Making Sense of Cloud Native Applications, Platforms, Microservices, and More


As more and more of our infrastructure moves into the cloud, the proliferation of buzzwords, new terms, and new ways of doing things can be daunting. Fabio Chiodini, Principal System Engineer at EMC, spent some time helping us make sense of these concepts during his LinuxCon Europe talk, “Cloud Native Applications, Containers, Microservices, Platforms, CI-CD…Oh My!!”

Fabio started by talking about the companies that are transforming their industries. We naturally think about the “unicorn” companies from Silicon Valley:

  • Netflix in the $53 billion entertainment industry
  • Square in the $6 billion financial services industry
  • AirBnB in the $26 billion hotel industry
  • Tesla in the $34 billion automotive industry
  • Uber in the $50 billion transportation industry
  • Nest in the $3.2 billion industrial products industry

But, the transformation is not restricted to the new and emerging Silicon Valley companies, traditional enterprise customers are delivering software in similar ways:

  • Lockheed Martin using Spring Framework with Pivotal Cloud Foundry as a cloud native Platform
  • Kroger adopting DevOps practices with a Pivotal Cloud Foundry automated build pipeline
  • Mercedes-Benz working on connected cars and smart apps
  • Bosch creating an IoT suite

Fabio defines cloud native applications as “applications that do not require resilient infrastructure,” which is a more concise version of Duncan C. E. Winn’s definition from his Cloud Foundry book, “Cloud native is a term describing software designed to run and scale reliably and predictably on top of potentially unreliable cloud-based infrastructure. Cloud native applications are purposefully designed to be infrastructure unaware, meaning they are decoupled from infrastructure and free to move as required.” However, Fabio also admits that there are many different definitions depending on what aspect of cloud someone is focused on.

If you look at the application lifecycle, Fabio talks about how some of these concepts fit together starting with microservices in the design phase moving from monolithic tightly coupled applications to loosely coupled components where each on can be deployed in an automated fashion without waiting on other components. In the deploy phase, he talked about Continuous Integration (CI) / Continuous Deployment (CD) moving from infrequent releases to releasing early and often resulting in a higher quality of code as bugs are fixed and deployed to production more quickly rather than sitting unfixed between releases. In the manage phase, a DevOps mindset is helping people move from disconnected tools and opaque processes to one of shared responsibility with common incentives, tools, process and culture. 

He discussed how this results in “new requirements for IT to deploy and deliver applications reliably at scale,” putting the focus on flexibility over reliability. He broke this down into four cloud native platform requirements:

  • Programmability: “Infrastructure As Code”
  • Elasticity: make it easy to scale
  • Economics: affordability with standard servers and software
  • Strong Instrumentation And Telemetry: metrics and monitoring of the infrastructure layer

Fabio also included a few demos to illustrate these concepts, which can be found in his ProjectSpawnSwarmtc and ReceiverCF GitHub repositories.

There are clear and solid business needs for cloud native applications with many options and technologies available. A structured approach with a simplified, flexible infrastructure offers many advantages for companies moving to cloud native applications.