Going Cloud-Native: 6 Essential Things You Need to Know

DZone 's Guide to

Going Cloud-Native: 6 Essential Things You Need to Know

Cloud-native application and architectures are no longer concepts, but real solutions to cloud challenges.

· Cloud Zone ·
Free Resource

Are you just starting on your digital transformation journey and wondering what cloud-native is and why you need it? We just added a new page to our Kubernetes library called "Going Cloud-Native: 6 Essential Things You Need to Know." This article discusses the key takeaways to know about the term "cloud-native." It also describes how you can take advantage of cloud-native capabilities to speed up your development team’s productivity and increase your company’s innovation output.

A Brief History of Cloud-Native

Depending on who you ask, cloud-native can mean a lot of different things. Ten years ago, it was coined by companies like Netflix who leveraged cloud technologies, going from a mail order company to one of the world’s largest consumer on-demand content delivery networks. Netflix pioneered what we’ve come to call cloud-native, reinventing, transforming and scaling how we all want to be doing software development.

With the phenomenal success of Netflix and their ability to deliver more features faster to their customers, companies want to know how they implemented cloud-native technology to gain such a huge competitive advantage.

At its core, the term cloud-native is a way to increase the velocity of your business and a method to structure your teams to take advantage of the automation and scalability that cloud-native technologies like Kubernetes and containers offer.

Cloud-Native Architecture: What Does It Look Like?

Monolith vs. Microservices Architectures

After a disastrous release with a misplaced semicolon, Adrian Cockcroft, former Netflix Cloud Architect shifted their entire architecture from a monolith to microservices.

The problem with a monolithic architecture is that when new features are developed and tested, it takes a considerable effort to deploy those changes to production:

  • Multiple teams are needed to coordinate their code changes.
  • Deploying several features all at once requires a lot of upfront integration and functional testing.  
  • Development teams are restricted to using one or two languages.

The shift to microservices empowered Netflix developers to deliver new features much faster to their customers.

Microservices results in a loosely-coupled, service-oriented architecture with bounded contexts. This means that if every service has to be updated simultaneously, it’s not "loosely-coupled"; and along the same lines, if you have to know too much about the surrounding services then you don’t have "bounded contexts."

See Martin Fowler's and James Lewis's original blog that discusses the definition: “Microservices: A Definition of This New Architectural Term.”

Microservices, Docker, and  Kubernetes

Docker containers lend themselves very well to microservices. By running your microservices in separate containers, they can all be deployed independently and even in different languages, if you wish. Containerization removes the risk of any friction or conflict between languages, libraries or frameworks. Because containers are portable and can operate in isolation from one another, it is very simple to create a microservices architecture with containers and move them to another environment if you need to.

Container Orchestration

Once you have a large number of microservices all running in Docker containers, you need a way to manage or to orchestrate those containers so that they make sense as an application. This is where you need an orchestrator (cluster manager) like Kubernetes or Docker Swarm or others.

At one time in the past, you had to make an informed choice on which orchestrator to use, but now the orchestration wars are won and Google’s Kubernetes came out on top. All of the major cloud providers support Kubernetes with easy-to-install solutions.

The gist of this discussion is that for most companies to be competitive, they have to architect their applications around microservices and run them in a Kubernetes cluster – although some companies do run Docker containers on other orchestrators as well.


With applications running in containers and orchestrated in Kubernetes, the next step is to automate deployments. A continuously automated flow of features is what distinguishes DevOps from other software development philosophies and practices like the waterfall model where development follows an orderly sequence of stages.

Continuous doesn’t mean that engineers are working 24/7 updating code, or that they are deploying updates every time a line of code is changed. Continuous in this sense refers to software changes and new features rolling out on a regular basis through an automated continuous integration and continuous deployment pipeline (CICD). 

More DevOps strategies for building CICD pipelines can be found in Building Continuous Delivery Pipelines.


With containers and microservices, monitoring solutions have to manage more services and servers than ever before. Not only are there more objects to manage, but cloud-native apps also generate a lot of extra data that needs to be kept track of.

Collecting data from an environment composed of so many moving parts is complex. Prometheus is the best modern solution for these dynamic cloud environments. It was built specifically to monitor applications and microservices running in containers at scale and is native to containerized environments.

Cultural Changes

The success of implementing cloud-native technology and DevOps best practices into your organization depends a lot on your existing company culture. Internal teams must not only learn to adopt cross-functional methods that ensure software is iterated on with a continuous cadence, but that it also complements the business goals of the company. Making the actual switch to cloud-native may be the simplest part of your journey; getting those changes to stick and propagating them throughout your organization could well be the most difficult part of the process. 

Learn more about Going Cloud Native and find out: 

  • The benefits for enterprises adopting a cloud-native stack
  • What happens when you put cloud-native strategies into practice
  • The role of the Cloud Native Computing Foundation (CNCF)
  • How cloud-native relates to DevOps

cloud native, docker, kubernetes, microservices, prometheus

Published at DZone with permission of Anita Buehrle , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}