Archive for Change

Looking at Microservices, Containers, and Kubernetes with 2020 Vision

Kubernetes Icon

Some years are easy to predict than others. Stability in a market makes tracing the trend line much easier. 2020 looks to be that kind of year for the migration to microservices: stable with stead progression toward mainstream acceptance.

There is little doubt that IT organizations are moving toward microservices architectures. Microservices, which deconstruct applications into many small parts, removes much of the friction that is common in n-Tier applications when it comes to development velocity. The added resiliency and scalability of microservices in a distributed system are also highly desirable. These attributes promote better business agility, allowing IT to respond to business needs more quickly and with less disruption, while helping to ensure that customers have the best experience possible.

Little in this upcoming year seems disruptive or radical; That big changes have already occurred. Instead, this is a year for building out and consolidating; Moving past the “what” and “why” and into the “how” and “do”.

Kubernetes will be top of mind to IT in the coming year. From its roots as a humble container orchestrator – one of many in the market – Kubernetes has evolved into a platform for deploying microservices into container clusters. There is more work to do with Kubernetes, especially to help autoscale clusters, but it is now a solid base on which to build modern applications.

No one should delude themselves into thinking that microservices, containers, and Kubernetes are mainstream yet. The vast majority of applications are still based on n-Tier design deployed to VMs. That’s fine for a lot of applications but businesses know that it’s not enough going forward. We’ve already seen more traditional companies begin to adopt microservices for at least some portion of their applications. This trend will accelerate in the upcoming year. At some point, microservices and containers will become the default architecture for enterprise applications. That’s a few years from now but we’ve already on the path.

From a vendor perspective, all the biggest companies are now in the Kubernetes market with at least a plain vanilla Kubernetes offering. This includes HP and Cisco in addition to the companies that have been selling Kubernetes all along, especially IBM/Red Hat, Canonical, Google, AWS, VMWare/Pivotal, and Microsoft. The trick for these companies will be to add enough unique value that their offerings don’t appear generic. Leveraging traditional strengths, such as storage for HP, networking for Cisco, and Java for Red Hat and VMWare/Pivotal, are the key to standing out in the market.

The entry of the giants in the Kubernetes space will pose challenges to the smaller vendors such as Mirantis and Rancher. With more than 30 Kubernetes vendors in the market, consolidation and loss is inevitable. Expect M&A activity in the Kubernetes space as bigger companies acquihire or round out their portfolios. Kubernetes is now a big vendor market and the market dynamics favor them. There’s plenty of value in the smaller firms but it will be too easy for them to get trampled underfoot.

If there is a big danger sign on the horizon, it’s those traditional n-Tier applications that are still in production. At some point, IT will get around to thinking beyond the shiny new greenfield applications and want to migrate the older ones. Since these apps are based on radically different architectures, that won’t be easy. There just aren’t the tools to do this migration well. In short, it’s going to be a lot of work. It’s a hard sell to say that the only choices are either expensive migration projects (on top of all that digital transformation money that’s already been spent) or continuing to support and update applications that no longer meet business needs. Replatforming, or deploying the old parts to the new container platform, will provide less ROI and less value overall. The industry will need another solution.

This may be an opportunity to use all that fancy AI technology that vendor’s have been investing in to create software to break down an old app into a container cluster. In any event, the migration issue will be a drag on the market in 2020 as IT waits for solutions to a nearly intractable problem.

2020 is the year of the microservice architecture. Even if that seems too dramatic, it’s not unreasonable to expect that there will be significant growth and acceleration in the deployment of Kubernetes-based microservices applications. The market has already begun the process of maturation as it adapts to the needs of larger, mainstream, corporations with more stringent requirements. The smart move is to follow that trend line.

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.