IBM Takes a Big Step Toward Cloud-Native

Everyone talks about cloud-native, but like the weather, nobody seems to be able to do much about it.  In fact, the interest in the concept often seems so abstract that you could argue “cloud-native” is a state of mind.  It’s not, of course, but clearly something is missing between the raising of the interest profile, even at the CIO level, and realizing the goal in real deployments.

If you’ve followed my blog, you know that it’s been my view that applications for the cloud have to be developed within an ecosystem of middleware and tools that create a kind of virtual operating system.  Applications are then written for it, and because they obey rules that were designed to impose cloud-native principles and exploit the cloud’s unique capabilities, they’re “cloud-native” out of the box.  We’ve known for a year or more that containers and Kubernetes were the foundation of this virtual operating system, the “Kubernetes ecosystem” I’ve mentioned from time to time.  We’ve also known that more was needed, and IBM is now stepping up with what might be the most organized attempt to define that virtual operating system that’s come along.  It’s called “Kabanero”.

Out of curiosity, I tried to see if the name meant anything clever.  It sounds Spanish, but Google’s translate says it’s Maori for “diagnosis”.  I don’t think IBM had that in mind, so I’ll leave it to IBM’s PR people to come up with the meaning, if there is one.  Meanwhile, let’s look at the concept itself.

Kabanero is a Kubernetes ecosystem designed to facilitate the development of containerized, cloud-native, applications.  Besides Kubernetes, it includes Knative, Istio, and Tekton, three new open-source projects (Codewind, Appsody, and Razee).  For those who don’t know the details of the first three, Knative is a scale-to-zero “serverless” Kubernetes extension, Istio is a service mesh, and Tekton is Kubernetes-centric CI/CD kit.  Of the new elements, Codewind is a container-friendly IDE extension for popular development environments like Eclipse, Appsody is a framework for creating and managing runtime stacks for containerized applications and a repository for popular stacks, and Razee is a multi-cluster at-scale Kubernetes distribution/deployment framework.

All of this is hard for non-developers (and even some developers) to get their heads around.  Remember, though, that the goal of Kabanero is to provide a complete virtual operating system that makes the cloud look like a computer, with special features like scalability and resiliency.  It enforces practices on developers to exploit those features, and it operationalizes the results to reduce the inconsistencies in deployment and application operations that would inevitably creep in if every developer were to approach containers and cloud-native in their own way.

This is a major step forward for containerized apps and cloud-native, because of that creeping disorder and inconsistency.  If we go back to the old days of computers, we’d come to a time when there was no standard disk I/O, no middleware or operating system tools.  Imagine how difficult it would be today to deal with data harmony in a major interreactive enterprise if every application that needed relational database capability created its own model.  Not only would writing applications have been incredibly complex, running them properly would have been an almost-insurmountable challenge.

RDBMS would have languished without a common model.  Cloud-native would do the same, so what this is going to do is unleash cloud-native, create a pathway to the goal and not just a PR slogan.  This raises two questions.  First, what will unleashed cloud-native actually do, and mean?  Second, why is IBM making such a big move here?

The biggest fallacy in cloud computing was the notion of “migrating to the cloud”.  Yes, there are some applications that under-utilize server resources enough that public resource pools could save money for their users overall.  Yes, there are some users who can’t maintain their own data center resource pools properly for lack of access to the skilled workforce involved.  Both these are limited opportunities.  The benefits of the cloud require you write applications for them, not move applications to them.

What we’ve seen so far in cloud computing is a combination of two things—enterprises who are able to build new application front-ends using cloud principles, and startups who needed cloud properties from the first and pulled together the tools needed to build real cloud-native behaviors.  Kabanero could mainstream cloud-native.

The first thing that will do is revolutionize application development.  Most of the code run today was designed on principles that were already old when the cloud came along.  Cloud-native will require that we redo that, rethink all the application architecture, design, and operations principles we’ve lived with for decades.  How revolutionary is this?  Recall my criticisms of operator transformation projects like NFV and ONAP.  These projects needed cloud-native thinking, and they’re either in big trouble or will be because they didn’t have it.  But going back to redo all that stuff in cloud-native form will be very difficult at this point.

Application development here means more than just software architects and programmers churning out code.  The tools needed for development in a cloud-native world are different, as the components of Kabanero show.  Application lifecycle management, continuous integration and delivery, service discovery, scalability, resiliency, DevOps, GitOps, and just about everything else we know today will be impacted by cloud-native.

The second thing this will do is revolutionize the cloud.  Cloud providers today have tended to create their own framework for cloud-native, on the simple theory that this would differentiate them during cloud consideration and lock users in once code was developed.  A uniform framework for cloud-native will eventually force cloud providers to adopt it.  Don’t believe that?  Look how quickly everyone’s managed container services have become managed Kubernetes services.

Is this bad for cloud providers, then?  In a sense, perhaps, because it means not only that differentiation among public cloud providers will be more difficult, but also that competitors who’ve not made the top tier (like, obviously, IBM) will have a shot.  But the total value of incremental cloud services that cloud-native could drive approaches a trillion dollars per year, so a little jostling for the market won’t offset the fact that there’s going to be a lot more market to jostle for.

The third result of cloud-native is the death of the machine.  Virtualization all too often has locked us into a historical backwater instead of freeing us.  NFV created virtual devices to build networks with, and so built the same kind of networks we had all along.  Virtual machines were just as operationally complex and as inflexible as real machines.  Containers are different.  They’re an abstraction of what you run, not what you run on.  If the cloud world is virtual, containers are the closest thing we have to creating it, because they don’t constrain it.

Forget VMs, IaaS.  The future is containers and container hosting.  That’s the net message of Kabanero, and that’s what IBM is clearly banking on.

This could actually be a very smart move for IBM, one I must admit I hadn’t expected.  In a tactical sense, Kabanero links an open, pan-provider, framework for cloud-native to IBM’s still-strong-and-with-Red-Hat-stronger position in development.  If IBM makes Kabanero work, they erode the benefit of being one of the Big Three in the cloud, because anyone who can host Kabanero can win the largest piece of the cloud pie.

In a strategic sense, this could be even bigger.  I learned programming on an IBM computer, and for most of my career in software development, architecting, and management, I looked at IBM as the thought leader.  Up to about a decade ago, they were the unchallenged leader in strategic influence on enterprise IT.  It made them a boatload of money, and they threw it away.

Kabanero could get it back for IBM.  Add in the Red Hat dimension, which further improves the base of businesses that IBM could expect to influence with Kabanero, and you have what might be a really compelling story.  Will it be, though?  IBM has done great things and dumb things, and for sure the trend over the last decade has been toward dumbness.  They could still mess up both Red Hat and Kabanero, and I think if they do, they’ve probably lost forever.  They could also get it right, and if that happens, we might see a revival of those old IBM notepads embossed with the single word “Think”.  For sure, it’s about time somebody started doing that, and for that start alone I applaud IBM’s efforts.