Microservices Architecture Review PDF

WHAT IS A SERVICE BASED ARCHITECTURE? Service Oriented Architecture (SOA) Style of software design where the software components are Services that interact through a communication protocol over a network. Traditionally systems that use a SOA are decomposed into multiple software applications which...

WHAT IS A SERVICE BASED ARCHITECTURE? Service Oriented Architecture (SOA) Style of software design where the software components are Services that interact through a communication protocol over a network. Traditionally systems that use a SOA are decomposed into multiple software applications which are then further decomposed into services. Often these software applications are called monoliths because they consist of a single deployment that is very large and complex. MICROSERVICES Microservices A form of SOA where the applications and services are more fine-grained and independently deployable. User Mgmt. Search User Mgmt. Search Service Service Service Service How Small is “Micro”? Storage Auth. Storage Auth. Service Service Service Service Monolith – Single Deployment Microservices – Multiple Small Deployments SYNCHRONOUS VS ASYNCHRONOUS COMMUNICATION Synchronous Communication – When a client makes a request and has to wait until the request fulfilled before receiving the response. The client thread generally is blocked until the server fulfills the request. The server thread has to complete all the activities required of the request before returning the response. Asynchronous Communication – When a client makes a request and DOES NOT have to wait until the request completely fulfilled before receiving the response. BENEFITS OF ASYNCHRONOUS COMMUNICATION ¡ Simple, scalable connectivity ¡ Simple, high availability ¡ Simple producer/consumer scalability ¡ The enablement of publish/subscribe, message filtering, routing and fanout ¡ Message rate and consumer availability decoupling ASYNCHRONOUS COMMUNICATION - MESSAGING Microservices Principle: ¡ Dumb Pipes and Smart Endpoints (more toward Kafka) ¡ Pipe (i.e., Message Broker) is merely a highly-available transport mechanism (minimal logic) ¡ Endpoints (i.e., Services) have the logic on how or if to process the messages Traditional SOA: Smart Pipes and Dumb Endpoints (more toward RabbitMQ) ¡ Pipe (i.e., Message Broker) has complex logic – i.e., routing, retry ¡ Endpoints (i.e., Services) just process the messages they are given DATA STORES Traditional monolithic applications have one large database shared by multiple components in the application. This allowed for strong data integrity across tables because constraints can be added (i.e., foreign key references). Microservice based applications typically have a separate database per service (that actually requires persistent data storage). This provides looser coupling of services and different technology choices for data persistence for each service. Separate databases does add complexity to a Microservices Architecture. These include: ¡ Eventual consistency – Your system may have to accept that stored data will not always be consistent at a given time. ¡ Multiple Step Rollback – If you need to be consistent and a failure occurs, you may have to “manually” do rollback across multiple services. LOGGING ¡ Tracing – Logging for developers. Used to troubleshoot problems during development and sometimes in test or production. Can be very noisy. ¡ Event Logging – Logging for System Admins. Used to monitor and troubleshoot a system in product. Usually has very specific messages. This needs to be designed in during upfront architecture and design. CONFIGURATION Configurable parameters are defined in configuration files rather that in the source code. These Configuration Parameters may include: ¡ Environment Specific Settings (i.e., URLs, Database Hostname) ¡ Options – Turn on/off features or characteristics of the software (i.e., enable/disable 2FA) ¡ Tuning – Adjust the features or characteristics of the software (i.e., adjust how many retries on failed login) Reason: Provide a single place where intentionally configurable aspects of the software can be adjusted. You do not want System Admins modifying the code. CONFIGURATION Externalized Configuration – Configuration can be modified outside of the application without requiring a re-build (perhaps a restart though). Centralized Configuration – All configurations are stored in a central location (may be version controlled) to make it easier to view and update. SPA CHARACTERISTICS ¡ Web Server serves HTML/CSS/JavaScript pages to the user’s browser ¡ JavaScript dynamically updates the HTML/CSS as the user performs actions and upon requests/responses to backend services ¡ Frontend – The SPA ¡ Backend – The RESTful services providing the GET/POST/PUT/DELETE methods to the front end ¡ Developers sometimes specialize in the Frontend or the Backend, or work across both as in Full-Stack Developers CONTAINERIZATION What are some benefits of using Docker? ¡ Known/standardized configurations – the base image and any additional installed software/configurations are defined in a Dockerfile ¡ Can start and stop as needed. So can scale up and down as well ¡ Deployment platforms are built on top of Docker images (i.e., Kubernetes – K8s, OKD) SCALING SERVICES ¡ RESTful APIs – Load Balancer like NGINX (SW LB) ¡ Message Consumers – Multiple Partitions and Balanced Consumers CONTAINERIZED DEPLOYMENTS Docker Core for building images and running Use for a small number of independent services. containers. Docker Build on top of Docker and part of the Docker Use for groupings of related services where the Compose Ecosystem. number and type are static (i.e., no auto scaling). Good for development and test environments, and simple production environments. Container Typically 3rd party software for deployment of Use for large number of services and/or when Orchestration Docker containers, often over a cluster of VMs. services need to be automatically scaled up and Docker does have the built-in “Docker Swarm”. down. DEPLOYMENT STRATEGIES A Recreate deployment terminate the old version and release the new one. Recreate Rolling deployments (or ramped deployment) are a pattern whereby, instead of deploying a package to Rolling Update all servers at once, we slowly roll out the release by deploying it to each server one-by-one. In load balanced scenarios, this allows us to reduce overall downtime. A Blue/Green deployment is a way of accomplishing a zero-downtime upgrade to an existing application. Blue/Green The “Blue” version is the currently running copy of the application and the “Green” version is the new version. Once the green version is ready, traffic is rerouted to the new version. Canary Release is the technique that we use to “softly” deploy a new version of an application into Canary Production. It consists of letting only a part of the audience get access to the new version of the app, while the rest still access the “old” version one. A/B Testing is the release a new version to a subset of users in a precise way (HTTP headers, cookie, A/B Testing weight, etc.). A/B testing is really a technique for making business decisions based on statistics. It does not come out of the box with Kubernetes. It is included here for completeness. It requires additional infrastructure such as Istio, Linkerd,Traefik, custom nginx/haproxy, etc) A new version is released alongside the old version. Incoming traffic is mirrored to the new version and Shadow doesn't impact the response. OUR SAMPLE APPLICATION Dashboard UI (SPA) Frontend RESTful API Backend RESTful Data Storage API Processing Service Config Service Config Publish Consume Request Log Log Simulated Receiver Client Apps Response MySQL DB JSON Service Datastore (jMeter) Consume Config Log Analyzer Service Config (Event Sourcing) RESTful API Log OUR SAMPLE APPLICATION DEPLOYMENT Receiver (Docker) MySQL PostMan jMeter (Docker) Storage (Functional (Load (Docker) Testing) Testing) Port 80 Kafka NGINX Processing Volume (Docker) JSON (Docker) Analyzer (Docker) Zookeeper Anomaly Volume (Docker) (Docker) JSON Dashboard UI (React/HTM) Bind Mount Bind Mount Config Files Log Files Your Laptop Cloud VM Docker Compose DECOMPOSITION INTO SERVICES ¡ Capability or Domain – Strongly related functionality ¡ Team – Ownership ¡ Self-Contained Services – Asynchronous/High Availability/Scalable ¡ How are our sample services organized? MICROSERVICES – OVERALL ASSESSMENT ¡ What are the advantages of a Microservices architecture? ¡ What are the disadvantages of a Microservices architecture? ADDITIONAL TOPICS That we’ve used: ¡ Distributed Tracing – Debugging interactions across multiple services ¡ Service Per Container – Each microservice is deployed in its own container The we’ve discussed: ¡ API Gateway – Single entry point for all client applications ¡ Decompose By Business Capability – Each microservice corresponds to a business capability ¡ Decompose By Team – Each Team is fully responsible for one or more microservices