On the heels of Dockercon I was recently contemplating different ways to build, deploy and scale an app. The following question popped into my mind.

Virtualization and container tools have gotten so complex, are we creating more risk by containerizing and orchestrating, or are we really adding value?

The answer I came to was YES. The distinction really becomes what you are doing with your app (api, etc) and what your needs are for scaling.

I was inspired by these two posts (worth reading later). https://thenewstack.io/has-kubernetes-already-become-too-unnecessarily-complex-for-enterprise-it/
https://news.ycombinator.com/item?id=16851756

When to to keep it simple stupid

I think the kiss idea is great, but in devops practice it is not so straight forward. Don’t use the concept to settle for or justify a shitty implementation. At the core though, if you only need a knife, don’t bring a machine gun to the fight.

If your app is small and gets updated once a quarter at best, you can keep maintenance costs down by skipping containers and orchestration all together. When you need more firepower upgrade the VM, when you need to scale the app beyond a single host re-evaluate with a load balancer (here there is no one size fits all option either). I see people who want to be able to massively scale from day one only to find they do not get the traffic to justify the expense for months or years…or even never. This advice is primarily for start ups and small businesses.

For enterprise deployments, things can quickly become more gray. For large enterprises going from 1 to 10,000 containers in a short period of time could be a real requirement. Security and compliance are a big concern regardless of volume. This is true even for back office or smaller internal custom apps. If you have dozens or even hundreds of apps in your company, finding ways to manage them all is a real concern, internal apps included. This is where DevOps can really shine. After the initial investment you could reap the benefits for years. Letting numerous apps forgo security updates and regular maintenance is an accident waiting to happen for any CIO or CTO with oversight.  Full containerization, orchestration and automation would make a good fit here.

Things to keep in mind

What is the maintenance budget and do you have dedicated resources (budget) to manage your DevOps infrastructure?

There are numerous ways to leverage tools like Kubernetes and docker at all sorts of scales. Don’t feel pressure to conform to any one direction…this area is definitely not one size fits all. Try to leverage the team’s skill set and encourage them to try out some new technologies.

Consider using a Kubernetes PaaS from AWS, Docker or Google. You could also give Rancher or OpenShift a shot. If you are managing 100s of microservices and have a large ops team, run your own k8 cluster tuned to your needs.

We use Rancher and Docker here at Arroyo Labs (expect a follow up post on that).

What about a more traditional approach, such as Chef / Puppet or Consol + Ansible / Salt? If someone on the team is an expert at some combination of those tools, leverage it. If you’re starting from scratch, you can avoid these tools altogether. They are mature and well supported in the community but aren’t needed depending on your approach.  If you are trying to stay lean, why not avoid these until the need is very explicit?

Key take aways

Consider Rancher when the overall complexity of Kubernetes will just get in the way or have a limited devops budget. Consider what orchestration features you need and go from there. If you are using Kubernetes check out one of the great hosted versions (EKS, GKE, or AKS).  As your containers grow you will probably be using Kubernetes, the real question is how deeply or explicitly you will rely on it (hint both Rancher 2 and OpenShift have kubernetes under the hood).

I hope this post can clear up or isolate some of the considerations for a modern cloud app, at the very least I hope this doesn’t create more confusion. To some architects and engineering managers I am sure analysis paralysis has already set in with options for migrating your legacy behemoth to the cloud (and containers).

Although many of these tools are free, the staff needed to set up and maintain them are not and can get significant as you automate and scale. My motto is be prepared to scale, but beware of the costs of doing it too prematurely.

I didn’t get into CI / CD, that conversation is part of the overall picture, but deserves it’s own post(s).  If you aren’t leveraging tools for continuous integration and deployment yet, you should be. You don’t need to dedicated DevOps engineers to pull off continuous deployments. More on that topic later.