Tech Talk: Breaking Down DevOps
Written By: Matt Rogish
I’ve been hearing a lot about DevOps. What does it mean to you?
DevOps is one of those terms, kind of like Agile or XP, that means different things to different people. To me, DevOps means Developers and Operations working more closely together, and walking a mile in each other’s shoes (you’ll hear the word empathy thrown around a lot). Developers should support their applications in production (including pager rotation!) and architect, design, and build applications with infrastructure supportability in mind, and Operations needs to engineer infrastructure using better development techniques: test driven development, automation, and with developer ergonomics in mind (providing a standardized, scalable platform and not just isolated snowflake systems).
Should I break up my app into microservices/build it that way from scratch?
Microservices are primarily a technical solution to a primarily organizational problem. There’s immense overhead to microservices that are best amortized across a bigger organization. When Dread Pirate Bezos dictated that all apps that power Amazon will be services, he didn’t do that to be trendy. It’s a longer topic than I can discuss here, but this was put into place because of organizational scaling issues, not necessarily solely technical ones. Make sure you understand what problem you’re solving with microservices because you might not have it yet (or ever!).
What is Docker, and why should our team us it?
Docker is, at its core, a wrapper around a software (often a microservice) payload that provides a consistent runtime environment in both development and production, removing the old “It works in development, but not in production” problem.
That’s it?
Sort of. Much like PhoneGap/cordova, the core is just the tip of the iceberg. With containers, you need to figure out how to handle: security, discovery, config management, supervision/monitoring, deployment, networking, orchestration, and the underlying runtime. It’s a huge puzzle that doesn’t have a clearly defined right or wrong answer right now.
So should I use it or not?
6–12 months ago, I’d have told you to wait. The ecosystem is changing so quickly that the gaps you’d have to fill in on your own would be filled by open source software from the likes of Docker, CoreOS, Google, Amazon, etc. — and you don’t want to build your own in this space if you don’t have to. Nowadays, we’re quickly converging on “not obviously the wrong answer” software like Kubernetes, Tectonic, Deis, etc. that it’s much less of a shifting landscape.
However, even today there are show stopper bugs in some of these tools that if you hit them will make it very difficult to operate this at small/medium scale. Without expending significant resources fixing these issues, you’re stuck. If you’re happy on a VM environment, I’d say wait. The longer you can afford to keep what you have, the more robust the ecosystem will be in 6–12 months.
What about Serverless” architectures? What the heck does that mean?
“Serverless” is the new “DevOps”. Serverless doesn’t mean there aren’t servers — just that some approximation of “you don’t have to worry about it” holds. The current champ is AWS Lambda. Lambda essentially is a JavaScript or Python function executor-as-a-Service. You write event-driven functions that have a Web API and can scale (theoretically) infinitely — without you needing to worry about servers, operating system patches, upgrading, security, etc.
What’s the catch?
The catch is that this completely locks you in to the vendor, the tooling is relatively immature (so local development is more difficult), and it gets more expensive than a similar (but more laborious) VM-based environment. And, it only supports a handful of languages and runtimes (no Ruby-on-Rails-Controller-Actions-as-a-Service yet!).
Lambda represents a huge leap forward from the VM and Container runtimes we’ve been using. Once they figure out how to improve the developer ergonomics, I’d be surprised if we didn’t see a new era of “Serverless” apps and frameworks emerge.
So VMs are dead then?
In the same way that the internal combustion engine-powered car is. Not today, not tomorrow, perhaps not even 5–10 years from now. ICE “works”. We have figured out most of the bugs (aside from things like pollution and fossil fuel usage). VM-based infrastructures “just work”. We have a great set of tools like Ansible, Terraform, and Packer to create autoscaling, completely automated AWS infrastructures that you don’t have to worry much about. But the rapid innovation and investment has moved on to containers and serverless architectures.
We won’t see orders of magnitude improvements in VM-based workloads like we will see in containers and serverless. VMs represent the pinnacle of current technology, and although are today better general-purpose architectures, at some point in the future won’t be. When? Too soon to tell, but I’d bet good money that we’ll still be deploying plenty of VMs to AWS in 10–15 years.
If your workload is best represented as a VM-based architecture, then there’s no reason not to use VMs.
What’s the final word on VM vs. Docker vs. Serverless?
If you have a general-purpose workload, put it on VMs. If you have an obviously microservice problem, use Docker. Serverless is too soon to use for widespread app development, but you should definitely keep it on your radar and experiment with it.
Written By: Matt Rogish
Fairwinds — The Kubernetes Enablement Company
ClusterOps Managed Kubernetes — ClusterOps is a fully-managed Kubernetes cluster management tool that integrates infrastructure as code, open source software, and SRE expertise as a subscription service.
ClusterOps Kubernetes Advisory — ClusterOps Advisory integrates Kubernetes expertise and open source software so you can confidently run reliable, scalable, and secure Kubernetes clusters.
Fairwinds Insights — We integrate trusted tools, collaboration workflows, and expertise into a single monitoring platform, so workloads always stay secure, reliable, and efficient.
