Cloud Hosting

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 bringto the table that other serverless solutions, such as AWS Lambda and Microsoft Cloud Functions,don't? Whats different?What are the use cases?Andwhen should you use Cloud Run over "traditional" serverless platforms?

Here's what you need to know about Google Cloud Run.

[ Enterprise Service Managementbrings innovation to the enterprise. Learn more in TechBeacon's new ESM guide. Plus: Get the 2019 Forrester Wave for ESM. ]

Cloud Run can produce a container image with an encapsulated web server inside. Itcan also determine a set of resources, including compute, memory, and storageall with concurrency in mind.The whole thing must leverage stateless logic.

Cloud Run is serverless, whichmeans 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, offeringjust 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 ofresources 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.AndCloud Run can scale by assuring that the proper number of containers needed to handle the load isrunning.

Sothe real differences amongthe 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 means that you can deploy sourcecode 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 Runpoint to some drawbacks with this system.

Cloud Run is intendedfor 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 runon this platform as well, and the "runtime contract"is considered stable, meaning it's not likely to change.From there, developers needto create a Dockerfile 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 useCloud Run services, the first step is to build the container, which then moves to testing on a staging platform.From there it getspushed 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.

[ Learn how to transform your IT with AIOps in TechBeacon's guide. Plus: Download the analyst paper on how AI is changing the role of IT. ]

Putting the platdform religious warsaside, what Cloud Run offers is a sound serverless platform, delivered as a managed service, that supportscontainers 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'san advantage if youhave 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 valueserverless 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 resultof deployed, container-based serverless applications will be much the same when placed into production.

Onthe 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 toguesshow 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 operationswithin 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 100thof 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 iseasier to track to production.Testing is easier as well, considering that the Cloud Run container is a full-blown web server, which simplifies bothremote and local testing.

However, what is a positive can also bea negative.A forced full-blown web server exists inside the container.This may be limiting for organizations withdifferent application requirements.

The mistake that many people make when comparing Cloud Run to Lambda and Functions lies in how theyanalyze the internal features and functions of each.That's not a fair way to compare theseproducts.Most of whatdifferentiates one serverless platform fromanother are your application requirements.Considering that we're moving into a multicloud world, Cloud Run may not be a bad approach.

The dirty little secret about traditional serverless is that itplaces 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 stronga 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 deploymentand 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.

Cloud Run is best forshops 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:

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'mcertain that we'll see more evolution of Cloud Run in the near future.

[ Learn how robotic process automation (RPA) can pay offif you first tackle underlying problems. See TechBeacon's guide. Plus: Get the white paper on enterprise requirements. ]

Go here to see the original:
Google Cloud Run: What every IT Ops team should know - TechBeacon