You might think of Google Cloud Run, launched last November, as serverless for containers. That's true, but it's also much more.
So what does Cloud Run bring to the table that other serverless solutions, such as AWS Lambda and Microsoft Cloud Functions, don't? What’s different? What are the use cases? And when should you use Cloud Run over "traditional" serverless platforms?
Here's what you need to know about Google Cloud Run.
What's different — and the same?
Cloud Run can produce a container image with an encapsulated web server inside. It can also determine a set of resources, including compute, memory, and storage—all with concurrency in mind. The whole thing must leverage stateless logic.
Cloud Run is serverless, which means you don't have to fiddle with back-end resources to run applications.
As with other serverless platforms, Cloud Run can scale up or down, offering just the right amount of resources. No more over-provisioning services just to be sure you won't run out of memory, storage, or compute. Even better, no more under-provisioning, where falling short of resources can cause your application to fail.
Indeed, the serverless value proposition is much the same as with Lambda and Functions.
Cloud Run can create HTTP endpoints after you push a container. These can receive requests and route them to containers. And Cloud Run can scale by assuring that the proper number of containers needed to handle the load is running.
So the real differences among the Amazon, Microsoft, and Google products are around how serverless applications are deployed. Both AWS Lambda and Microsoft Cloud Function are "source-based," while Cloud Run is not.
Source-based vs. container-based
Source-based means that you can deploy source code to a serverless platform, where that code is compiled. There are two advantages to doing this: ease of use and speed. However, those who promote Cloud Run point to some drawbacks with this system.
Cloud Run is intended for those who focus on container-based development versus using source-based systems. The idea is that containers provide separation of duties between the developer and the platform where the container executes.
The developer has the duty to create and start an executable that opens a port for HTTP requests. Containers run on this platform as well, and the "runtime contract" is considered stable, meaning it's not likely to change. From there, developers need to create a Docker file and launch the HTTP server.
If that seems a bit complex, just think of Cloud Run as leveraging a container architecture that's core to the service.
AWS and Microsoft support containers, including Kubernetes, but use a source-based approach that some developers find limiting. Container fans will find Cloud Run compelling.
Indeed, one of the core differences is found in continous integration/continuous delivery (CI/CD) around the deployment of services. If your organization leverages continuous delivery, it's imperative that you separate the build and deployment stages.
When you use Cloud Run services, the first step is to build the container, which then moves to testing on a staging platform. From there it gets pushed to a production platform.
Compare this with AWS and Microsoft, which are both source-based, and it's difficult to determine what ends up on the production server because you can see the output of the build process only after it's deployed.
Where is serverless going?
Putting the platdform religious wars aside, what Cloud Run offers is a sound serverless platform, delivered as a managed service, that supports containers and many different programming languages.
While the number of programming languages supported by traditional serverless platforms is limited, all major managed services expand their language support with each new release. Since Cloud Run is not source-based, that's an advantage if you have applications already built using a specific language.
The growth of the serverless market in the last few years has resulted in a more explosive growth of containers and Kubernetes. Enterprises consider Kubernetes as the platform of choice due to the portability of container-based applications from platform to platform, cloud to cloud.
The real selling point for Cloud Run is its container-focused architecture, development, and deployment. That, combined with the value serverless brings, could equal a home run for Google.
Then again, other cloud providers are good with containers and container orchestration, including Kubernetes, which is already on the serverless container bandwagon. While you can get into an argument about source-based versus container-based approaches, the end result of deployed, container-based serverless applications will be much the same when placed into production.
Be mindful of the tradeoffs
On the positive side, Cloud Run makes it much easier for developers who build container-based and stateless web servers to quickly move to elastic serverless technology. Because you don't have to guess how to size container servers, Cloud Run will ultimately provide a better ROI.
The serverless benefits are also compelling. While some people can accurately size resources, and even leverage reserved instances at a discount, most enterprises struggle to manage cloud operations within cost parameters. Serverless provides more fine-grained billing.
Like all public cloud providers, the pricing for Cloud Run is a bit confusing. Fully managed Cloud Run charges only for the resources you use, rounded up to the nearest 100th of a millisecond. However, each of these resources include a free quota that you can take advantage of. Your total bill will be the sum of the resources you use in the pricing table.
Another advantage if you do DevOps and CI/CD is the ability to integrate better with continuous deployment, since Cloud Run is easier to track to production. Testing is easier as well, considering that the Cloud Run container is a full-blown web server, which simplifies both remote and local testing.
However, what is a positive can also be a negative. A forced full-blown web server exists inside the container. This may be limiting for organizations with different application requirements.
The mistake that many people make when comparing Cloud Run to Lambda and Functions lies in how they analyze the internal features and functions of each. That's not a fair way to compare these products. Most of what differentiates one serverless platform from another are your application requirements. Considering that we're moving into a multicloud world, Cloud Run may not be a bad approach.
What about lock-in?
The dirty little secret about traditional serverless is that it places guardrails on what you can do. This affects application development and includes programming code and architecture. Thus, moving code from one serverless platform to another serverless platform is not a direct lift-and-shift port.
Lock-in may be too strong a term, but be aware of its potential impact on your project.
Cloud Run is perhaps more portable considering the container-oriented approach to development and deployment and the open nature of the programming languages in use. At the very least, the concept makes Cloud Run applications more portable than those running in traditional serverless systems.
The best use cases for Cloud Run
Cloud Run is best for shops that are all-in with containers and want a purer container deployment using the advantages of serverless. Those who are not sold on containers won't find Cloud Run as compelling, unless your projects are based on Google Cloud Platform.
It's safe to say that the best Cloud Run use-case patterns would consist of:
- People who are targeting containers and container orchestration as their preferred platforms and are looking for serverless technology that's more container-native
- Applications that require an HTTP server as part of the architecture, and the testing simplicity that comes with it
- Those who depend upon continuous deployment and want better control and visibility
- Those who are sold on serverless systems but are not happy with the features and functions of serverless offerings from other cloud providers
- Those who find this approach to serverless more cost-effective than leveraging containers using non-serverless deployments, where resource overages are normalized
Of course, there are security, governance, and management capabilities that need to be considered as well. And many organizations need to consider the cloud-native features of the cloud provider that hosts the serverless managed service.
In other words, you need to consider the holistic picture of cloud, cloud services, infrastructure, and then the serverless systems.
The good news for cloud computing is that we now have one more serverless system. This time serverless converges to meet containers, which is hype squared. That alone may make this a compelling choice for many enterprises. And I'm certain that we'll see more evolution of Cloud Run in the near future.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
