This was first published on the Amalgam Insights site. This year’s KubeCon+CloudNativeCon was, to say the least, an experience. Normally sunny San Diego treated conference goers to torrential downpours. The
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.
Today (August 22, 2019) VMware announced the acquisition of Pivotal. Term “acquisition” seems a little weird here since both are partly owned by Dell. It’s a bit like Dell buying Dell. Strangeness aside, this is a combination that makes a lot of sense.
For nearly eight years now, the concept of a microservices architecture has been taking shape. Microservices is an architectural idea wherein applications are broken up into many, small, bits of code – or services – that provide a limited set of functions and operate independently. Applications are assembled Lego-like, from component microservices. The advantages of microservices are that different parts of a system can evolve independently, updates are less disruptive, and systems become more resilient because system components are less likely to harm each other. The primary vehicle for microservices are containers, that are deployed in clusters to enhance resiliency and more easily scale up resources.
The Kubernetes open source software has emerged as the major orchestrator for containers and provides a stable base to build microservice platforms. These platforms must deploy, not only the code that represents the business logic but a set of system services, such as network, tracing, logging, and storage, as well. Container cluster platforms are, by nature, complex assortments of many moving parts – hard to build and hard to maintain.
The big problem has been that most container technology has been open source and deployed piecemeal, leaving forward looking companies to assemble their own container cluster microservices platforms. Building out and then maintaining these DIY platforms requires continued
investment in people and other resources. Most companies either can’t afford or are unwilling to make investments in this amount of engineering talent and training. Subsequently, there are a lot of companies that have been left out of the container platform game.
The big change has been in the emergence of commercial platforms, based on open source projects, that bring to IT everything it needs to deploy container-based microservices. All the cloud companies, Google especially which was the original home of Kubernetes, and open source software vendors such as Red Hat (recently acquired by IBM) with their OpenShift platform, have some form of Kubernetes-based platform. There may be as much as two dozen commercial platforms based on Kubernetes today.
This brings us to VMware and Pivotal. Both companies are in the platform business. VMware is still the dominant player in Virtual Machine (VM) hypervisors, which underpin most systems today, and are marketing a Kubernetes distribution. They also recently purchased Bitnami, a company that makes technology for bundling containers for deployment. Pivotal markets a Kubernetes distribution as well but also one of the major vendors for Cloud Foundry, another platform that runs containers, VMs, and now Kubernetes. The Pivotal portfolio also includes Spring Boot, one of the primary frameworks for building microservices in Java, and an extensive Continuous Integration/Continuous Deployment capability based on BOSH (part of Cloud Foundry), Concourse, and other open source tools.
Taken together, VMware and Pivotal offer a variety of platforms for newer microservices and legacy VM architectures that will fit the needs of a big swatch of large enterprises. This will give them both reach and depth in large enterprise companies and allow their sales teams to sell whichever platform a customer needs at the moment while providing a path to newer architectures. From a product portfolio perspective, VMware plus Pivotal is a massive platform play that will help them to compete more effectively against the likes of IBM/Red Hat or the big cloud vendors.
On their own, neither VMWare or Pivotal had the capacity to compete against Red Hat OpenShift, especially now that that Red Hat has access to IBM’s customer base and sales force. Together they will have a full range of technology to bring to bear as the Fortune 500 moves into microservices. The older architectures are also likely to remain in place either because of legacy reasons or because they just fit the applications they serve. VMware/Pivotal will be in a position to service those companies as well.
VMware could easily have decided to pick up any number of Kubernetes distribution companies such as Rancher or Platform9. None of them would have provided the wide range of platform choices that Pivotal brings to the table. And besides, this keeps it all in the Dell family.