Designing for evolution - Monoliths to Microservices
•Download as PPTX, PDF•
1 like•42 views
Sunshine Coast .Net users group meetup. Talk on designing for evolution. Evolving design from monoliths to a distributed microservices architecture.
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Designing for evolution - Monoliths to Microservices
- 1. Design for Evolution Monoliths to Microservices
- 4. Monolith @red rock in Spanish Valley, Utah, Nov. 28, 2
- 8. Modular Monolith – Retail Banking
- 10. Micro Kernel
- 11. Micro Kernel – Pricing & Underwriting engine
- 13. ESB - SOA
- 16. Event Driven Architecture - Pradeep Loganathan Event Broker
- 18. ”Don't even consider microservices unless you have a system that's too complex to manage as a monolith” - Martin Fowler Microservice Premium
- 19. Microservices
Editor's Notes
- An evolutionary architecture supports guided, incremental change across multiple dimensions.
- As we start this conversation I am very interested to know and understand … Question - What is your definition of architecture ? Maybe a quick short one since it is a very subjective For me - Architecture is about enabling and making small incremental changes to the system.. It is about creating designs that allows teams to safely make small incremental changes continuously, changes that can be adequately tested for fitness before rolling out , Changes that can be safely rolled back, etc Architecting systems is not about big bang approaches or making large sweeping changes all over the system.. (It is a surgeons scalpel making precision cuts rather than a large hacksaw and slash and burn..) Why should architecture cater to incremental change .. Why should we design for change? basically, Change is a fundamental part of the business landscape and impacts how systems are built and is also impacted by the systems architecture also .. Change can be Business driven change.. Business drivers being new products, faster time to market, globalization etc. or Eco system change. E.g., containerization, cloud, JavaScript framework Evolutionary architecture basically caters to these change and enables incremental design changes and options. evolvability is a meta-characteristic of an architecture which protects the other architecture characteristics like scalability, security, performance etc. All of these need to evolve. Building evolvability into architecture allows us to protect all the other ilities. Cradle of Humankind at Maropeng near Johannesburg , South Africa. Homind fossil - Taung Child had a small brain, and many researchers thought the approximately three-million-year-old Taung was merely an ape. 2.3 million years old. Originally thought to have belonged to a monkey or ape, one feature stood out as being human-like., foramen magnum was positioned further forward under the skull than an ape’s, indicating that Taung held its head erect and therefore likely walked upright. a small incremental change in the position of the foramen magnum, or the opening that allows the spinal cord and brain to meet, convinced Dart that the child had walked upright like a human. helped convince anthropologists that walking upright came before big brains in the evolution of humans. Bipedal vs quadrupedal. 2.3 million years old. Originally thought to have belonged to a monkey or ape, the skull, as Dart realized, must have been positioned directly above the spine, indicating an upright posture. That is a trait seen in humans but unknown in other primates…Australopithecus africanus was in the human line of descent
- Ok since we are talking about small incremental changes and architecture enabling incremental changes… I have a question again. Question What do you think are the primary levers that an architect can use to engineer incremental change ? What do you folks do to enable incremental change within your teams. There are two primary parts to engineering incremental change Design & Development , which primarily covers how developers design systems, how they structure it, how they organize it etc. Operational, which covers how teams deploy software. (CI/CD Pipelines ).. Ability to deploy safely, ability to recover and rollback quickly.. This includes the ability to create immutable infrastructure (IaC) etc. Architecture is about using both these levers effectively.
- Monolothic ERA Starts off with a blockbuster business idea for a startup or a business opportunity to be addressed by a team in a large enterprise. Systems start with simple requirements .Nobody starts off by saying I will build a microservices based, containerized system deployed on a Kubernetes cluster load balanced across multiple regional data centers. A monolith is a good starting point for Bootstrapping systems development – (Do not prematurely optimize ). Simple to develop. Simple to deploy with a simpler deployment topology Code reuse possible using plain copy, libraries or bundling as a service. Simple to scale – Multiple copies behind a LB. There are various evolutionary variants of monoliths starting with the single process Monolith.
- First type of evolution of the monolith. A single app combining multiple business functions. What is the design evolution over here ? Composed of loosely related classes. No coherent overarching structure Very little modularity Developed on a single technology stack. High coupling Low cohesion ( includes everything and the kitchen sink ). High rate of change. Question : How do you think teams are organized in this structure ? Answer : A single team working across the whole monolith. From a team perspective Single Team – artificial organization for management. A large codebase and heavily coupled. Causes delivery contention no clear ownership. Large monolithic code base intimidates developers, can be difficult to reason, understand and modify Quality of the code declines over time. It’s a downwards spiral. From a deployment perspective Deployed and scaled as a whole. All code packaged into a single process Single deployable unit with a single persistence mechanism. Simple deployment process. hinder delivery agility. can be brittle Changes ripples across the whole system A small change in a single function can require compiling and testing the entire platform. Question – What is the simplest incremental change that can be performed to make this a better solution ? Answer – The simplest incremental change that I can think of is adding some sort of a overarching structure to the codebase
- Layered monolith based on layered architecture specifically…Technical Layering – Horizontal partitioning of the system based on technical concerns. What is the design evolution over here ? Technical layering – various horizontal ( Presentation, Domain, data layer ) ( Controllers, Services, Repositories ) Each layer is independent of the other layers, thereby having little or no knowledge of the inner workings of other layers in the architecture. Each layer is isolated allowing any layer in the architecture to be replaced without impacting any other layer e.g., replace presentation layer from angular to react. Layers can be open or closed. In a closed layer each layer defines strict contracts to access the it. Each layer access the other layer through these well-defined entry points Open layering – Each layer can directly access components in the other layers – This introduces coupling - If the presentation layer can directly access the components in the business layer, then they get coupled by implementation. Other Variants : strict layered approach / relaxed layered approach Relaxed layered approach – layers can jump across layers to access other layers for e.g.. The presentation layer can directly call the persistence layer, then changes made to the persistence layer would impact both the business layer and the presentation layer, producing a very tightly coupled application with layer interdependencies between components Question : How do you think teams are organized in this structure ? Answer : Teams are organized based on layers. Front end developers in one team, back-end developers in another team, DBA’s in a third team etc Teams are organized by technical knowledge. Teams are interdependent. Less interested in the business domain. Question: How do you think deployments would work in this sort of architecture ? Answer : Single deployment by statically build and linking code Could be a .net publish file or a Java WAR file Rudimentary automated tests. Question : What happens when business wants to make a simple domain change such as capture an additional field E.g. Capturing an additional field as part of a business process means changes to all the layers. Answer : Any domain-based change impacts all layers vertically. Changes will ripple through all the layers . To handle domain changes impacting all layer's teams start to think of structure their code better and this leads to
- A modular monolith is a system which is generally partitioned around domains rather than technical capabilities.. What is the design evolution over here ? Modularity is basically an organizing principle.. Modularity is a logical grouping of related code .. Could be functions, classes or components. Long term sustainable code bases require order and consistency. Question : Why is modularity important ? Answer : You now have teams working effectively independently. You are reducing the blast radius of incremental changes being made within these teams to their modules. Each team owns their own build and test pipelines and can incrementally deploy changes to the system. You now have a lot of small incremental changes being pushed out in a controlled manner with a low blast radius. The code may be deployed as a single unit but you have modules with tests and contracts. Modularity enables development agility and deployment agility. Good architectures allow for modularity as a principle, separating interface from implementation. At this stage , We're starting to think more about the design and implementation of the architecture and which components should be separated across those concerns. We're less interested about the technical evolution, but we're more interested about the areas that we want to support around the business We start thinking about the SOLID principles for OO design, we start using Domain driven design to identify boundaries and structure components. Question : How do you think teams are organized in this structure ? Modules as boundaries of separation. Multiple teams - interdependent – Module Ownership. Question: How do you think deployments would work in this sort of architecture ? Deployment All code packaged into a single process. Statically/dynamically linked modules for deployment. Deployment needs to be coordinated across teams. We have evolved from thinking about a system with no structure to thinking about using a layered approach to provide structure and organization ….. to building a modular design which enables modular architecture, enabling teams to develop independently. Teams can now reason about the structure of the system in conceptual terms. Teams can work independently and effectively on specific modules.
- In the modular era we build systems based on modularity principles. We pay attention to factors like Composition , aggregation, association. We start to think through how we glue our modules together. We start to work though structural, creational and behavioral design patterns. We start to think of factories and singletons. We start to think about contract-based design and development. We start to pay a lot more attention to interfaces and contracts. One of the architectures in this ERA is the micro – kernel architecture.
- In Micro Kernel architecture there is a concept of a core system with a well-defined functionality which provides a plugin architecture enabling plugins to bolt on to provide additional functionality. The Core system has a very well-defined base functionality. Design Evolution It provides extension points to extend functionality or develop new functionality. The extension points are defined as interaction contracts between the core system and the plugins. This defines the coupling and cohesion within the system & the plugins. The system can have a Concept of a registry. The Registry defines how plugins will interact with the system, the information that will be transferred back and forth etc. The Registry is the repository of functionality, and this functionality can be activated or deactivated by manipulating the registry. Need to factor for backward compatibility as the core system evolves to allow for plugins to operate. Team Organization Teams can independently build plugins. Contract based development with well defined interfaces. Core systems needs to evolve slowly to not break plugins Deployment Rate of change of the plugins is much faster than the core. Plugins can be developed and deployed independently. Core system deployment needs to be coordinated across all teams to avoid breaking existing functionality.
- Built premium calculation engine using micro kernel architecture. Engine exposes basic calculation functionality. Risks assemblies can be added when needed. Risk assemblies can be identified at run time through .NET reflection functionality.
- Now from here we start to evolve to not only think about structure but also about patterns of interaction both static interaction and dynamic interaction Architecture evolves from structure and small scale in-process interactions to focus heavily on large scale external interactions which are generally spread across multiple process. This is the SOA era.
- Service Oriented Architecture with an Enterprise Service Bus. What is the design evolution over here ? Business functionality is implemented as coarse grained services. SOA is a design approach where multiple services collaborate to provide a set of capabilities. A centralized ESB is used for orchestration and choreography of calls across these services to perform specific actions. ESB’s choreograph business processes centrally. Business services connect to the ESB to implement different parts of the workflow. All orchestration and Choreography is contained within the ESB. ESB’s are generally proprietary and expensive orchestration systems. Shared Taxonomy causes coupling. Question : How do you think teams are organized here ? Answer : Teams are organized around the services. Teams independently own these services and control the development, deployment , versioning and other factors of each service. Question: How do you think deployments would work in this sort of architecture ? Deployment Tooling to deploy, publish and manage the lifecycle of services. The ESB dictates how the services are built and their lifecycle. Proprietary messaging semantics. All services must agree on a shared taxonomy to enable the communication and orchestration. Shared Taxonomy causes coupling. Proprietary tooling and proprietary deployment processes. Question : With shared taxonomies .. How do teams evolve ? Answer : Taxonomies become contracts. There is a lot of coordination required to ensure that the contracts are adhered to. In a lot of cases the solution becomes centralized into the ESB in the form of mapping components. The primary duties of an ESB are: Route messages between services Monitor and control message exchange .. Workflow between services Resolve contention between communicating service components.. Mapping, transformation, etc. Control deployment and versioning of services ESB also Provides commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication service. What is the next best level to get over some of the things that hold us back in the SOA era.. It is about thinking through highly granular services, open communication protocols etc.
- Aqualogic ALSB
- Architecture evolves from synchronous , workflow type interactions to asynchronous reactive interactions. This is the reactive ERA. We start to think more about reacting to external signals in a consistent , fail proof manner. Ability to quickly react to changes and act in a consistent and predictable form determines success.
- Architectures built as Reactive Systems are more Reliable, flexible, loosely coupled, scalable and resilient. They are significantly more tolerant of failure and when failure does occur, they meet it with elegance rather than disaster. Four key facets of a reactive system – Responsive, resilient, Elastic and Message driven. Responsive – The system responds in a timely manner if possible. Responsiveness means that problems may be detected quickly and dealt with effectively. Responsive systems focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. This consistent behavior in turn simplifies error handling, builds end user confidence, and encourages further interaction. Resilient – The system stays responsive in the face of failure . Failures are contained within each component , isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Resilience can be achieved using various techniques such as replication , containment, isolation and delegation . Replication: Running the same component in more than one place, so that if one fails, another could handle it and the application can function in a normal fashion. Containment/isolation: Issues of a particular component are contained and isolated within that component and don’t interfere with other components or other similar components spun up as part of replication. Delegation: In the case of an issue in a component, without much deliberation, the control is transferred to another similar component that is running in a completely different context. Elastic – The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms. Back pressure , Competing Consumers, Message Driven – Asynchronous message passing is the base of reactive systems. Reactive Systems rely on asynchronous message–passing to establish a boundary between components that ensures loose coupling, isolation, and location transparency .
- The event broker topology pattern is used in scenarios where the event flow is relatively simple in nature and does not require any central event orchestration. In this topology, the event messages created by event producers enter an event broker, sometimes referred to as an event bus. The event broker can be centralized or federated and contains all of the event channels used for the event flow. The event channels may be message queues, message topics, or some combination of the two. The event processors are responsible for picking up events from an event broker. What is the design evolution over here ? Each event processor reacts to events Multiple event processors can react to the same event and perform differing functionality. Event processors can scale independently based on load. Question : How do you think teams are organized in this structure ? 1. Teams are organized around each event processor module. 2. Event processing may be based on the concept of a domain Question: How do you think deployments would work in this sort of architecture ? Event processors are deployed independently The centralized event broker represents a shared infrastructure concern across all teams.
- The mediator topology pattern is used to design systems/processes that will need some level of coordination/orchestration in order to process the event. This topology uses a single event queue and an event mediator to route events to the relevant event processors. This topology is commonly used when multiple steps are required to process an event. In mediator topology, event producers send events into an event queue. There can be many event queues in an EDA. Event queues are responsible for sending the event messages on to the event mediator. All of these events, referred to as initial events, go through an event mediator. In order to perform each step in the initial event, the event mediator sends a specific processing event to the event channel. This processing event is received and processed by the event processor. Event channels are used to pass processing events associated with each step to the event processors.
- As we start to think through and solve for these we move into the microservices era. Primary focus is on Small Services which are fine grained. Loosely coupled Independently deployable Organized around business capabilities Owned by a small team Highly maintainable and testable Minimal lead time High deployment frequency
- Premium on microservice, Microservice tax.
- This is an example of a microservices architecture. What is the design evolution over here ? Each microservice is a black box. It hosts business functionality on one or more network endpoints ( REST, MQTT, GRPC etc. ). Or whatever protocol is most appropriate. Each microservice encapsulates its own persistence mechanism. They embrace the concept of information hiding. Question : How do you think teams are organized in this structure ? Smaller.. Laser focused teams. ( 2 pizza teams etc. ) High development agility Decentralized structure -- Becoming comfortable with independence. -- Enables each team to be autonomous and work with minimal coordination with other teams Build and run teams. -- Changing how developers, operators and security professionals work together. Dev Sec OPS Change in culture - High‑Freedom, High‑Responsibility Culture with Less Process Question: How do you think deployments would work in this sort of architecture ? High deployment agility. High frequency deployments with low rates of change. Quick controlled deployments with controlled automated rollback. Multiple deployment models – canary, blue green, rolling upgrades etc Through testing processes Move to conclusion In a lot of ways, we have been on a whirlwind tour from monoliths to microservices in less than 30 minutes but what enables this to happen again is the meta characteristic of architecture.. Which is evolvability. You generally don’t see this as one of the ilities. However, I am very passionate about including this as one of the primary defining characteristic of a system
- Good architecture allows for systems evolution. This Evolution allows team to become agile, react faster, be effective autonomously. This evolution allows the delivery process to achieve efficiency… by catering to faster cycle times and shorter lead times, the delivery process can react quickly and deliver value faster. This evolution allows for the system to evolve to cater to higher loads, become more reliable and predictable, and perform predictably and consistently across varying loads.
- Thanks for the opportunity to talk through what I consider a very important part of architecture .. Evolvability and the ability to enable evolvability. Question : Is the ESB a SPOF ? Answer : If you really ask me the ESB is definitely a SPOF purely because it is the central orchestrator and if it fails everything else also fails. SOA From an SOA perspective… Services tend to be composed of large pieces of functionality. Evolving services is painful as coordination is required. SOA does not indicate best practices for service granularity. SOA does not have best practices on how to split something big into something small and manageable. Lots of standards and protocol dependencies.. SOAP, WSDL, WS * specifications etc. Componentization via Services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Evolutionary Design
- Component level modularity is measured on 3 axes. Component Cohesion – Measure of how related parts are to one another. Things which change together stay together. Functional – Sequential – Communicational – Procedural – Temporal – Logical – Coincidental – Coupling – Implementation coupling – All parts of the system have intimate knowledge of the other parts of the system. Any change to any part of the system will break other parts. Temporal Coupling – Calls are synchronous Deployment Coupling – All parts need to be deployed as a whole Domain Coupling –NA for monoliths…Does not exist as it caters to a specific domain. Connascence - Two components are connascent if a change in one would require the other to be modified in order to maintain the overall correctness of the system Static Connascence – Dynamic Connascence -
- Same as previous Package by feature leads to this pattern. This is a technique to prevent coupling at the database layer and introduce modularity at the persistence layer. Each vertical slice evolves to holds its own data .
- The layered architecture evolves from an in-process vertical slice to an out of process vertical slice. Looks like a microservice, sounds like a microservice but is it a microservice. A change to one service requires a change or a deployment to other services. A distributed monolith is a system that consists of multiple services, whatever reason the entire system has to be deployed together distributed monoliths have all the disadvantages of a distributed system, and the disadvantages of a single-process monolith Less focus on information hiding and cohesion of business functionality, leading instead to highly coupled architectures Interactions between the monoliths start to dictate a lot of factors.