It seems like just yesterday we were reading about how everything was going to migrate to the cloud. Now we’re hearing that companies like IBM are launching major initiatives to promote cloud-native development. If everything’s migrating to the cloud, why do we need to develop anything “natively” for it? If we do need to, what would such a development look like? Is cloud-native just another hype wave in the making?
To start with the obvious, everything was never going to “migrate” to the cloud. Migration means move as-is, and the cloud could never have absorbed more than a quarter of computing tasks, even if we moved every application for which cloud hosting could deliver decisively lower TCO. It’s not reached that point, or even half of it, yet.
Playing to the Cloud’s Benefits
What the cloud needs, and has always needed, is a set of applications that were written to maximize the cloud’s unique benefits, things like scalability, agility, resiliency, and global distributability. Move a monolithic server app to the cloud and you have a cloud-hosted monolithic server app, and you’re paying for resources and for the cloud provider’s profit margin too. Write apps for the cloud and you can get real benefits. Today, most cloud provider revenue comes from cloud-native apps written by specialty startups. We need to make cloud-native mainstream to make the cloud mainstream.
Who’s writing this stuff today? It’s social media companies, content companies and other Web startups. Launched with a clean slate, they’ve not only laid out the principles of cloud-native, they’ve created many of the key pieces of software infrastructure you need for cloud-native development. Their tools and techniques are often open source and increasingly available. If enterprises can get their arms around cloud-native and these tools, it could be (as they say) “huuuuuugh!”
Our tools start with something practically everyone in IT has heard of --
containers and
Kubernetes. It’s common to think that containers are just a kind of lightweight virtual machine, one that doesn’t quite have the security and application isolation of a VM. That’s not true either. VMs are virtual machines, but containers are more like virtual workloads. Perhaps the most important piece of cloud-readiness is to disconnect work from the specifics of hosting, and containers do that.
You can’t have work floating around looking for a place to be done, of course. Kubernetes is an orchestrator, meaning it’s a software tool that’s designed to match up that portable work with a pool of resources. You can deploy something, redeploy if it breaks, scale it, and so forth, and Kubernetes can organize that for you. It’s orchestration in general, and Kubernetes in particular, that make it possible to juggle the pieces of cloud-native applications.
Getting in the Middle of Things
Orchestration is a necessary condition for cloud-native, but not a sufficient condition. Getting the portability and scalability we want means creating an execution framework, one that can perform load balancing when we scale, redirect connections when we replace something, and recover resources when peak periods pass. If every cloud-native app took its own path to securing the benefits, the result would be expensive parallel development and chaotic operations. “Middleware” tools can provide these capabilities in a uniform way, to everyone’s benefit, and most of our cloud-native focus these days is on collecting the right middleware tools.
Most of the recent attention in the cloud-native space has focused on the tools used in deployment and application lifecycle management, things like pushing changes out when new features are added. This is great, but it still leaves the problem of how you actually build a cloud-native application and its components. We’ve already had a couple issues emerge to illustrate the problem. One is the “multi-cloud” problem and the other is the way to handle “serverless.”
Should orchestration treat data centers and any public cloud resources as parts of a single resource pool, or as separate hosting pools? Today, containers and Kubernetes tend to take the latter approach, but sentiment is shifting toward a “federation” model in which all hosting is coordinated no matter what you host on. Similarly, serverless computing today is seen as its own kind of specialized cloud development, mostly supported by the public cloud providers. That view is shifting in favor of a model where serverless is simply a “scale-to-zero” version of cloud-native scalability. We need to accommodate the new approaches quickly and in a uniform way, and track new things as they come along.
All Framed Up
In all, realizing cloud-native potential instead of just saluting the term means creating and organizing that middleware framework, and that’s something that’s really become clear only within the last year or so. Vendors like Google, IBM, and VMware, and all the major public cloud providers, have been quietly expanding their tools to address all the essential pieces of cloud-native application development and operations. Now, in 2019, we’re getting some results. Google promotes its
Anthos as a hybrid and multicloud strategy, but it’s really a cloud-native framework. So is IBM’s
Kabanero.
What’s going to make cloud-native real isn’t the fact that it’s actually a great idea, even one essential to our taking the next great step in information technology. It’s that we’re finally starting to see complete frameworks to build and deploy cloud-native applications. It’s been hot, but now it’s practical. So yes, there’s something to cloud-native and you’ll want to pay attention as it presents itself.
