Software development strategies continue to evolve to meet changing business needs. There has been a lot of discussion of digital transformation recently, and custom software development is driving much of that transformation. Agile software development and DevOps have become the norm as companies strive to develop better, faster, more flexible applications. Microservices offer the next step in the evolution of enterprise application development.
DevOps separates developers (Dev) and operations (Ops) into teams collaborating on new enterprise solutions. Similarly, microservices expand on the idea of specialization, creating specialized app building blocks to build new applications. Microservices enable an even shorter development time and greater agility. They also present a new set of challenges for enterprise architects who must oversee these microservices and govern the development process.
A Series of Building Blocks
If you are unfamiliar with the term, microservices are a series of building blocks assembled to make new applications. Just as agile software development is a philosophy as well as an approach to development, microservices are an architectural and organizational approach to enterprise software development.
The value of microservices is in the building block approach. With old-school monolithic services, you must design and maintain a single application and its various components to act as a unit. Change or remove one element, and the entire application needs to be rewritten and tested, which is costly and time-consuming.
With microservices, the individual services function as self-contained functional units that can be mixed and matched as needed to create different custom applications. Using microservices is faster, more versatile, and more reliable, simplifying the delivery of large, complex applications.
Microservices also are built around business capabilities so that business application components can be created in tandem with DevOps agile enterprise development. And with different teams working to create smaller components, there is less chance of having a single point of failure.
No-code/low-code development solutions are placing the power of microservices in the hands of business users. Domain experts in product development, finance, logistics, and other departments can use a drag-and-drop interface to develop microservices that can then be incorporated into other applications. In short, microservices gives subject matter experts the tools to create custom apps that can be added to the enterprise architecture.
The Pros and Cons of Microservices
Microservices offer businesses and enterprise architects several benefits. Deployment of new applications is faster, and you have more flexibility to adapt to changing enterprise and business needs. They also scale quickly and make it simple to add new features to existing applications. And microservice elements are reusable.
Of course, there are challenges as well, including governance. As the architecture evolves, there are more components to be managed. In addition to different departments building microservices, the DevOps team is still responsible for overseeing application development and solving everyday problems. Having a mature engineering culture helps automate app development and track microservices, providing the necessary guidance to ensure app development supports larger business objectives.
Microservices also create architectural overhead. Applications must be documented to ensure ongoing business value. Trying to document everything, however, creates delays, so the documentation is never current with the stage of development. The challenge is providing enough documentation to be useful without delaying ongoing software changes.
This requires a new enterprise application mindset. DevOps needs to closely watch autonomous teams to control development and ensure they support larger corporate goals. The use of no-code/low-code tools also could result in shadow IT not being sanctioned by the network architects or DevOps.
Governing Development
One of the market forces driving microservices adoption is the need for “outside-in” application development. All microservices should be developed at the request of a customer, whether that customer is inside or outside the organization. Customer requirements continually change, and microservices can accommodate those changes faster and more efficiently.
Microservice development works best in a domain-driven architecture, which models the applications based on the organization’s real-world challenges. A domain-driven architecture assesses the enterprise infrastructure in light of business requirements and how to fulfill them. Most organizations already have a domain-driven design strategy in place that maps the architecture to business capabilities.
Bounded Context is a strategy that is part of domain-driven design. Autonomous teams responsible for microservices are formed around areas of responsibility such as inventory management, product discovery, order management, and online transactions, i.e., bounded context. The domain expertise resides within the team, so the enterprise architect’s responsibility is to guide development to align with strategic goals, balancing immediate needs and future business objectives.
When governing microservices as part of the enterprise, applying the C4 model for software architecture—context, containers, components and code—makes sense. The context defines the relationship between the customer or end user and the application. The container represents the microservice itself and how it is packaged to serve as an application building block.
The secret to governing microservices in any enterprise architecture is to map business capabilities to the digital infrastructure, then promote the vision behind the enterprise architecture as well as the guidelines to achieve that vision. Focus on organization-wide objectives for both business transformation and IT strategy. Educate the stakeholders on when to involve the enterprise architect. Also, try to anticipate topics beyond the perspective of the DevOps team and focus on the big picture—what is the long-term business strategy and how do microservices contribute to that strategy?
