Contributed by Tracy Ragan, CDF Governing Board Member

Originally posted on medium.com

Evolving to a microservices architecture is key to future-proofing your organization.

Adopting a container strategy is a great way to get started on your journey to modern architecture. But don’t stop there. Once you have embraced containers and Kubernetes, the next and most important step is to move to a microservice architecture. Microservices are small independently deployed functions that will define your full digital transformation. Microservices give you 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.

If you have containerized your application, you are ready to take this next step. There are many benefits to moving to a microservice architecture and most companies will shift to this development platform over the course of the next 5 years. These benefits do not come without challenges. With any pivot there is disruption. This disruption is welcome and can be overcome if we can understand both the difference and similarities in a microservice architecture compared with a monolith.

The truth is microservices can be complex. Their creation and delivery are very different from a monolith implementation. But you can do this. As a collective community, we have gone through similar big shifts in the past, mainframe to distributed for example, and we not only survived, we thrived. And like the shift from mainframe to distributed systems, microservices disrupt the way we write and deliver code. So it is time for the next evolution of software development.

Three Basic Truths

When moving to microservices, consider these 3 basic truths:

1. Microservices do not require a traditional ‘build’ step. Linking is NOT done at the CI build step, 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

“Ten-minute builds” has been the war-cry of continuous integration for years. The goal being a fix to a build in 10 minutes or less. The good news is everyone will have builds that are less than 10 minutes. The bad news is the configuration management and decision making that went into your CI build step goes away. Instead, your build will focus on creating a container for your service and registering it. Build done. What we lose in this process is the ‘logical’ application. It still exists, but we no longer create a ‘full’ build that makes up a complete solution. We are just building a small reusable part.

Microservice Sharing and Domains

Most microservices should be reused. Microservice sprawl is a sign that your overall architecture is not taking advantage of microservice reuse. To avoid this mistake your microservices 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 siloes. 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.

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 microservice 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. With microservices, 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 shifting to a microservice architecture, methods of tracking, versioning and visualizing the complete ‘logical’ application will be essential to simplify a microservice implementation.

Conclusion

Moving to a 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 a microservice 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 microservice 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 in order to achieve the DevOps at scale that microservices demand.

About the Author

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.