Orchestration modernization for architects: Driving Microservices forward
Modernization represents a substantial investment in both systems and operating models. Determining the optimal extent of this modernization is crucial to avoid wasting resources on efforts that do not drive business progress. By aligning your modernization efforts with your strategy and understanding how each product in your organization supports that strategy, you can pinpoint which aspects of your architecture will benefit most from modernization and how to carry it out effectively to meet your business objectives.
To achieve this, consider the following questions: What new capabilities need to be developed? Which system components will require the most extensive development? What is the current level of technical debt in each system area? Is your focus on accelerating innovation, reducing operating costs, or improving scalability to accommodate rapid growth? This text looks broadly at the typical way of building microservices and then explore the architecture of microservices through the lens of process orchestration to make a case for modernizing them by identifying a north star.
Architecture stifling business growth
Microservices have become a popular approach to building software, typically involving a number of independent services that communicate with each other. Services perform two main functions: business logic and flow logic. Business logic refers to the actual job the services are designed to do, while flow logic pertains to the communication between services to achieve tasks across different contexts. The way this communication is handled is crucial for defining a microservices architecture.
A traditional method of developing microservices involves embedding both flow and business logic within the services themselves, allowing each service to coordinate with others. This is known as choreography. This approach emphasizes decentralized communication, enhancing aspects such as resilience, scalability, and flexibility. However, it also increases complexity in tracing and monitoring, and lacks centralized control, which is important for enforcing policies or coordinating complex workflows.
In contrast, microservices orchestration uses a central controller, known as the conductor, to facilitate communication between services. This method emphasizes centralized communication, offering advantages like improved visibility, coordination, and reducing the need for each service to manage its own communication logic and error handling. Nevertheless, it can introduce disadvantages such as potential bottlenecks, and a single point of failure.
Peer to peer choreography or centralized control?
With peer to peer task decentralized choreography, microservices normally use event-brokers (or message brokers) and publish/subscribe models; while this is a very popular strategy, it has its limitations, with growing scale and complexities, publish/subscribe quickly highlights some of the issues associated with the approach:
- Process flows are embedded within the code of multiple applications, leading to services containing too much flow logic.
- It is difficult to systematically determine the remaining steps for a process to be complete without diving into the microservices to understand their current state.
Centralized control, on the other hand, provides a central point for managing interactions between services, adding value for operational policies such as compliance, security, and standardization — in one word: governance. In practice, many modern architectures combine both approaches, using event/message-driven communications for some system aspects while employing orchestration for complex workflows requiring coordinated control.
The goal is to balance flexibility, scalability, resilience, and control according to the application’s needs. As a general guideline, microservices orchestration is preferable for better control over all application aspects and for a stable, measurable development process. In other words, to explore another way to coordinate microservices with a conductor, while maintaining resilience, flexibility, and scalability, consider the following:
Why microservices need a conductor?
In real-world scenarios, many business processes are essentially orchestrations across services. A service can execute its logic only if preceding services have completed their tasks and produced the necessary outputs. Whether through choreography or orchestration, there is always a business process, either spread across multiple microservices or contained within a single component. Therefore, a conductor becomes an obvious choice.
Unlike business logic, decisions about what happens after the current task requires a broad scope and an understanding of the larger context beyond the microservice. This broad scope and understanding are effectively provided by the conductor, particularly in complex scenarios.
Principles for Process Orchestration
In the fast-paced realm of modern systems, complexity is the norm, and adaptability is key to success. As architects and stakeholders, we’re constantly navigating a landscape full with challenges, seeking innovative solutions to build systems that are not only resilient and scalable but also agile and efficient. In our journey through the intricacies of process orchestration, we’ve encountered numerous limitations that hinder our ability to innovate effectively. We’ve grappled with complexities in communication, struggled with maintaining system coherence, and faced barriers to scalability and adaptability. As more of the world is run by software, systems will become more complex, and architecture will become even more important.
These challenges prompt us to take a step back and reevaluate approaches. There is a need for a guiding framework, a set of principles that would serve as a north star in navigating the complexities of distributed system architecture. We have articulated a series of principles and guidelines underpinning our approach, aimed at fostering simplicity, agility, and effectiveness in distributed system architecture.
- Decoupling Decision-Making: We promote separating decision-making from individual services, following the principle of “simple pipes, smart endpoints”. This action emphasizes simplicity in communication, allowing services to focus solely on their core business logic. By doing so, we simplify communication, improve maintainability, and enhance system resilience.
- Empowerment Through Orchestration: A dedicated component orchestrating interactions between services, fostering compatibility and system-wide optimization empowers services to concentrate on their core functionalities, leading to clearer communication, easier maintenance, and greater adaptability.
- Centralized Governance through Orchestration: Additionally, services no longer need to handle governance individually, as the orchestrator component provides a centralized point for better governance. This ensures compliance, security, and standardization across the system. Since many tools do not include governance, this layer, separated from the actual business logic, is an effective approach to incorporate governance seamlessly.
- Embracing Diversity: We see the diversity of endpoints in modern architectures as opportunities for innovation. By accommodating diverse endpoints, including legacy systems and external services, we unlock new possibilities for scalability, adaptability, and efficiency. Integrating various endpoints enhances system-wide resilience and efficiency.
By following these principles, we can design robust, scalable, and efficient systems that are adaptable to the fast-paced world of modern process orchestration. The underlying logic preceding the principles is as follows:
- Unified Source of Truth: An orchestrator act as custodian of a unified source of truth, ensuring coherence, consistency, and transparency across a system. Simple pipes facilitate straightforward communication, while smart endpoints make informed decisions based on their specialized knowledge and context.
- Modularity for Agility: A modular approach to system design, allows services to operate as autonomous entities, being loosely coupled and independently deployable. This modularity promotes agility, allowing for iterative development, rapid deployment, and seamless integration of new functionalities.
- Data-Driven Insights: Data drives insights and meaningful outcomes. Orchestration facilitates data transformation and interoperability, ensuring compatibility and coherence across diverse endpoints. Strategic use of data-driven insights propels systems towards greater efficiency and effectiveness.
Prepare to connect architecture and strategy
A fruitful architecture modernization journey requires seeing business and IT as two sides of the same coin. But in some organizations, this mindset can be tough to accept. IT is sometimes seen as a bunch of programmers who just take requirements and convert them into code. Adopting a modern, product-centric mindset in which teams are empowered to make product decisions and own their roadmap is a monumental shift and probably won’t happen overnight.
We discussed the product-centric mindset in a previous post as we explored the low-code concept, but in this post I’d like to mention a good tool to become more product-centric, that is the John Cutler’s Journey to Product Team infographic, it helps us understand where we are and where we would like to be in relation to that goal.
As we normally mention in many of our workshops, the use of BPMN is just the tip of the iceberg, to accomplish true transformation and rip the benefits we are looking for, we need to make relevant cultural changes. Modernization is a long journey with many important decisions and challenging moments. Collectively, modernization leaders have many responsibilities, including
- Understanding and contributing to the business strategy
- Defining the modernization strategy
- Designing and evolving the architecture
- Setting up an organizational structure to develop the architecture
- Communicating vision and progress
- Build vs. buy vs. partner decisions
- Setting rewards and incentives that encourage the desired behaviors
- Continuing business as usual (BAU) while simultaneously delivering modernization
- Ensuring engineering teams are immersed in the business domain
- Shaping engineering culture
- Developing and managing people
- Introducing modern technical practices and coaching teams
- Continuously infusing new ways of thinking and working
With all of these responsibilities, modernization efforts cannot be led by a single superhero or even a small group of them. Before starting your modernization journey, it’s a good idea to look at this list of modernization responsibilities and any others you expect to face and then identify which leaders can take on which responsibilities and whether there are gaps. In addition, you’ll need to think about how these people will work together to collectively lead modernization initiatives across the business.
Modernizing your microservices architecture is not just about adopting the latest technologies but about aligning your IT infrastructure with your business strategy to foster growth, agility, and resilience. By embracing orchestration and incorporating guiding principles such as decoupling decision-making, empowering through orchestration, centralizing governance, and embracing diversity, organizations can navigate the complexities of modern distributed systems effectively. This journey requires a collective effort, a shift in mindset, and a commitment to continuous improvement. With a clear strategy and collaborative leadership, you can transform your architecture to meet the demands of today’s dynamic business environment and drive meaningful progress.
