Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Comparison: Running serverless containers in Google Cloud Run, AWS Fargate, and Azure

Cluster-based orchestrators, for example, Kubernetes, are complex to manage. Using a managed service such as Azure’s AKS or Amazon’s EKS might guard the server infrastructure. Still, it doesn’t take care of the operational overhead involved in securing, configuring, and managing your pods. Do we have to go through this overhead just to run a cluster of containers? The leading cloud providers each have an evolving “serverless” offering for running containers without the difficulty of running any orchestration infrastructure. Azure was the first state-of-the-art with Container Instances; however, Google’s Cloud Run service and AWS Fargate followed the same.

Generally, each of these services delivers a similar proposition. You can twist up containers on demand and tear them down again. The charges are for the usage concerning processor time, memory, and the number of requests in Google’s instance. You can discard all the unnecessary details involved in building and maintaining nodes and clusters.

Is this actually “serverless”?

The services may be advantageous, but it doesn’t inevitably count as “serverless.” Running containers in these services aren’t entirely comparable to the PaaS experience offered by function-as-a-service platforms such as Azure Functions and AWS Lambda.

A “real” serverless platform should deliver an absolute abstraction of the hosting infrastructure along with reasonable pricing. Provisioning should be easy and quick. You should also expect a level of automatic, elastic scaling in response to demand. Ultimately this should incorporate scaling to zero in the absence of any need. None of the platforms fit this description. For instance, Azure Container Instances is easy to get up and running with the same experience as the Docker run command. So far, so good, but it doesn’t provide any manually provisioned automatic scaling and instances. This is one of the limitations of its usefulness.

AWS Fargate is more of an untangled way of deploying containers to ECS or EKS instead of a clean, serverless abstraction. It doesn’t hide the underlying clusters, and the provisioning process can take up to twenty minutes while AWS spins everything up. You can define resource consumption restrictions, but there’s no elastic scaling unless you need to get involved in configuring the underlying cluster.

Google’s Cloud Run draws nearest to a real “serverless” proposition. It offers a seamless developer experience with auto-scaling out of the box, including scale-to-zero. You can define the number of convergent requests that a single instance can accommodate and the maximum number of created instances.

Comparison: Google Cloud Run/AWS Fargate on EKS/ Azure Container Instances

On the Whole

Even though AWS Fargate on EKS holds an elegant design, concept, and architecture, it lacks an intuitive developer experience. Because of the dependency on an EKS cluster, it consumes at least 20 minutes to deploy an existing pod definition on Fargate. The service becomes less productive when configured from the AWS Console, a private subnet, creating a pod execution role, and the namespace. The creation of an ALB, connecting that with the private subnet running the Fargate pod, is so much work to reveal a public internet job. However, the latest release of eksctl takes care of the plumbing; you will still have to use the typical AWS CLI or the AWS Console to create the ALB. Changing between eksctl, aws, and kubectl lessens the productivity of the developers.

The assurance of a serverless container platform is to offer developer experience equivalent to that of PaaS. AWS Fargate on EKS needs DevOps to do a little heavy lifting before the developers could deploy the first pod. Amazon may finally launch a managed Fargate service that makes EKS and ECS totally invisible by revealing the stack’s topmost layer. Assume the potential to submit a Kubernetes pod to an environment that doesn’t force you to launch a cluster in advance.

By hiding the infrastructure operations, both Google Cloud Run and ACI squarely focus on the developer experience. Both of them ensure to hand over a URL as soon as the container image is deployed. AWS Fargate on EKS is in the right direction, but the developer experience needs enhancement.

Confused about choosing the right cloud service provider? Get in touch with us today.

Leave a Reply

Your email address will not be published. Required fields are marked *

Share on facebook
Share on twitter
Share on linkedin

Recent Posts

Looking to enhance your productivity while cutting costs through cloud computing solutions?

Talk to our solutions expert!