Cloud native adoption means getting the DevOps tooling right

There's no debate over the fact that a cloud native architecture using DevOps tooling can work.

Eliminating the wheel and spoke architecture where the massive monolith sits in the middle, and instead approaching software design by using DevOps tooling with a focus on serverless functions, stateless processes, isolated microservices and container based deployments has definitively been proven to work. But getting cloud native and DevOps tooling to work at scale isn't easy, and the vast number of different pathways to success can be outright intimidating to those with a more traditional set of software development skills. While competitions is good, the smorgasbord of different technologies that are trying to plant their flag in the DevOps tooling space may actually be hindering cloud-native adoption, as the endless set of choices can easily lead to delayed decision making and discussion overload.

"There's probably at least ten different fancy reverse proxies out there you could use for microservices," said Chris Aniszczyk, COO of the Cloud Native Computing Foundation (CNCF), speaking to the fact that developers sticking their toes in the waters of containers, microservices and related DevOps tooling can quickly get overwhelmed when the time comes to move beyond the abstract theory and into a concrete implementation. It's not uncommon for enthusiasm to become beset by analysis paralysis as the number of options available become overwhelming. For this very reason, expect vendor consolidation to become a big trend in the cloud native and DevOps tooling space in the near future.

Simplifying cloud native DevOps tooling

There's an old joke about throwing three software architects into a room to solve a simple problem, and having them come out with four competing solutions. But that old joke has become a cloud-native reality. For example, IT professionals embarking on a cloud native migration need to choose between five very impressive scheduling and orchestration tools, including Kubernetes, Swarm, Mesos, Nomad and AWS ECS. And that's just the orchestration and management piece. Even more DevOps tooling options arise when decisions need to be made about provisioning tools, runtime infrastructure, logging tools, open API management, distributing tracing and so on.

Even the important decision as to which container rutime to use can create consternation amongst cloud native adopters. A significant percentage of the industry hype focuses on Docker. When software architects realize that there are other, equally compelling container runtimes such as containrd, rkt, LXD, hyper_ and the Open Container Initiative, the decision making process becomes significantly more complex.

"The microservices and container based architecture came from web scale companies like Google, Facebook and Twitter," says Aniszczyk, tracking back the roots of cloud native computing. While the big Bay Area behemoths certainly proselytized about the virtues of a microservices based approach to software design, while at the same time open-sourcing key pieces of their systems, they certainly didn't wrap up every inch of their proprietary systems, put a little bow on it, and hand it over to the enterprise software community at large. "Not all of the pieces required to run the way these internet scale companies do are fully open source and integrated well into a single platform," said Aniszczyk.