Moving from a monolithic architecture to a microservice application 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 entire 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. In other words, we all have a lot to learn.
The core of understanding microservices is how they are written and deployed. Microservices 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.
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. The compile/link process creates our application version that push 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 microservice reuse. To avoid this mistake your microservices strategy should be defined around the concept of a Domain Driven Design. This approach requires you 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. 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 is 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 different. 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 to achieve DevOps at scale that microservices demand.
About the Author
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 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](https://www.ortelius.io/, the open source core of DeployHub.
Top comments (0)