Fargate vs. Kubernetes: Which Container Orchestration Solution Do You Need?

Kubernetes and AWS Fargate both simplify the process of deploying and managing containerized applications. In many ways, they offer the same core features – which is not surprising, given that Fargate is, in some respects, an extension of or complement to upstream Kubernetes.

Yet ultimately, Fargate and upstream Kubernetes are distinct tools that cater to different use cases. Understanding the differences between the two platforms is critical for making the right decision about which service to use to deploy your containerized applications.

This article breaks down the similarities and differences between Fargate and Kubernetes by explaining how they relate to each other, how they approach container orchestration, and what the unique features of each platform are. As we’ll see, neither of these tools is the best solution for every use case and every workload; instead, each has strengths that cater to different types of situations.

What Is AWS Fargate?

Fargate, which AWS introduced in 2017, is (to put it simply) an orchestration engine for containers and the infrastructure that hosts them. It automatically sets up and manages the infrastructure required to host containers. It also automates the deployment of containers on that infrastructure. In these ways, Fargate removes much of the management overhead required to deploy a containerized application.

You could also describe Fargate (as AWS does) as a “serverless compute engine for containers.” In other words, Fargate does for containers what serverless platforms like AWS Lambda do for serverless functions: it automatically handles the infrastructure resources required to deploy an application so that developers and IT engineers can focus on the application rather than on managing its host environment.

Importantly, Fargate runs each node for the infrastructure it provisions within an isolated kernel. This means that the platform delivers the same level of isolation between workloads that teams could achieve by provisioning their own clusters, without the requirement that they actually provision the clusters themselves.

What Is Upstream Kubernetes?

Kubernetes, of course, is an open source container orchestration engine. It automates many of the management tasks associated with running containerized applications, including determining which nodes to use to host containers, restarting failed containers, and (through a plugin architecture) managing storage and networking resources for containers.

Anyone can download and build the open source Kubernetes code, which is known as upstream Kubernetes. However, most people deploy Kubernetes using a pre-built and pre-configured distribution. These distributions are different from upstream Kubernetes in that they often include certain configurations or add-ons, which upstream Kubernetes lacks. Put another way, distributions are “opinionated” with regard to how they configure Kubernetes.

What Is Fargate Kubernetes?

The relationship between Fargate and Kubernetes is a bit complex. To define it, let’s start by explaining what Fargate is not.

Fargate is definitely not upstream Kubernetes. The Fargate code itself is certainly not generic Kubernetes code. Fargate is also not a Kubernetes distribution. It’s not based on or derived from Kubernetes.

Instead, probably the best way to think about Fargate’s relationship to Kubernetes is to say that Fargate is an optional management tool that complements Elastic Kubernetes Service (EKS), Amazon’s managed Kubernetes platform. Fargate complements EKS by providing an alternative scheduler that allows pods deployed within an EKS cluster to be managed by Fargate.

The relationship between Kubernetes and Fargate is made more complex by the fact that Fargate doesn’t require Kubernetes to run. Fargate can also work with Elastic Container Service (ECS), another AWS-managed container service that uses its own orchestration engine rather than depending on upstream Kubernetes.

The bottom line: Fargate can optionally be used to manage infrastructure within EKS. (It doesn’t work with other Kubernetes distributions or platforms.) But Fargate can also manage containers running outside of a Kubernetes cluster.

Similarities and Differences Between Fargate and Kubernetes

Fargate and Kubernetes both provide orchestration and automation features related to containerized applications, but the extent to which their functionality overlaps is limited.

Fargate vs. Kubernetes: Key Similarities and Differences

Feature or function	Fargate	Kubernetes
Infrastructure management	Fully managed	Limited to container reallocation (although some distributions support node auto-scaling)
Workload types	Containers	Containers and VMs
Supported environments	ECS and EKS	Any cloud or on-prem environment
Logging and monitoring	Native integrations with AWS tools	No built-in solutions; admins choose from a variety of plugins or tools that run as sidecars
Infrastructure control and access	No direct access to nodes	Full access to host nodes
Licensing model	Proprietary	Open source (although some distributions contain proprietary add-ons)
Pricing model	Pay-as-you-go based on resource consumption	Depends on configuration and type of infrastructure

Fargate vs. Kubernetes: Similarities

We can sum up the similarities between the two platforms as follows:

Container scheduling: Both platforms provide container scheduling, which means they automatically determine where to deploy containers.
Infrastructure management: Both platforms provide infrastructure management, albeit to different degrees. Fargate fully manages host infrastructure. Kubernetes usually doesn’t provision infrastructure (although some distributions can be configured to perform node autoscaling, which means they will add nodes automatically) or do anything to keep nodes running smoothly. But Kubernetes does at least check for nodes that have failed and then reallocate pods accordingly. Arguably, you could say that this is a form of infrastructure management.

Fargate vs. Kubernetes: Differences

The differences between Fargate and Kubernetes are more numerous:

Infrastructure provisioning: Fargate sets up the servers required to host containers for you. Upstream Kubernetes does not (except, again, in the case of distributions that support node autoscaling – but even there, admins have to do more work to write policies that specify when nodes should be autoscaled, whereas Fargate automatically determines when to scale).
Serverless architecture: Fargate operates according to a serverless model. Kubernetes uses a conventional distributed-server architecture.
Plugins and customizability: Kubernetes supports a large ecosystem of plugins, which give teams a lot of options when it comes to how Kubernetes manages resources like storage and networking. Fargate has some configuration options, but it offers much less customization.
Platform dependencies: Fargate works only with specific services within the AWS cloud (namely, EKS and ECS). Kubernetes is a generic open source platform that can run virtually anywhere.
Pricing: AWS prices Fargate based on how many infrastructure resources an application consumes while running in Fargate. With Kubernetes, pricing models vary widely based on where and how a cluster is deployed. Whether or not Fargate is less expensive than Kubernetes depends on many factors, especially how cost-efficient the nodes used to set up a Kubernetes cluster are, and whether they are used to full capacity.
Node access: With upstream Kubernetes, developers and admins have full access to the operating system environment for each node within the cluster. Because Fargate abstracts the host infrastructure from users, Fargate provides no equivalent level of access.
Logging: Fargate has a built-in log shipper that can be configured to push logs to a variety of locations, such as S3 or Firehose. Kubernetes has no log collectors or logging pipeline tools built in by default, but it is compatible with a variety of third-party logging architectures and tools.
Monitoring: Fargate can be easily monitored using AWS tools like CloudWatch and CloudTrail, with which it integrates easily. Third-party monitoring tools can also be used to monitor Fargate. Kubernetes provides no default monitoring tool, but a variety of third-party monitoring platforms can integrate with Kubernetes.
Configuration and management: Fargate uses proprietary tooling for configuring workloads, and it provides relatively few configurations in general. Kubernetes workloads can be configured using YAML or JSON files, which can define a wide variety of settings based on configuration frameworks that are built into Kubernetes, like RBAC and pod security settings policies.
Supported workload types: Fargate only supports the deployment of containerized applications. Kubernetes is primarily used to deploy containers, but modern versions of Kubernetes can also manage workloads inside VMs if desired.

When to Use Fargate

Fargate makes sense for use cases where the following conditions are true:

You need relatively little control or customization over how your workloads are deployed and run.
Your workloads aren’t subject to strict compliance mandates that require specific types of isolation between workloads or data protection measures (which you may not be able to implement using Fargate’s limited feature set).
Your workloads are highly scalable and will require more infrastructure resources as they grow.
You don’t want to worry about the complexity of configuring Kubernetes networking resources, storage plugins, RBAC, and so on.
All of your workloads run as containers.

To put this another way, Fargate is the best choice for containerized workloads that are relatively simple and straightforward. It’s also a good option for teams that aren’t versed in the deep complexities of Kubernetes and want a simple way to deploy containerized apps without the infrastructure management hassle.

When to Use Kubernetes

In contrast, Kubernetes is a better fit for the following use cases:

You need extensive control over workload configuration.
You need OS-level access to the host infrastructure.
You want to use third-party monitoring, logging, or other management tooling that Fargate does not support (again, although Fargate can integrate with some third-party tools, it’s primarily designed to work within the AWS ecosystem).
You want the ability to deploy workloads anywhere – in any cloud or on-prem – and to move them when necessary.
Your team understands Kubernetes from top to bottom and is prepared to handle the complexity of Kubernetes configuration.
Your workloads won’t scale quickly – or, if they do, you are prepared to scale them yourself (or set up node autoscaling, if your Kubernetes distribution supports it).

In short, if you need maximum control and have the necessary management expertise on hand, upstream Kubernetes will provide more options and customizability than Fargate.

Interested in More Content?

Read here for a detailed comparison between EKS vs ECS vs Fargate
Read more about Platform9’s latest innovation to save big on EKS costs – Elastic Machine Pool
Watch latest demo of Elastic Machine Pool here:

Author
Recent Posts

Platform9

Platform9 is the only container management and orchestration solution that supports the complete lifecycle of the cloud-native journey on infrastructure anywhere. Our unique management plane simplifies operations, including observability & monitoring, increases uptime, minimizes costs, and scales as you scale. Built on open foundations, our platform enables enterprises to keep up with the ever-changing cloud-native ecosystem. Our cloud-native wizards provide Always-on Assurance™ every step of the way to ensure a smooth, simplified journey. Innovative enterprises like Juniper, Kingfisher Plc, Mavenir, Redfin, and Cloudera achieve 4x faster time-to-market, up to 90% reduction in operational costs, and 99.99% uptime.Platform9 is a better way to go cloud native, paving the way for an open distributed cloud