Transitioning to a microservices architecture from a monolithic one is an increasingly popular goal for many companies. Microservices promise speedier processing and delivery as well as the agility needed to pivot when markets demand changes.
However, the strategy needed to make the change is complex; the newly configured system must be more flexible than its monolithic predecessor while retaining some or all of its proprietary capacities. The mono-to-micro developers must understand the essential corporate functions — its “domains” — that define the essence of the enterprise to accurately replicate its overall performance in the evolved system. From my experience, the following fundamental steps will ensure the development of an effective approach to this transformational journey.
Step Zero: The Non-Technical Foundation
Moving to a microservices architecture presents both domain change and technical challenges. Focusing on the domains first ensures their integral properties will be properly transitioned to the new organization. Therefore, the project’s initiating “corporate function” evaluation is labeled “Step Zero” because it is the absolute foundation of everything that will follow.
Step Zero develops the strategy that will structure the domain transformation process. To effectively transform the functions of those monolithic domains into their granular microservices elements, it is critical to know exactly what those elements are. After several successful transformation projects, we’ve learned that gathering a detailed understanding of how those elements inform each overarching domain avoids unnecessary (and expensive) duplication of them throughout the rest of the transformation process.
Step One: Understanding The Business Architecture
Reviewing the architecture of the business reveals the functioning and processes the new system will have to achieve. This evaluation explores the business features already at work and how they produce proprietary products, then, broken down into domains, clarifies how those domains function individually and as a whole. Architects and developers will identify all relevant business drivers in their assessment, which may include:
- The company’s “Capability Matrix,” to identify and define what capabilities need support regardless of the style of architecture.
- The business services and processes inventories, to validate their value to the system.
- The correlation of corporate organization and functioning, to identify distinguishable elements (sub-domain/microservices).
- External and internal factors such as industrial policy and regulatory changes.
- A risk management evaluation with a thorough evaluation of assets, threats and vulnerabilities
Investing necessary resources in the first two steps builds the foundation necessary to move on to a structured design phase of the microservices architecture for the enterprise.
Step Two: Defining The Bounded Contexts
Each microservices module offers a single function (application) which, when aggregated with others, form the context of the greater function to which they each contribute. That overarching context is then bounded to define that greater function. “Bounded context” is a central pattern in the strategy behind domain-driven design (DDD), which divides large models into smaller Bounded Contexts and then explicitly directs their interrelationships to achieve the desired outcome.
For the entire enterprise to function, the bounded context apps are then loosely coupled to each other via a communications language into the fully orchestrated entities that perform the organization’s work. The bounded context architecture provides flexibility because the separate modules and contexts don’t require full integration of their functions to work together as a greater whole.
Step Three: Describing The Domain Data Model For The Microservices
Clarifying the domains into their bounded contexts defines the entities and reveals, at an abstract level, the subsequent structure of the microservices organization. As many technology evangelists begin defining how the microservices architecture will structure the transaction boundaries and mapping the entities to those boundaries, the resulting matrix provides a blueprint of processes that will become the foundation of the microservices enterprise. The next step is to evaluate how that new organization will interact with the company’s current corporate and technical status.
Step Four: Technical Considerations
As stated earlier, technical considerations play an equally significant part during the transformation, a few key factors being:
Overall Consistency: A consistency assessment provides an overview of how well the organization’s technology is functioning. The goal is to optimize the five domains that are (or should be) most influenced by its technology: its operations, organization, solutions delivery, financial management and transformative capacity. The assessment will reveal where within the current structure the enterprise is meeting or missing those marks.
Security: Each microservice is its own entity that requires its own security detail; multiplying the number of microservices also multiplies the number of security risks. Further, microservices security protocols require a different security strategy than that established in the monolith.
Standardized Evolution: Templates And frameworks: Templates and frameworks for microservices bring consistency and reliability to commonly used functions. Templates streamline processes by controlling groups of assigned resources, managing infrastructure, defining dependencies and controlling access to services. Frameworks also ensure that each module functions appropriately within the whole so the redesigned microservices enterprise gains both consistency and speed.
Automation maturity: Automation maturity is a process of aligning comprehensions, resources and priorities. Maturation evolves over a continuum of segments and silos, juggling costs and time considerations with cultural attachment to outdated methodologies. A fully mature automated DevOps capacity blossoms when the entire company adopts the DevOps practice and quickly moves concepts from ideas through to valuable business practices.
Maintainability: The replication of an entire monolithic software program to facilitate varying deployments often prohibits its use across other environments. In a microservices architecture, only some, not all computing elements require replication, so it’s easier to maintain the value of the software across networks. Prioritizing the maintainability of the incoming system addresses this challenge.
Transforming your enterprise from a monolithic to a microservices architecture requires a comprehensive understanding of its functional domains so those can be replicated in a microservices environment. Taking the time to develop a strategic approach to the transformation will ensure that all relevant legacy assets are captured and restructured to retain their value and maximize both their functionality as well as that of the new and renewed enterprise.
Director, Enterprise Integrations, for Sage IT Inc.