Microservices & Monolithic Architecture Recap PDF

Microservices & Monolithic Architecture recap Content Microservices Architecture Converting Monolithic Architecture → MSA Microservices Characteristics of MS...

Microservices & Monolithic Architecture recap Content Microservices Architecture Converting Monolithic Architecture → MSA Microservices Characteristics of MS Strengths of Microservice Architecture Weaknesses of Microservice Architecture Wrapper & Adapters in Microservices Types of Micro Services Atomic/Simple MS Composite/complex MS Differences between the two Microservices Monolithic Architecture Characteristics of a Monolith Application: Pros & Cons of a Monolith Application Converting the diagrams Microservice Architecture design overview Converting a monolithic application into micro services SOA Layered Architecture Diagram Microservices Architecture MSA are a cloud native architectural approach in which a single application is composed of many loosely coupled and independently deployable smaller components, or services. Concerned about the architecture when many microservices come together to form an enterprise solution and less about the architecture of individual MS Microservices & Monolithic Architecture recap 1  Unlike Monolithic applications, Microservice Architecture breaks down the single unified unit into a collection of smaller and independent units Unit carry out every application process as a separate service → Each service has their own logic | database | specific functions It is important to ensure that your micro services are as loosely coupled as possible Flexibility of Microservices Microservices can always be reused and reassembled to create another solution to target another business problem - Save resources & Development time 🚨 UIs may be decomposed into “micro-UIs” as well Converting Monolithic Architecture → MSA Consider business scenarios Data entities / Operations Communication patterns / Technologies Microservices & Monolithic Architecture recap 2  Microservices Defined as A microservice may be defined as a service that can be independently developed/deployed and provides only one or a few (instead of many) functionality needed to support business requirements It can be invoked by other applications (or microservices) over the network in a standard interface that is independent of programming languages and platforms 🚨 Focus of MSA: Develop & Maintain enterprise solutions as assemblies of loosely- coupled microservices Provide full functionality needed as microservices Each microservice is small & Simple Microservices are “Loosely coupled” with each other which provides the following features: Can be implemented in different programming languages Can be deployed and run on different platforms Usually have its own data store when a data store is needed Microservices & Monolithic Architecture recap 3  💡 “Own data store” does not mean seperate instances of supporting database software - i.e., Order & Customer database can be in the same MySQL software while running on the same machine Seperating will give benefit that different microservices can use different database (Polyglot Persistence Architecture) - easier to scale Ultimately dependent on how much independence among microservices that we want. Can be scaled independently Reduced downtime Implementation can be changed independently as long as interface (API) for invocation remains the same 🚨 A service can be considered a microservice if it possesses MS characteristics i.e., Independent redeveloped/redeployed - Easily deployed & scaled Can be implemented in different languages If the application implementing the functionality of the service is not Monolithic Characteristics of MS Microservices architecture is a style or pattern, not rigorous rules Microservices & Monolithic Architecture recap 4  Each microservice is relatively small and simple in comparison with usual enterprise applications A microservice can be developed and managed by a small agile team independently Each development team manages one or a few microservices 2 pizza rule: If you need more than 2 pizzas to feed the team that maintains it, it's too big Microservices exchange data with each other through a standard interface by using commonly used data formats and communication technologies i.e., JSON over HTTP transport; messaging Microservices architecture promotes a methodology that develops an enterprise application or solution as an assembly of loosely-coupled microservices Strengths of Microservice Architecture Each microservice can be deployed independently, enabling Continuous 1. Independent improvement & Updates components Ease of adding new features to a microservice application than a monolithic one. Split up into smaller and simpler components Smaller codebase makes microservice applications are easier to understand and 2. Easier understanding manage Easier for teams to collaborate - Easy for everyone to understand Microservices & Monolithic Architecture recap 5  Easier to scale up an application using microservices as demand for application increase 3. Independently scalable Resources can be used to scale up the most needed MS instead of whole app Faster & more cost efficient scaling If a specific MS fails, that failure can be isolated to that single service, preventing consecutive 4. Reduced downtime - failures which would cause app to fail. Fault isolation Fault isolation allows your critical application to stay up and running even when one of its modules fail More strengths of Microservices Have a well-defined boundary in the form of language-neutral APIs (to make it easy to communicate with other apps/MS implemented in different languages) A higher level of modularity than monolithic apps Weaknesses of Microservice Architecture Communication between services can be complex - An application can have multiple services which need to communicate with each other 1. Extra complexity for securely development teams Debugging is more challenging with MS - Each MS has their own logs, hard to trace source of problem Integration testing is not easy with MS - Components are distributed, developers may not able to test an entire system from their machines Microservices & Monolithic Architecture recap 6  Rely on network calls so more prone to failures Intricate dependencies => harder to debug Need to choose and implement an inter-process communication mechanism among 2. Interface control microservices, which may be more troublesome becomes critical than usual function calls; need extra code to handle possible communication failures Sufficient infrastructure with security and maintenance support + development teams to 3. Higher up-front costs manage and understand all the different MS is needed to make MSA work - Higher costs Logging, security and data transfer are the concerns which are needed in almost every module of an application, hence they are cross- 4. Cross cutting concerns cutting concerns. Each MS has the same few cross-cutting concerns which need to be set up multiple times as compared to Monoliths 🚨 Crosscutting concern are concerns which is applicable throughout the application and it affects the entire application. Other weaknesses: May result in a challenge on implementing business processes and transactions involing multiple entities across microservices May result in too many moving parts to keep track of Microservices & Monolithic Architecture recap 7  Partitioned databases are at odds with an enterprise-wide common data model: The same kind of data may be represented in different / incompatible ways; May lead to duplicated or inconsistent data across microservices May need some data transformers or adaptors Wrapper & Adapters in Microservices An adapter bridges the disconnects between an interface with another E.g. Used when there is an incompatible interface A wrapper simplifies an interface E.g. Wrapping a layer around a software component to expose its functionalities or encapsulating multiple API calls to make complicated functions easy to use Definition of “Adapters” in Wrapper Microservices An adapter exposes domain-specific capabilities of the underlying monolith or its components as though they were themselves microservices. 🚨 The process can be called “Exposing the functionality of a system as a service” Ideal for a monolith that has fully realized APIs for its various domains— including equivalent APIs for all user operations without requiring any interactions via UI Refers to software/code that enables functionality of an application (coded in Python for e.g.) to be called by another application (that may be coded in another programming language). Microservices & Monolithic Architecture recap 8  If the preconditions are met, we can develop services which “Wraps” the Monolith i.e., Order management, Payments etc or specific part of the monolith and present those capabilities as Microservices. Enables other MS/Applications to access these functionalites through the interfaces provided by the Wrapper service (Adapter) Considerations / Drawbacks of Wrapper services Wrapper services would often slow down the whole solution due to runtime costs in going through the additional wrapping operations. Key benefit of using wrapper services: Standardization, helps to make CI/CD easier and reduce maintenance costs. The slowdown could be mitigated in the long term by replacing the wrapper service and its underlying monolith with another new microservice. The replacement would also be relatively quick, if the new microservice conforms to the same interface of the wrapper service, we can easily replace by shutting down the wrapper service & starting the new microservice Microservices & Monolithic Architecture recap 9  🚨 In the short run, wrapper services can be worthwhile to do until a new MS can be developed to replace the Monolith & its Wrapper service. Applicable when the long term goal for an enterprise solution is to support CI/CD more efficiently & effectively for changing business requirements Migration: Over time, you can build out the adapters into full-fledged services which other client applications can use. Since the interface contracts are defined up front, you can inform the stakeholders of what’s coming, should they wish to start their migrations in parallel. In reality, though, it can take significant time before the rest of the enterprise has migrated their apps from calling the monolith to calling the microservice wrappers. But that’s okay: There’s no hurry. The monolith continues to function, there’s no disruption to client applications that call it directly. The key thing for these stakeholders to understand and accept is that customizations to the monolith will cease. When new business logic is needed for their applications, it should be developed in the new microservice architecture. This allows the enterprise sufficient time to adapt over time—to migrate from monolith to microservices while the engine is still running, so to speak. 🚨 NOTE: A Wrapper service invoking an external service that is seperately deployed & scalable (i.e., Google Search engine API) is still called a microservice However, usually not a microservice - Dependent on Monolith / IT System Microservices & Monolithic Architecture recap 10  Workings of Wrapper Services (Adapters) Adapting is necessary i.e., when a development team does not have decentralized control over an application’s data source A Wrapper microservice (Adapter) wraps and translates existing (usually function-based) services into an entity-based REST interface. This type of microservice treats each new entity interface as a microservice and builds, manages, and scales it independently - i.e., Using it to connect microservices to external adapter 🚨 An adapter must provide a service interface (for others to use), and the interface may use some function calls internally to invoke some underlying systems for the needed functionality. A service interface is a published interface used to invoke a service. Types of Micro Services Atomic/Simple MS (Micro)service implements the expected functionalities by itself independent of other (micro)services or applications within an enterprise context (except for commonly used applications, such as Apache HTTP server, MySQL server and have little impact on deployment) Refers to a MS that provides functionality related to only one entity of a business concern - Operations often include CRUD Often a single irreducible units / not beneficial to be broken down any future Implementation details within its interface is independent of others within an enterprise context It may be developed with any tool / language / OS of choice Microservices & Monolithic Architecture recap 11  Self-contained - No dependence on other MS / Monoliths: Will not invoke other MS via HTTP May depend on others as wrapper to expose some functionality in a monolith / external APIs Might not invoke other microservices via HTTP 🚨 An Atomic MS can communicate with other MS (Messages) but the communication should be independent of any reciever - Choreography based Does not need to recieve anything back Atomic MS should still be able to perform required functionality even if communication fails 🚨 An Atomic Microservice cannot invoke external services however, it can send requests (CRUD) to external services (AMQP Messages) A Simple (Wrapper) Service should be used for such invocations Any changes to the external service will only be affecting the Wrapper Service and not any other service (i.e., Complex MS) Composite/complex MS Composite MS are MS which relies on other MS to perform the desired functionality - Usually composition of simpler functionalities Refers to MS that provides functionality related to more than one entity The composition is often implemented via inter-process communication (IPC) technologies Microservices & Monolithic Architecture recap 12  Can involve conditional logic, error handling, and the sequencing of operations. Often called process (micro)service as it is often used to implement a business process involving more than one kinds of data entities Orchestrates multiple APIs to achieve broader business function No database, integrates data and functionality from multiple atomic services Invokes other (micro)services via HTTP, or directly communicates to others, e.g., by sending a request to a particular receiver and waiting for a reply Often needs to know the interfaces (e.g., URLs, routing keys, data formats) of all others it communicates with Functionality provided consists of a set/sequence of activities, including direct communication with others for a business process It may be developed with any tool / language / OS of choice May depend on other MS but not directly depend on a monolith - To allow it to be independently deployable and scalable Cannot be fully deployed/scaled independently without the support of other MS/Applications that it needs May depend on a monolith & other microservices but not recommended - Will increase coupling. 🚨 COMPOSITE MICROSERVICE ≠ COMPOSITE SERVICE A composite microservice shouldn't directly communicate to a monolith, so that it can be independently deployable and scalable A composite service that directly uses functionality of a monolith and other (micro)services is not recommended (although technically can be done), as that increases coupling between the service and the monolith. Microservices & Monolithic Architecture recap 13  🚨 A better way is to expose monolith's functionality is using a set of atomic services, then build a composite microservice that provides the monolith's functionality via using those atomic services and other (micro)services. Composite Microservice Composite Service Independently scaled DIRECTLY invokes the functionality of a monolith 💡 However, if the monolith is easily scalable and its Implements a functionality / long running process which require human invocation interfaces intervention (Approving applications) 🚨 are easy to use + change, the composite In such a scenario, it isnt a service can be called a microservice neither scenarios composite microservice can be independently scaled - Either scale up monolith / hire Example of easy to change more humans i.e., Database connected via standardized connection URL / External API to Google service which is scalable and easy to use interfaces) Differences between the two Microservices Microservices & Monolithic Architecture recap 14  Monolithic Architecture Considered as the traditional way of building applications Built on a single and indivisible unit Monolithic applications usually have one large code base and lack modularity If developers want to change/update something, they access the same code base and make changes in the whole stack at once Usually a 3-tier Architecture resembling a MVC design pattern: Microservices & Monolithic Architecture recap 15  Client Side UI / - HTML / JavaScript in browser (Model) - Consisting of table Database covering multiple entities (View) Server-side application - HTTP requests / Business logic / CRUD Database 3-tier architecture is similar to the MVC (Control) (Model View Control) design pattern 🚨 The server side application is usually deployed as a single package, referred to as a Monolithic Application / Monolith Characteristics of a Monolith Application: Has a single code base implementing all functions needed for various business processes The entire application is usually developed in only one programming language - Java / Python / PHP & on one platform - Windows, Linux, Mac OS Deployment of a monolith is often either all or none Not easy to deploy only a part of the application due to dependencies A change to one function often requires redeploying the entire application package Scaling only a specific function is not possible, the entire application has to be scaled Horizontal scaling involves adding more instances (or replicas) of the application to distribute the load across multiple servers Then use load balancers to distribute incoming requests evenly across the application instances Pros & Cons of a Monolith Application Pros Microservices & Monolithic Architecture recap 16  Straightforward to develop in a single language and platform; communication may be mostly in a simple form of method calls Simple to test as tests for the self-contained app can run a single machine Simple to deploy when the whole app is packaged together Can scale up the whole app by running multiple copies behind a load balancer In early stages, it may work well (if its size and complexity are not too high) Less cross-cutting concerns – Concerns that affect the whole application such as logging, handling, caching, and performance monitoring. In a monolithic application, this area of functionality concerns only one application so it is easier to handle it. Cons May become too large and complex for a developer to fully understand, and fixing bugs and implementing new features correctly becomes difficult and time consuming Slow down development; slow up start-up time Make continuous changes and deployment difficult: each change needs testing and redeployment of the whole app, which slows down change deployment Difficult to scale when modules in the whole app have conflicting deployment requirements A bug in one module can bring down the whole app Difficult to adopt new frameworks and languages Converting the diagrams Microservice Architecture design overview Recall Microservices & Monolithic Architecture recap 17  Microservices design SOA design Converting a monolithic application into micro services Note: If two edges have the same number, it indicates that two actions may happen in any order or in parallel In the example above, the following is happening: How decomposed micro services work 1. The Order micro service together in the business process of “placing creates an order record after an order” receiving an order from UI; 2. The Activity Log micro service gets notified about the order creation status, whether successfully or not; 3. If order creation succeeds, the order information is sent to create a shipping record; otherwise, the Error micro service gets notified 4. The Shipping Record microservice returns its status (whether the shipping record is created successfully or not) Microservices & Monolithic Architecture recap 18  back to the Order microservice; the Shipping Record microservice also informs the Error microservice if it encounters errors 5. The Order micro service returns its status and/or the status of the shipping record back to UI. In this micro service application, “order” is considered a complex micro service while shipping record, activity log and error are considered as simple micro services Monolithic Bookstore application Monolithic Bookstore application → Decomposed 🚨 You do not want to have a single UI be the end-to-end control of your entire business process Limits the functionality and reusability of the UI (JavaScripts). Instead, a complex micro service is used instead so that it can be reused for other purposes Microservices & Monolithic Architecture recap 19  Flaws of the design: The ability to clearly differentiate simple & complex micro service Simple microservices should not know the existence of other simple microservices but “Shipping Record” is contacting “Error” “Order” is suppose to be a complex micro service and orchestrate the system, but it has its own database - the ability to differentiate the simple & complex microservices is gone. A better design: Technical overview diagram SOA Layered Architecture Diagram kind of technical overview diagrams in the context of SOA in contrast to the previous technical overview diagram, this SOA diagram has less details about the data stores for the microservices, but more details about the workflows within the composite microservices. Microservices & Monolithic Architecture recap 20  May also omit the details of the workflows in composite microservices, to simplify the diagram further, depending on whether the diagram for your whole solution is clear enough; the details can be presented in separate microservice interaction diagrams for individual user scenarios Microservices & Monolithic Architecture recap 21