Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.
'Cloud Native': What It Means, Why It Matters
Cloud native is starting to mean a set of specific things about how business will run on software, Cloud Foundry CEO Sam Ramji explains.
6 Min Read
<p align="left">(Image: Andrey Prokhorov/iStockphoto)</p>
Why Cloud Security Beats Your Data Center
Why Cloud Security Beats Your Data Center (Click image for larger view and slideshow.)
When HP announced July 28 that it was acquiring ActiveState's PaaS business, senior vice president Bill Hilf said it was doing so in part to bridge the gap between traditional IT and "cloud-native applications."
The term "cloud-native applications" is not only finding its way more frequently into announcements, it's also gaining currency as a phrase that sums up where a lot of enterprise developers and operations staff think they are headed. "Cloud native" is not merely a buzzword; it's also enshrined in its own foundation -- the Cloud Native Computing Foundation, launched July 21.
For those unsure of what the term means, here's a primer on why it's the term du jour and why it's often used to sum up a set of goals and priorities that used to be the province of a Google or Facebook.
At the heart of "cloud-native" lie Linux, Linux containers, and the concept of applications assembled as microservices in containers. Indeed, the Linux Foundation launched the Cloud Native Computing Foundation. But cloud-native means a lot more than implementing Linux clusters and running containers. It's a term that recognizes that getting software to work in the cloud requires a broad set of components that work together. It also requires an architecture that departs from traditional enterprise application design. The Cloud Native Computing Foundation is going to try to make it simpler to assemble these moving parts.
[Want to learn more about containers? See Docker Adds Container Networking, Deployment Options.]
That task is daunting enough that Sam Ramji, CEO of the Cloud Foundry Foundation, gave a talk on the meaning of "cloud-native" during the annual Open Source Convention (OSCON) held July 20-24. Ramji is a veteran of fitting dissimilar parts together, having once lead Microsoft's internal efforts at coordinating its code base with open source code and contributing to open source projects. If nothing else, that qualifies him to explain how to avoid some of the pitfalls of what constitutes cloud native.
The Cloud Native Computing Foundation was launched on the heels of the Open Container Initiative, announced June 22, a seemingly overlapping group. Ramji kept hearing people ask why there are so many foundations and how the technologies work together, so he rewrote his OSCON address to answer those questions. And as a result, he said, "I've gotten some of the most positive feedback of any talk I've ever given."
Here are some of the points he made.
Cloud computing relies heavily on open source code; open source has won out over commercial code for next-generation applications, even inside the enterprise. Promising open source projects attract venture capital which encourages a project to form a company that wraps itself around the code and starts to monetize it. "We used to share code, improve it, and build it for reputation's sake," Ramji said in his OSCON keynote. Now an open source project can be an element of competition between startup companies and contributing companies who want to be able to adopt it for their own advantage. Foundations are formed when a project becomes so important that multiple vendors are willing to back it, provided no single one of them controls it. All participants want to move the code to a neutral plane, where they can share in it without one gaining control or competitive advantage. The growth of open source foundations is a result of the larger, direct role that startup economics tends to play in a project without multiple vendors, said Ramji.
One example is Docker, the Linux container company. "Docker has taken over the world," and its success generated unease among developers with other ideas for containers, leading to the well-known competition between Docker and CoreOS's Rocket. IT managers told Ramji they would have to conduct a nine-month project to figure out which one to use. He responded, "that doesn't sound fast" in a business world that has to constantly adjust to changing conditions. "Sometimes competition leads to innovation and sometimes it gets destructive," he told the OSCON attendees. Companies don't want to get bogged down in deciding between competing open source projects. On June 22, Docker and CoreOS both got behind the Open Container Initiative and agreed to adhere to a common container file format and a common runtime to simplify future tasks for enterprise container adopters.
The drive of open source projects today is not simply to create an alternative to commercial code. It's now driven by the need for "continuous innovation," by business needs that can be adapted with frequent software adjustments in any week or even through the space of a day. "Zynga used to say they deployed code 40 times a day. Now Amazon says it deploys code every seven seconds. Why do we do it? We do it to run in the cloud, to connect to any device," to constantly update applications in the cloud to adjust to business needs, Ramji said. There can't be continuous innovation if developers and operations staffs spend much of their time trying to figure out how open source code components will work together. Cloud Foundry, Docker, Kubernetes (the Google-spawned container orchestration system), Mesos (container cluster management used by Twitter, Apple, and Airbnb) and other container projects have continuous innovation as their underlying goal. "If we can bring it all together, if we can work to harmonize Kubernetes and Mesos together, we can re-imagine schedulers as plug-ins," Ramji continued, and use them as they're needed.
Single-vendor open source projects won't behave in this fashion. They'll be run by developers who have been given stock options by venture capitalists to press their momentary advantage. Only multi-vendor projects that are creating a new platform or set of components that work together will have the chance to grow into both a major project and a major force for change in cloud usage, he predicted.
Cloud-native applications are meant to function "in a world of cloud computing that is ubiquitous and flexible." Applications can be developed on a cloud platform, then deployed to different clouds where supporting software stacks will help them run at scale.
Cloud-native applications amount to "prescriptive software stacks" designed to work together for enterprises that are too busy to assemble components themselves, Ramji concluded. To get there, companies will build microservices -- discrete application services -- each running in its own container, then connect them via a network to build the application they want. Cloud native means "rebalancing the roadmap toward user-driven systems" that use standardized parts and follow standardized deployment and operational procedures.
Its proponents will still need to provide more examples of how this set of ideas works in practice, but "cloud native" will enable a constantly shifting software infrastructure that keeps companies oriented toward their customers and able to compete. Since 2000, 52% of the Fortune 500 has turned over, Ramji noted. Continuous innovation and deployment of fresh software is one of the few measures that will keep a company from becoming the next to drop off the list.
For more on Ramji's keynote, view his slides on SlideShare or a video of his talk he published on LinkedIn.
About the Author
You May Also Like
More Insights
