Cloud-native applications is a relatively new term that has been spurred by a relatively new technology. For an application to be cloud native, it needs to be broken down into microservices that run independently from each other and also be decoupled from any physical resources. With the absence of any physical resource, cloud-native apps need to in turn depend on cloud computing frameworks, which in essence are loosely coupled cloud services. These cloud services that allow applications to be broken down into microservices and packaged in containers are predominantly open source. Some of the leading tools in this movement like Kubernetes, Prometheus, and gRPC are part of the CNCF (Cloud Native Computing Foundation). So in other words, the CNCF is a collection of open-source tools that enable modern cloud-native applications.
Cloud native refers to applications that are “container-packaged, dynamically scheduled, and microservice oriented,” and though it’s tempting to think of cloud native as just about containers and clusters, on closer examination it’s about a lot more. CNCF is part of the Linux Foundation and was announced in July 2015 to advance the state-of-the-art for building cloud-native applications and services. Though it was originally founded to bring some order to the world of Kubernetes, it has since grown into a managed and curated group of nine promising open-source projects that are essentially everything you need to enter the world of containers and microservice architecture. Founding members include, Google, Huawei, Mesosphere, CoreOS, Docker, Twitter, RedHat, and IBM, just to name a few.
Speed, freedom, and trust
“Speed, freedom and trust” is what Alexis Richards, CEO of Weaveworks, says cloud native is all about, and though open source has won the war against commercial code even on an enterprise level, vendor lock-ins are still not unheard of. Vendor lock-in occurs when public cloud vendors ship open-source tools by wrapping them up into services that are not portable between clouds, and don’t integrate well with other important tools that make up the software development stack. In the era of containers where portability is everything, cloud-native applications need to be cross-compatible, and that’s one of the core principles of the CNCF. While the CNCF curates and promotes a trusted toolkit for modern architecture, it’s quite opposed to vendor lock-in and makes sure that all applications are compatible across all platforms.
Speed of releases
One of the earliest examples of a cloud-native application on a web scale with high availability is Netflix, and they did it at a time when people were still ordering DVDs in the mail and live video on-demand was unheard of. The two things they focused on were high availability and the rate at which they improve their services. Both these characteristics are key to what cloud-native applications are supposed to be. Availability is what the cloud is all about, and releasing updates at a frantic pace is at the center of the DevOps methodology as well the focus of most modern day applications.
Freedom to switch vendors
To emphasize this point more, it would be quite a letdown if you built a tool to a point where it’s almost working perfectly in Azure, but you find out that you can’t easily move to AWS if you wanted to. Now you may not want to move to AWS, but vendor lock-in — or now cloud lock-in as we are calling it — is one of the main enemies the Linux Foundation and open-source community were built to fight against. One of the mantras of the CNCF is that “anyone should be able to use any software on any cloud.” This is at an app level because people want to be able to use their apps anywhere. Open-source tools that are not cross-platform capable are not really open source and confine a user. This is the opposite of freedom.
Trust between contributors
As mentioned before, the CNCF was originally formed as a home for Kubernetes and was founded by the Linux Foundation, which is responsible for safeguarding Linux. The CNCF was originally formed to combat the problem of enterprises wrapping services around open-source code (Kubernetes) in order to monetize it. Now, for an open-source project to earn the trust of the enterprise, it needs to be backed by a foundation of vendors where no single one controls it or has a majority interest. This is why it’s important that open-source projects are run by multiple organizations and not just one vendor so there are no “kingmakers” or no one company that has an undue influence. This helps breed long-term trust as a single corporation could disappear overnight, and then you’d essentially be left with a useless tool.
Multiple vendor open source
The consensus here is that to meet the needs of today’s ever-demanding cloud market competitively, it requires a community from all parts of the world and all walks of life. This has been demonstrated repeatedly by the success of a number of open-source projects like Kubernetes, Prometheus, OpenTracing, FreeCAD, Apache Spark, Git, and the like. Single vendor open-source projects are more than likely to be run by developers with an agenda that comes from the venture capitalists backing them while multivendor projects are more likely to create tools purely for utility and performance.
While communities and foundations of the past were often about standards and protocols, this is extremely difficult with cloud-native applications. This is because the industry is not only young, but also riding on the edge of modern technology, with changes and breakthroughs happening every month. In contrast to traditional foundations, however, the CNCF is not about setting standards or deciding what things should look like five years from now, because, frankly, that’s impossible. It is, however, about the entire community getting behind a few open-source projects that they feel have potential and are useful in the shift to the cloud. Right now they have nine projects: Kubernetes, Prometheus, OpenTracing, Fluentd, Linkerd, gRPC, CoreDNS, containerd and rkt. What’s interesting and something they all have in common is that they’re all cross-compatible and can work with each other even though they’re all independent.
The home-cloud advantage
With regards to what cloud-native applications mean today, they signify applications with an unprecedented level of portability and agility. The word native means “home-turf,” which signifies a home-team advantage, and that’s what cloud nativity is about, an application running on its home ground with significant advantages. One of the advantages of being the home team is you’ve got the backing of the entire city. Cloud-native applications are not just running on their own but based on tools and applications that come with the backing of the biggest names in the enterprise like Cisco, Red Hat, IBM, Google, Intel, Docker, and Dell.
Cloud native now refers to that cutting-edge technology where each and every single microservice that your application is broken down into is running separately, efficiently, at its maximum potential and is supervised by experts. It really doesn’t get more “divide and conquer” than containers, since we’re essentially breaking down our problems into nice, tiny, neat portable packages that are easier to deal with. What cloud native actually does for developers is give them the tools to make sure their apps run anywhere, any place, anytime, smoothly, economically, and efficiently. What we’re essentially doing is maximizing our potential in terms of not only how we deliver code, but how we do everything else, like monitoring and logging that goes along with it. If each and every microservice is running on an open-source multivendor tool that’s always being updated and worked on by enterprise giants as well as a huge open-source community, there’s not a lot that can go wrong.
Photo credit: Wikimedia