Modern Digital Architecture with Microservices

Profile Santosh Patil • Enterprise Architect and Technology Evangelist • PT Midas Daya Teknologi • santosh.patil@midasteknologi.com

Agenda — Architecture Principles — Microservices — Service Mesh — Containers — Container Orchestration — DevOps

Digital Architectural Principles — Customer Centric Experience, Multi-channel — Agile modular services - Loosely coupled, self-contained — Real-time and Contextual data analytics — Security — DevOps for Agility — Future Ready Architecture — Cloud First Approach — Non Functional Requirements (NFR) – — High Availability — Scalability — Disaster Recovery — Maintainability — Reliability — Configurability — Governance

Digital Architectural Principles — User Centric Experience, Multi-channel Putting customer at heart of every business if key to business success. Digital applications should be responsive, intuitive, consistent. Easy to use interface enhances user experience and improves stickiness. Business functionality and features should be available across all multiple channels. True Omni-channel experience should be delivered with digital architecture.

Digital Architectural Principles — Agile modular services Business functionality or feature should be available as loosely coupled and self-contained service. Services should be agile, modular, easy to integrate and easily scalable. Microservices architecture meets this requirement. Services can be domain based, aggregation, integration, data services, security service etc. Services should be platform and technology agnostic.

Digital Architectural Principles — Real-time and Contextual data analytics Customer generate data with every move they make within an app, this data has to be captured and analyzed real time to provide personalize and contextualize analytics driven insights. E.g. personalized campaigns, targeting, marketing automation and segmentation etc.

Digital Architectural Principles — Security System architecture should ensure end to end security. Security must be an integral part of the overall application. Consider few security options like authentication, tokens, digital signatures, key management, authorization, SSO, auditing, logging, encryption of request, response and data etc.

Digital Architectural Principles — DevOps for Agility Quick time to market and agility are key attributes of Digital systems. DevOps methodology should be used for agile development and deployment. Continues integration and continues delivery should be used to release business functionality and features faster to market. DevOps provides following few advantages Automation Faster & frequent releases Improved quality and less errors Good Governance

Digital Architectural Principles — Future Ready Architecture Innovation continues its disruptive march across business and technology landscapes. Every day new technologies and new digital channels are emerging. Digital architecture should be ready to expand business functionalities across these new channels. Emerging Digital Channels Wearable Internet of Things (IoT) Augmented Reality & Virtual Reality (AR &VR)

Digital Architectural Principles — Cloud First Approach Digital systems should to be agile and flexible. Cloud based systems adhere to few base principles as flexibility, agility, scalability, automation, infrastructure as code. Cloud first approach provides following few advantages Cost Saving Agility & Scalability Optimal Performance Better Collaboration Easy Data Backup & Recovery

Digital Architectural Principles — Non Functional Requirements (NFR) Digital systems are mission critical hence they should be designed for zero downtime. Deployment, upgraded or maintenances should not affect customer experience. Following NFR should be addressed in system designs Ø High Availability Ø Scalability Ø Disaster Recovery Ø Maintainability Ø Reliability Ø Configurability Ø Governance

Microservices Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are — Highly maintainable and testable — Loosely coupled — Independently deployable — Organized around business capabilities — Owned by a small team The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.

Microservices Monolithic Architecture Microservices Architecture

Microservices Patterns Pattern is a general, reusable solution to a commonly occurring problem

Microservices Patterns Decomposition v Decompose by business capability - define services corresponding to business capabilities v Decompose by subdomain - define services corresponding to DDD subdomains v Self-contained Service - design services to handle synchronous requests without waiting for other services to respond v Service per team

Microservices Patterns Data management v Database per Service - each service has its own private database v Shared database - services share a database v Saga - use sagas, which a sequences of local transactions, to maintain data consistency across services. v API Composition - implement queries by invoking the services that own the data and performing an in-memory join v CQRS (Command Query Responsibility Segregation) - implement queries by maintaining one or more materialized views that can be efficiently queried v Domain event - publish an event whenever data changes v Event sourcing - persist aggregates as a sequence of events

Microservices Patterns Reliability v Circuit Breaker - invoke a remote service via a proxy that fails immediately when the failure rate of the remote call exceeds a threshold. Security v Access Token - a token that securely stores information about user that is exchanged between services

Microservices Patterns Observability v Log aggregation – centralized logging service, aggregate application logs v Application metrics - instrument a service’s code to gather statistics about operations v Audit logging - record user activity in a database v Distributed tracing - instrument services with code that assigns each external request an unique identifier that is passed between services. Record information (e.g. start time, end time) about the work (e.g. service requests) performed when handling the external request in a centralized service v Exception tracking - report all exceptions to a centralized exception tracking service that aggregates and tracks exceptions and notifies developers. v Health check API - service API (e.g. HTTP endpoint) that returns the health of the service and can be pinged, for example, by a monitoring service v Log deployments and changes

Service Mesh Service mesh is used to describe the network of microservices and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.

Service Mesh Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, with few or no code changes in service code. Istio support can be added to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality.

Service Mesh — The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices. They also collect and report telemetry on all mesh traffic. — The control plane manages and configures the proxies to route traffic.

Service Mesh Traffic Management Traffic routing rules let you easily control the flow of traffic and API calls between services. Istio simplifies configuration of service-level properties like circuit breakers, timeouts, and retries, and makes it easy to set up important tasks like A/B testing, canary rollouts, and staged rollouts with percentage-based traffic splits. Istio’s traffic management model relies on the Envoy proxies that are deployed along with your services. All traffic that your mesh services send and receive (data plane traffic) is proxied through Envoy, making it easy to direct and control traffic around your mesh without making any changes to your services.

Service Mesh Observability Istio generates detailed telemetry for all service communications within a mesh. This telemetry provides observability of service behavior, empowering operators to troubleshoot, maintain, and optimize their applications – without imposing any additional burdens on service developers Istio generates the following types of telemetry in order to provide overall service mesh observability § Metrics § Distributed Trace § Access Logs

Service Mesh Security Istio Security provides a comprehensive security solution to solve problems like. § TLS Encryption § Access Policies § Authentication, authorization § Service identity § Audits

Containers A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. Containers are often referred to as “lightweight,” meaning they share the machine’s operating system kernel and do not require the overhead of associating an operating system within each application.

Containers Containers are an abstraction at the app layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space. Containers take up less space than VMs (container images are typically tens of MBs in size), can handle more applications and require fewer VMs and Operating systems. Virtual machines (VMs) are an abstraction of physical hardware turning one server into many servers. The hypervisor allows multiple VMs to run on a single machine. Each VM includes a full copy of an operating system, the application, necessary binaries and libraries - taking up tens of GBs. VMs can also be slow to boot.

Containers q Portability: Portable and able to run uniformly and consistently across any platform or cloud. q Agility: DevOps tools and processes can be used for rapid application development. q Speed: Faster start-times as there is no operating system to boot. q Fault Isolation: The failure of one container does not affect the continued operation of any other containers. q Efficiency: containers are inherently smaller in capacity than a VM and require less start-up time, allowing far more containers to run on the same compute capacity as a single VM. q Ease of Management: Container orchestration platforms can ease management tasks such as scaling containerized apps, rolling out new versions of apps, and providing monitoring, logging and debugging, among other functions. q Security: The isolation of applications as containers inherently prevents the invasion of malicious code from affecting other containers or the host system.

Container Orchestration — Container orchestration is about managing the lifecycles of containers, it control and automate task like. — Deployment of containers — Scaling of containers — Redundancy and availability of containers — Resource allocations to containers — Container network management — External exposure of services running in containers — Load balancing of service discovery between containers — Container health monitoring

Kubernetes Kubernetes (K8s) is an open-source orchestration platform for automating deployment, scaling, and management of containerized applications. — Service discovery and load balancing — Service Topology — Storage orchestration — Self-healing — Deployments — Secret and configuration management — Horizontal scaling — Batch execution — Managing Resources for Containers

Kubernetes Deployment Strategies — recreate: terminate the old version and release the new one — ramped: release a new version on a rolling update fashion, one after the other — blue/green: release a new version alongside the old version then switch traffic — canary: release a new version to a subset of users, then proceed to a full rollout — a/b testing: release a new version to a subset of users in a precise way (HTTP headers, cookie, weight, etc.). A/B testing is really a technique for making business decisions based on statistics, , rather than a deployment strategy. It can be implemented using a canary deployment.

Kubernetes Deployment Strategies Blue green deployment. Blue green deployment is an application release model that gradually transfers user traffic from a previous version of an app or microservice to a nearly identical new release—both of which are running in production. The old version can be called the blue environment while the new version can be known as the green environment. Once production traffic is fully transferred from blue to green, blue can stand in case of rollback or pulled from production and updated to become the template upon which the next update is made.

Kubernetes Deployment Strategies Blue green deployment.

Kubernetes Deployment Strategies Canary deployment. Canary deployments are a pattern for rolling out releases to a subset of users or servers. The idea is to first deploy the change to a small subset of servers, test it, and then roll the change out to the rest of the servers. The canary deployment serves as an early warning indicator with less impact on downtime: if the canary deployment fails, the rest of the servers aren't impacted. Instead of switching from blue to green in one step, you use a phased approach.

Kubernetes Deployment Strategies Canary deployment.

DevOps — Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly. — DevOps describes a culture and set of processes that bring development and operations teams together to complete software development, also it highlights set of practices that automates the processes between software development and IT teams, in order that they can build, test, and release software faster and more reliably.

DevOps CI/CD — Specific techniques used as part of implementing the DevOps concepts and processes — Continuous Integration (CI) - Is a software engineering practice where members of a team integrate their work with increasing frequency. In keeping with CI practice, teams strive to integrate at least daily and perhaps multiple times per day. CI emphasizes automation tools that drive build and test, ultimately focusing on achieving a software-defined life cycle. When CI is successful, build and integration effort drops, and integration errors are detected as quickly as practical. — Continuous delivery (CD or CDE) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. CD focuses an organization on building a streamlined, automated software release process .

DevOps — Agile - Focuses on processes highlighting change while accelerating delivery. — DevOps- Focuses on culture highlighting roles that emphasize responsiveness, collaboration among teams — CICD- Focuses on software-defined life cycles highlighting tools that emphasize automation.

NoOps — NoOps can completely automate operations, in true NoOps development and operations never need to interact. Operation and maintenance is fully automated using software and software defined hardware.

High Level Digital Architecture

Thank You