Cloud-Native Software: What it Is, How We Got Here, and Why it Matters

Here’s a fun game to play with your tech industry friends. Next time you’re in a group waiting for an elevator or in line to get coffee, ask, “What does ‘cloud-native’ mean?” You might be surprised by the range of responses you get, even among savvy technologists. Something that’s “born in” the cloud? Designed specifically for the cloud? Yes, to both, but those answers barely scratch the surface of what cloud-native encompasses. The full answer is a surprisingly far-reaching tale, stretching back to early computing systems and encapsulating just how far we’ve come. At the same time, the journey to cloud-native software is more relevant to current business considerations than a simple history lesson. If you’re involved in managing or purchasing applications for your organization, knowing what it means when software is cloud-native—and when it’s not—can make a huge difference for your business.

Setting the Scene

To begin our journey, let’s go back to the infancy of modern computing. Specifically, to 1975, on a plane traveling to Albuquerque, where a young Paul Allen is furiously scribbling on some paper. Allen is on his way to meet with executives at MITS, an early microcomputer company, to pitch the Original Posteople/606-bill-gates.html?start=1" target="_blank" rel="noopener" shape="rect">BASIC interpreter that he and Bill Gates have written for the Altair 8080. If he seems a bit rattled, it’s because he’s just realized that his program is written on paper tape (an early form of storage), and he has no way to actually load it into the computer’s system memory.

Don’t worry; this story has a happy ending. Realizing his oversight, Allen quickly writes a bootstrap loader routine before settling in for a nap. The solution works, the investors are impressed, and the rest is history. But this isn’t just an anecdote from the early days of Microsoft; there’s an important lesson here about just how much computing has changed.

Allen’s mistake was forgetting how “aggregated” software had to be back then. Applications were written as monolithic, self-contained entities. Coders had to include steps for assembling all the routines and resources necessary to run the program as if instructing a system that had never run one before. You couldn’t assume that even basic tasks would be available as preprogrammed standard functions because those didn’t exist. You had to code out every step, every time.

Cloud-Native Origins

Fast forward 40 some years, and we’ve swung to the other end of the spectrum. Computing infrastructure is now fully disaggregated from individual applications and managed as an independent utility. So are storage and networking. Instead of having to spell out every step in assembling those resources in every application, developers can just call on them as pre-existing services available on demand.

Are these characteristics starting to sound familiar? They should because they’re the essence of the cloud. Thanks to disaggregation, applications can now use pre-existing public cloud infrastructure as a service, consuming only what they need and paying for only what they use. Yet disaggregation goes even further.

Today, applications themselves are getting broken up into ever-smaller, individually packaged functions (microservices) designed to run on standardized cloud architectures. Now, applications can access not only cloud infrastructure but dozens, even hundreds of disaggregated cloud services for a variety of common functions. Instead of having to code out instructions for handling things like scaling, load-balancing, recovery, and more, developers can simply invoke pre-existing cloud services. And as more applications get written for the cloud, the menu of available services keeps getting longer.

Naturally, this change has had a huge impact on how software gets written. Monolithic applications that take years to develop and encompass millions of lines of code are becoming obsolete. Instead, developers can build lightweight applications (often just a few hundred lines of code), written explicitly to use common cloud services. If you haven’t guessed yet, these lightweight applications, designed from the ground up to use cloud architectures and services, are what’s meant by cloud-native.

The Cloud-Native Advantage

The ongoing disaggregation of software can seem complicated on the surface, but the advantages are easy to understand. By writing and using cloud-native software, organizations benefit from:

A Final Word on Cloud-Native

The huge gains in efficiency, productivity, cost-savings and more that come with cloud-native applications are extremely attractive to developers and businesses. It’s the reason we hear so much about cloud-native applications in the first place. But remember, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver these benefits.

It’s also important to recognize what cloud-native is not. It’s not an application that’s simply hosted in the cloud. It’s entirely possible to take a monolithic traditional application, package it up in a great big virtual machine (VM), and host it on public cloud servers. Indeed, plenty of companies do that with aging legacy applications. But those applications have not magically become cloud-native. They won’t deliver the elasticity, agility, and other benefits of real cloud-native applications. And if you actually need those attributes, you might be in for a painful re-factoring process to get them.

No matter what kind of applications you’re evaluating, it never hurts to step back and appreciate how far we’ve come. If nothing else, you’ll never have to worry about finding yourself on the way to an important sales pitch, trying to figure out how to tell a computer how to load software.