The Case for AWS Fargate. Consider Letting Someone Else Handle your Container Orchestration.
First, let me start by saying that a discussion of rolling your own vs buying a service or platform off the shelf is usually not an easy one. You may lean one way or another based on your particular requirements or circumstances, and that’s perfectly OK. We should all be celebrating the plethora of choices we have when selecting tools to get the job done.
Second, let’s not beat around the bush and jump right into the controversial topic of vendor lock. I find that the principal reason some customers choose to run their own Kubernetes cluster is to avoid the dreaded vendor lock. They say with Kubernetes you are free of eternal dependence on one cloud provider or another, and that you enjoy the freedom of movement and the piece of mind knowing that your systems can run on-premise, in the cloud, or anywhere in between.
Except there is one problem: you’ve vendor locked to Kubernetes. Sure it’s open source, but consider how easy it is to move off of K8 and to another orchestration platform that you hand rolled. I mean really think about it. Take all your environments, your products, the infrastructure scripts and the amount of time it took to test HA and scalability. Yep, you are not moving off of Kubernetes, not easily anyway. In other words — vendor locked.
All it is to say that vendor lock or some form of it is not a bad thing. It happens all the time. Consider Python, the programming language.
One cannot say that they’ve vendor locked to Python, but I would say Python does have a gravitational field.
Once your organization has chosen Python as one of the adopted languages for your applications, chances are you will not be looking to move away from it, unless there is a clear and substantiated need. You are not vendor locked, but separating away is not that simple.
Let’s move to the second most predominant reason customers choose to hand roll their Kubernetes environments: perceived cost savings.
This one is a bit tricky. Indeed depending on scale one can reap the benefits of rolling your own Kubernetes environment. It really depends on how your organization is set up — do you have centralized infrastructure for all your product lines (and the relevant operations / SRE / support staff to go with it) or is your infrastructure partitioned by BUs and product lines?
Depending on your scale, your product needs, and how your org is structured AWS Fargate or Azure Container Services may be a good fit.
The simple premise with AWS Fargate is that you are letting the cloud provider handle your container orchestration. Your job is to provide the credit card. Not quite that simple — but you get the idea. Instead of you hiring and keeping the right talent you hire someone else to do the work.
Here’s an oversimplified diagram that compares the options:
Depending on the size and the requirements for your container orchestration environments, you might just elect to pay for someone else to do the work. Fargate has gone through a series of price reductions recently, so it might be worth to re-visit the topic if you have a new greenfield project coming up.
Why do I need containers — why not go the full Serverless?
That too is something worth considering. The short-lived request/response nature of web makes a very good case for wrapping your APIs into Lambda or Azure functions. Those are some of the first and usually the easiest pieces to move into serverless functions. If you have longer running workloads, code that needs OS access, workloads that are latency sensitive, code that has a large package (or compiled) size, or code that has a large memory footprint — then serverless may not be a good fit.
The idea of this article was not to start a this vs that war (although the title says otherwise) but to highlight that there are other options that are worth considering, and that one should give them a chance rather then ruling them out based on “vendor lock” or potential higher costs.
Cheers
