Archive for Change

Canonical Takes a Third Path to New Platforms

This was originally published on the Amalgam Insights website.

We are in the midst of another change up in the IT world. Every 15 to 20 years there is a radical rethink of the platforms that applications are built upon. During the course of the history of IT we have moved from batch-oriented, pipelined systems (predominantly written in COBOL) to client-server and n-Tier systems that are the standards of today. These platforms were developed in the last century and designed for last century applications. After years of putting shims into systems to accommodate the scale and diversity of modern applications, IT has just begun to deploy new platforms based on containers and Kubernetes. These new platforms promise greater resiliency and scalability, as well as greater responsiveness to the business.

As is often the case with new technology, Kubernetes and container platforms began as a decidedly DIY affair. Over time, however, software vendors have begun to craft curated platform experiences for sale. The DIY platform is a customized experience but difficult and expensive to engineer; the vendor curated platform is much easier but has more constraints. These are typical tradeoffs seen in any emerging platform environment. Curation reduces risk and degree of difficulty but at the expense of choice. DIY has ultimate choice but requires additional personnel costs, not only to build but to support and maintain the platform. These are the two paths open to IT shops looking to Kubernetes and containers to solve the problems of their 21st century applications.

Canonical, however, is creating a third path to new platforms. At the Canonical Analyst Day (September 12, 2019) in New York City, Canonical CEO Mark Shuttleworth articulated a different vision for Kubernetes platforms than is typically expressed by vendors. Based on their Juju and Charms toolset, Canonical hopes to offer the benefits of the curated experience and the flexibility of the DIY. With Charms, Canonical hopes to encapsulate best practices and integrations, in effect curating the parts. Instead of combining these into a set platform, they are offering Juju as a way to combine these parts, Lego like, into a custom platform. Charms describes what the software should be; Juju says where the software should go. At the component level, Charms knows how to configure, provision, and deploy a piece of software while Juju knows the existing infrastructure and where a Charmed component can and should go.

So, why a third path? The most obvious benefit is flexibility. Most platform plays assume that you will want what they have already tested and integrated. Simplicity is the byword since complexity is harder to do and support. If the platform vendor has integrated Istio and Envoy for the service mesh, that is what is supported. If IT’s platform engineers believe Linkerd makes more sense, they now have the responsibility for figuring out how to integrate it and manage its deployment. It’s a simple trade off – the cost of engineering versus the constraints of pre-determined components. While this works for a lot of applications, there are plenty where deviation from the platform is called for. The third path that Canonical is envisioning changes that dynamic. It provides the advantages of DIY with the advantages of the curated platform. This is not to say that DIY or curated platforms are wrong. For many companies, one or the other works for them. Not all IT environments, however, can go in the two common directions. They lack the resources to build their own platforms from scratch but need more flexibility than a standard platform can give them. They need purpose-built platforms at standardized pricing. This is where the third path becomes valuable.

It’s not at all unexpected that Canonical would take a path that diverges from the pack. This has been their modus operandi since the very beginning. The Charm-Juju experience is just another example of Canonical refusing to accept the status quo and, instead, looking for a way to forge a different trail through the woods of IT.

The View from KubeCon+CloudNativeCon Seattle

Kubernetes Icon

Containers and Kubernetes Become Enterprise Ready

In case there was any doubt about the direction containers and Kubernetes are going, KubeCon+CloudNativeCon 2018 in Seattle should have dispelled them. The path is clear – technology is maturing and keeps adding more features that make it conducive to mission critical, enterprise applications. From the very first day the talk was about service meshes and network functions, logging and traceability, and storage and serverless compute. These are couplets that define the next generation of management, visibility, and core capabilities of a modern distributed application. On top of that is emerging security projects such as SPIFFE & SPIRE, TUF, Falco, and Notary. Management, visibility, growth in core functionality, and security. All of these are critical to making container platforms enterprise ready.

If the scope of KubeCon+CloudNativeCon and the Cloud Native Computing Foundation (CNCF) is any indication, the ecosystem is also growing. This year there were 8000 people at the conference – a sellout. The CNCF has grown to 300+ vendor members there are 46,000 contributors to its projects. That’s a lot of growth compared to just a few years ago. This many people don’t flock to sinking projects.

Despite all the growth in ecosystem and capabilities, there were still a fair number of container-curious people who were at KubeCon+CloudNativeCon. Their companies sent them to KubeCon+CloudNativeCon because they just beginning to explore containers and Kubernetes. They had a lot of questions about the viability of containers and microservices in their more demanding environments, especially regulated environments. Many of the questions I was asked, especially about visibility within clusters and security, were important discussion points. Some of the doubts were a smokescreen for organizations that resist change. It was obvious that they were looking for an excuse to stick with old ideas.

Another issue holding back container architectures is confusion in the market. CloudFoundry, serverless platforms, and Kubernetes platforms overlap and use similar technology, namely containers. Since vendors will often present these as competing platforms, depending on what they sell, it presents the market as more fragmented then it is. Even within technologies there is a lot of confusion. Take serverless computing. Ask ten people what serverless is and you will get eleven different responses. Some vendors want to make it a marketing label they can slap onto anything to make it shiny and new. This makes life very confusing for an enterprise IT professional trying to design next generation applications.

Some of this confusion is just an artifact of a lifecycle problem. Five years ago, there were several competing container formats from Docker, Rancher, CoreOs and others. That has changed. Containers have coalesced around a common image format. Container engine vendors are no longer competing on the basics but on performance and security layered over standard runtimes such as containerd.

No one is advocating change for the sake of change. We are at a point, however, where the demands of modern applications require a new architecture. Kubernetes represents an excellent platform for highly distributed applications where portability, performance, and development lifecycle problems are easily managed. The future of containers and Kubernetes as the base of the new stack was on display at KubeCon+CloudNativeCon and it’s a bright one. Expect to see more enterprise applications that rely on rigorous architectures to be Kubernetes.