Microservices: A Welcome Disruption

Much is discussed about Kubernetes and containers, but the real benefit of this platform comes in the form of microservices—small, independently deployed functions that will define digital transformation. 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.

Yes, 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 five years. These benefits come with challenges, however. With any pivot there is disruption, but the disruption is welcome and can be overcome if we can understand both the difference and similarities in a microservice architecture.

The differences between a microservice and monolith implementation are what cause the most confusion. 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.

When moving to microservices, consider these three basic truths:

  • Microservices do not require a traditional “build” step. Linking is not done at the CI build; it is done at runtime via APIs.
  • To gain their full benefit, they should be shared across teams.
  • 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, of course, to fix the 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 their 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, which 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.

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 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 monolith, 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 an implementation.

Moving Forward With Microservices

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 such an 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 scale that microservices demand.

This article is part of a series of articles from sponsors of KubeCon + CloudNativeCon 2020 North America

Tracy Ragan

Ms. Ragan has had extensive experience in the development and implementation of business applications. She began her consulting career in 1989 consulting to fortune 500 organizations in the areas of testing, configuration management and build management. It was during her consulting experiences that Ms. Ragan recognized the lack of build management procedures for the distributed platform that had long been considered standard on the mainframe. In the four years leading to the creation of OpenMake Software she worked with development teams in implementing a team-centric standardized build management process. Ms. Ragan served on the Eclipse Foundation Board of Directors as an Add-in Provider Representative for 5 years. Ms. Ragan received her Bachelor of Science Degree in Business Administration from California Polytechnic University, Pomona, CA.

Tracy Ragan has 3 posts and counting. See all posts by Tracy Ragan