Quura Pixel

DevOps Institute

Microservices: Three Basic Truths

Containers, Culture and Human Skills, DevOps Basics

Microservices: Three Basic Truths

By: Tracy Ragan, CEO and Co-Founder of DeployHub.

November 30, 2020

Moving from a monolithic architecture to a microservice architecture is a big deal. It is not just a ‘shift,’ it is a tsunami.  Understanding what is required to make the shift is broad.  Developers need to start thinking about how they are going to break up monolithic applications into smaller functions, Operation Teams must build out an entirely new approach to the datacenter around Kubernetes and containers, and DevOps Engineers must start evaluating existing pipelines and what needs to change to support hundreds of independent moving parts from dev through prod.

Learn Kubernetes-It’s Easier Than You Think!

What are microservices?

The core of understanding microservices is how they are written and deployed.  They are small functions that are independently deployed. Your traditional ‘application’ is lost in a sea of services that make up a ‘logical’ application.  Microservices give us the ability to write an entirely new generation of software.  They make AI and ML a possibility while also creating a platform for highly scalable software at a fraction of the cost compared to monolithic solutions. Make no mistake, the journey is worth the effort.

The Microservices Journey

With any new journey, there is disruption, and microservices are no different.  And honestly, this disruption is welcome and can be overcome if we can understand both the changes required and similarities a microservice architecture has compared to monolithic.  We have gone through big shifts in the past, mainframe to distributed for example, and we not only survived, but we also thrived. And like the shift from mainframe to distributed systems, microservices disrupt the way we write and deliver code.

While there are many discussions you will have within your organization about microservices, consider these three basic truths:

  1. Microservices do not require a traditional ‘build’ step. Linking is not done at the CI build, it is done at runtime via APIs.

  2. To gain the full benefit of microservices, they should be shared across teams.

  3. Microservices are independently deployed and can impact multiple ‘logical’ applications.

The CI Build

We have relied on a CI build to do the heavy work and decision making around what goes into an application. [What are CI/CD Pattern and Practices].  The compile/link process creates our application version that pushes through development, testing, and production as a complete unit.  With a microservice implementation, this goes away.  Instead, our build becomes the process of taking a small piece of code, say 300 lines or less, and creating a container image. That image is then registered to a container repository. This single microservice living in a container may impact several ‘logical’ applications.  What is important to realize is that the ‘link’ step normally performed at your build, is now performed at runtime via APIs.  Microservices are loosely coupled and linked via an API at execution instead of linked in a build process.  

Microservice Sharing and Domains

Most microservices should be reused.  Microservice sprawl is a sign that your overall architecture is not taking advantage of reuse.

To avoid this mistake your strategy should be defined around the concept of a Domain-Driven Design. This approach requires you to take a step back and see your organization in terms of ‘solution’ spaces.  These solution spaces will define what microservices need to be created and shared across your organizational silos. 

Once these solution spaces have been identified, you may well discover that close to 80% of your microservices will be reused, leaving as little as 20% of custom microservices for any individual solution. In the below example, you will see how Website A & B customize on a shared foundation.

 

Microservice Domains and Sharing

Image 1: Microservice Domains and Sharing

This level of code reuse will be essential for us to meet the demands of the digital transformation of the 21st century.  We have a lot of software to design and reuse is the most cost-efficient way of getting us there.

The loss of the ‘Logical’ Application

The benefits of microservices are also their complexity.  When you throw out the application build process, you also throw out the application versioning process. 

The shift requires a new way of thinking about software configuration management and application versions is required. While we no longer release an application as a monolithic, we are still creating applications.  Banks will continue to build mortgage, auto loan, and settlement applications- they will just be built differently. 

As we begin this architecture shift, methods of tracking, versioning, and visualizing the complete ‘logical’ application will be essential to simplify a microservice implementation.

Conclusion 

Moving to Kubernetes and microservice architecture will be required to future proof your organization. To get there you will need to re-imagine your software development practice to support the implementation.

When you begin down this journey consider the impact of losing a full application build that determines how a monolithic application version is going to act based on the code and libraries that were compiled and linked as a whole.

Second, review and identify your microservice patterns, defining them into logical solution spaces, or domains.  A Domain-driven design is key to a successful implementation.  Without one, you may create microservice sprawl. 

And finally, software configuration management and application versioning are still important.  Consider methods of tracking microservice versions to application versions.  You will need an understanding of what your logical application consumes, what microservices impact your application, and the ability to track application version differences across all your clusters to achieve DevOps at the scale that microservices demand.

Hear more on this topic from Tracy Ragan in this episode of The Humans of DevOps Podcast.

 

About the Author

Tracy Ragan

Tracy is CEO and Co-Founder of DeployHub.  DeployHub is the first microservice management platform designed to facilitate the sharing, relationship mapping, and deployments of microservices. Tracy is an expert in configuration management and pipeline life cycle practices with a hyper-focus on microservices and cloud-native architecture.  She currently serves as a board member of the Continuous Delivery Foundation (CDF) where she is the elected General Member Representative.  She is also the Executive Director of the Ortelius Open Source Project, the open-source core of DeployHub.

Advance as a Professional

Become a member of DevOps Institute to unlock benefits and advance your professional career. Get started today with a complimentary, basic membership.

Membership at DevOps Institute

related posts

DevSecOps and ITIL4

DevSecOps and ITIL4

By: Niladri Choudhuri, Hugo Lourenco, Jay Shah and Helen Beal DevSecOps has emerged and established itself as the model to assure cybersecurity is properly considered when transitioning to DevOps ways of working. It demands collaboration between the security, IT...

[EP35] Life of an SRE at Google with Ramón Medrano Llamas

[EP35] Life of an SRE at Google with Ramón Medrano Llamas

On this episode of the Humans of DevOps, Jason Baum is joined by Ramon Medrano Llamas [@rmedranollamas], Site Reliability Engineer at Google. We find out how Ramon ended up at Google and more. Ramon comes from a town in the north of Spain and has moved no less than 13...