Cloud native adoption means getting the DevOps tooling right

There are so many DevOps tooling options in the world of cloud native computing that many companies looking at a microservices and container based architectures are being overwhelmed by the options.

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 Development 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.

The challenge of cloud native configuration

So where does that leave the rest of the software development community in terms of DevOps tooling and adopting a cloud native strategy? Sadly, it leaves them holding a tub valve, a P-trap and a wrench. "The challenge of the future is getting all the plumbing right," said Aniszczyk. "Getting the pieces to fit together is where vendors are going to provide value. Stitching them together into a cohesive unit that is useful for application developers is huge. That's where companies are competing now." 

In pushing the cloud native computing game forward, CNCF has welcomed a number of DevOps tooling projects under their umbrella, including  the containerd runtime, Kubernetes as the container orchestration tool, linkard and gRPC as service management tools and opentracking, fluentd and prometheus for tracking, logging and monitoring. But there is a big divide between steering these projects as they grow and actually delivering a complete, cloud native suite that installs with one click of the button and takes care of every aspect of the application lifecycle management (ALM)  process from DevOps integration to software policy governance.
"You already see RedHat doing this with OpenShift," said Aniszczyk. "Other companies are getting into this space, making it easier for people to deploy their apps on a dynamically orchestrated platform. Having companies within our ecosystem essentially stitch together and build out a distribution or PaaS to make cloud native adoption easier is key."

Pitotal is making great inroads in the Java cloud space with their Cloud Foundry offering. IBM is pushing in this direction with their BlueMix offering, and Oracle has a number of PaaS offerings that are being shoehorned into this space, but to this date, there is no clear leader in this space, and plenty of room for a new, potentially unfamiliar name to emerge. But the cloud native landscape is indeed changing, and once the plumbing problem is more completely addressed, expect cloud-native adoption to accelerate rapidly.

Ref: http://www.theserverside.com/feature/Key-to-future-cloud-native-adoption-is-getting-the-plumbing-rightf