- Hello, Cloud Gurus.
I'm Janani Ravi.
Welcome to Cloud Provider Comparisons.
In this series, we take a look at the same cloud service
across different cloud providers.
We'll explore what's similar, what's different,
and other details that may be interesting.
In this episode, we'll focus on containers.
We'll look at what the different cloud platforms
have to offer
for deploying and running containerized applications.
(upbeat music)
Before we jump in,
let's start with a quick overview of what a container is.
A container brings together
everything you need to run your application,
including dependencies and configuration management
in a single lightweight package.
Containers do not run
directly on top of your operating system
unlike old school applications.
Instead, containers run on top of a container runtime
which extracts your application
from the operating system nitty-gritty,
making your apps highly portable
and greatly speeding up development and release cycles.
The most popular containerization technology today is Docker
though there are other technologies
used in different ecosystems.
(upbeat music)
Let's get started with the basics.
Azure, AWS, and the GCP
all support containers and container clusters.
You first build a container image,
which is just a static file
with executable code that can create a container.
This container image
then needs to be registered with a container registry
that allows you to secure access to your container images,
manage versions, and a whole lot more.
On Azure, this container registry is simply called
the Azure Container Registry.
On AWS, no surprises here.
It's called the ECR or Elastic Container Registry.
The GCP also has a container registry.
However, given that teams need to manage
more than just containers,
GCP offers a next-gen container registry
referred to as the Artifact Registry.
The Artifact Registry is used not just for container images
but for language packages,
such as Maven and NPM and Debian packages as well,
operating system packages.
(soft music)
On all three cloud platforms,
it's possible for you to deploy your container images
directly on virtual machine instances.
However, this Infra as a Service option
has very high administrative overload.
In addition, you're dealing with standalone containers,
which is not ideal.
Standalone containers have several limitations.
They do not have the ability to provide replication,
auto-healing, auto-scaling, load balancing.
These are all must-haves in modern applications
and this is exactly why we need
a container cluster orchestrator such as Kubernetes
that automates software development, replication, scaling,
and load balancing on container clusters.
(soft music)
All three cloud platforms
have their own offerings of managed Kubernetes.
If you happen to have most of your applications
running on one of these cloud platforms
whether it's Azure, AWS, or the GCP,
you should stick to running Kubernetes
on that cloud platform.
This will give you great integrations
with the other existing services
that you're using on that cloud.
On Azure, you have the Azure Kubernetes Service or AKS.
On AWS, you have the Elastic Kubernetes Service or EKS.
And on GCP, you have the Google Kubernetes Engine
or the GKE.
How do they compare?
Well, the short answer is
that Amazon's EKS is the most widely used.
Azure's AKS may be the most cost-effective option.
And Google's GKE has the most features
and automated capabilities.
EKS and AKS were first released in 2018
and GKE was released way back in 2015.
No surprises there.
Google originally invented Kubernetes.
Both Microsoft and Amazon
had their own container orchestration technologies
before Kubernetes.
However, as the adoption of Kubernetes
in the software community grew,
Azure went ahead and integrated its service
with Amazon Kubernetes Service
and Amazon released a Kubernetes offering
in addition to its own offering.
Amazon still has its own Elastic Container Service
separate from Kubernetes for managing container clusters.
And that may be the right choice for you
if you want very tight integrations with other AWS services,
more than what Kubernetes provides.
All three services are globally available
but an advantage when using Azure and AWS
is that you can run Kubernetes on the government cloud,
the special infrastructure
that meets the needs of federal governments worldwide.
The GKE, that is Google Kubernetes Engine,
unfortunately does not have the option
to have your cluster run on the government cloud.
AKS and GKE are more automated.
They will automatically handle
security patches on the control plane
and upgrade the nodes that make up your Kubernetes cluster.
However, upgrades to EKS components
and node health repair for EKS components
tend to be much more manual.
Clusters are, by default,
virtual machines on all three platforms.
All three cloud platforms
support virtual machine nodes with GPUs enabled,
if you want that.
However, it's only Amazon
which supports bare metal machines as your cluster nodes.
Both Google Kubernetes Engine and Azure Kubernetes Service
have complete command line support to work with Kubernetes.
However, you may find that Amazon support
for the command line is much more limited.
Both Elastic Kubernetes Service and the GKE
provide an integrated service mesh,
which works on Kubernetes
called App Mesh on Amazon and Istio on Google.
However, Azure at this point in time
when we are recording this,
does not have an integrated service mesh
allowing you to work with microservices.
And finally, in terms of scale,
AKS can support 500 nodes in a cluster.
EKS can support just 100 nodes; and the GKE can support
up to 5,000 nodes in your Kubernetes cluster.
(soft music)
Now, if you're looking
for more turnkey solutions using Kubernetes,
Red Hat OpenShift is a Platform as a Service offering
that offers OpenShift build and deployment tools
in addition to Kubernetes.
This service is built using Kubernetes at its core
but it offers IDEs; runtimes; build tools; CI/CD services;
a service mesh; and much, much more.
Red Hat OpenShift is available as a service
on both AWS and Azure but not on the GCP.
(soft music)
Now it's also possible that you want to be able to deploy
and run containerized applications
without managing infrastructure and creating clusters.
You can do this
using something known as serverless containers.
Microsoft was the first in the industry
to offer serverless containers in the public cloud
via Azure Container Instances
where you run containers without using a Kubernetes cluster.
On the GCP, you can run containerized workloads
in a serverless manner using Cloud Run.
Once again, Cloud Run does not need
an underlying Kubernetes cluster.
AWS Fargate is a serverless offering on AWS
that removes the overhead of scaling, patching,
and managing servers on your container clusters.
An important way in which Fargate differs
from both Azure Container Instances and Cloud Run
is that Fargate is used to abstract away the overhead
of using an orchestrated cluster, either EKS or ECS.
It is not used without an underlying cluster.
(soft music)
Now, since Kubernetes can be deployed
on an on-premises data centers
as well as on all cloud platforms,
it offers a middle ground between Infra as a Service
and Platform as a Service options,
allowing you to work in a hybrid multi-cloud world,
which is increasingly important today.
Each cloud platform has its own offering
to support this hybrid multi-cloud environment.
On the GCP, you have Anthos.
Anthos is built around a Kubernetes core
where you run GKE on your cloud machines and GKE on-prem
on the machines in your local data center.
Google then uses a single control plane
to manage your applications in this hybrid environment.
On Azure, you have Azure Arc
that goes beyond managing hybrid Kubernetes deployments.
Azure Arc allows you to manage servers, Kubernetes clusters,
Azure data services and SQL servers
hosted on resources outside of the Azure platform.
AWS is not far behind.
Amazon EKS Anywhere is a deployment option,
which allows customers to create and operate
Kubernetes clusters on customer-managed infrastructure
supported by AWS.
Now, there is a lot more to say on container clusters
and interoperability in a hybrid multi-cloud world
but that's a topic for another day.
That brings this cloud comparison
containers edition to an end.
Thank you for listening to the very end
and keep being awesome, Cloud Gurus!
(soft music)