{
  "$type": "site.standard.document",
  "canonicalUrl": "https://unnecessary.tech/posts/cloud_run",
  "path": "/posts/cloud_run",
  "publishedAt": "2019-04-21T00:00:00.000Z",
  "site": "at://did:plc:jx54v4rmscfwzit7fmgz24ba/site.standard.publication/3mnrsqmzz3w2e",
  "tags": [
    "cloud"
  ],
  "textContent": "One of the major announcements at Google Cloud Next this year was Cloud\nRun,\nwhich Google describes as \"containers meet serverless.\" Although that's a\ngreat combination of two current buzzwords, in terms of functionality it may\nbe more accurate to think of Cloud Run as a modern PaaS service. In contrast\nto classic PaaS, popularized by platforms like\nHeroku, Cloud Run offers the following advantages:\n\n\n\n1. Accepts Docker containers rather than code, though it does offer a\nseparate, optional cloud build system.\n2. Automatically scales based on traffic to maintain a user-definable number\nof concurrent connections per instance, which defaults to 80.\n3. Only charges for CPU and Memory consumed during an actual web request\n(rounded up to the nearest 0.1 seconds).\n\nHowever, it's still in beta and has a few drawbacks including\nbeing only available in a single region, at the moment, and no ability to set\na maximum budget or scale-out limit. You also can't connect a Cloud Run\nservice to a VPC, which makes it harder to secure connections between Cloud\nRun and some backends. \n\nThe most notable benefit is that it's built on containers, which\nmakes the applications you deploy on Cloud Run very portable. If it turns out\nyour container is serving queries most of the time, it would be easy to move\nthe service to Kubernetes, Google Compute\nEngine, AWS\nFargate,\nAzure, or even\nDigitalOcean. It's also\neasy to test applications, and most developers are familiar with containers.\n\nThe focus on containers also means it is possible to deploy just about\nanything using just about any development environment. One example I found\nparticularly amusing is Fortran 90 on Cloud\nRun. A community has\nalready started to form around this technology with a very useful unofficial\nCommunity FAQ as well as an\nawesome list.\n\nEnterprise users may continue to find that orchestrating pods on\nGoogle Kubernetes Engine is the best way to manage large containerized\napplications, other containerized applications might be more easily deployed\nusing Cloud Run along with Google's existing managed container platform which\nincludes\nGoogle Compute Engine's\ncreate-with-container,\nor Container-Optimized OS\nas well as App Engine\nFlexible. These services\nallow you to use the familiar and well tested tools built-in with Google\nCloud Platform for your containerized applications, though in the end you give\nup some portability for convenience.\n\nIf I have any qualms over Cloud Run it is with Google itself whose focus is\noften inscrutable. App Engine is a perfect example of a service which has\nsuffered through a mixed stewardship from Google. It was a breakthrough\nservice which may have been ahead of its time, but it languished for years\nwithout significant updates as other platforms caught up and exceeded its\ncapabilities. App Engine Flexible appeared bring new life to the\nplatform until the second generation runtimes came out and seemed to signal a\nstep away from a containerized focus. Cloud Run might be thought of as App\nEngine Flexible second generation in this context, but will Google continue to\ninvest in this new service, and adapt it to emerging workflows? I have no\nidea.\n\nIf this has peaked your interest, I encourage you to give Cloud Run a try. The\nmore users it has, the more likely it is to remain in Google's good graces.",
  "title": "Cloud Run: The Future of PaaS"
}