02 Feet in the Cloud, 04 Compute Unmanaged

The Return of the Bin Packer: Manual Orchestration

Reading Time: 3 minutes

As we are making our way backwards from Serverless to “plain compute” we should wonder if a Container Orchestrator, a managed or unmanaged one, is of actual use. When should Containers not be used at all?

Managed Orchestrators?

A managed service or application is always about paying a premium during an operational run against the costs of maintenance and reliability (99.0% to 99.99% guaranteed uptime). A Managed Orchestrator is a premium paid for the manager/master only, not for the servers required to run the Containers.

AWS ECS is completely free, no matter how many clusters or environments you have. When it comes to costs, there is no question there. However, AWS Elastic Kubernetes Service (EKS) and Google Kubernetes Engine (GKE) both cost $0.1 per hour per cluster. That would be about 75$ a month. If you’ve got three environments that would be 225$ a month.

That would be just for one cluster. At Silo we had two independent clusters, one that would run only Containers related to the messaging infrastructure and another that would run the customer facing services. There would probably have been a third one. [On splitting clusters in a future article]. That would have been $225 a month per environment and we had 7 of those planned, so it would have been a total of $1,575 a month. Costs do accumulate, which is another reason why we stayed with ECS and did not move to EKS.

I have no past experience with Kubernetes (K8S). When it first started it was somewhat unstable and was hard to set up. Today, as far as I’ve heard, creating your own cluster is an easy walk, and even to make it scale with Auto Scaling has been resolved.

Set up is of a Kubernetes cluster is considered to be fairly easy these days (it wasn’t back in 2018), and it’s even easy to make the worker nodes scale with Auto Scaling. But I have no past experience with Kubernetes, I would not know what to do in production when something happens.

It wouldn’t be a serious downtime. Containers would keep on running, but it would stop deployments and scaling. If it were to happen in the wrong time, which everything bad always happens in the wrong time, that would be a downtime my team and we wouldn’t be able to fix in time. For that reason alone, I might rather pay for a managed orchestrator (or take one for free). If there was an experienced DevOps with our team, I might have come to a different conclusion.

An Orchestrator?

an Orchestrator’s main function is bin packing, to move Containers between underlying servers in order to reduce costs [see Cloud Computing Evolution series]. If you have no need for this feature, you probably shouldn’t be using an Orchestrator at all.

A small fleet of a few servers that carries a small number of applications fixed in position, is not a call to add another unmanaged layer to maintain (master servers and agents). It would be counterproductive as the goal is to reduce maintenance and costs, not to add more of it.

Consider just containerizing as many of your applications so they would still retain their three traits (OS independent, Identity and the most important Isolation) and it would be of value to your development team. Instead of an automatic process, spread them out manually. It may be just a one time thing that will take you far less then to set up and maintain a managed cluster.

Leave a Reply