Modern Digital Architecture with Microservices

Presented by Santosh Patil (Enterprise Architect, Technology Evangelist - Midas Daya Teknologi) at a webinar by BATC, Agile BSD, and Agile Circles Indonesia.

Innovation continues its disruptive march across business and technology landscapes. Organizations strive to embrace digital technologies as a source of growth and enhance competitiveness. Right and holistic digital architecture is a key to drive successful business outcomes. This session is to discuss modern digital architecture with microservices.

Transcript

1. Modern Digital Architecture
   with Microservices
   

   View Slide

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

   View Slide

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

   View Slide

4. 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
   

   View Slide

5. 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.
   

   View Slide

6. 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.
   

   View Slide

7. 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.
   

   View Slide

8. 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.
   

   View Slide

9. 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
   

   View Slide

10. 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)
    

    View Slide

11. 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
    

    View Slide

12. 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
    

    View Slide

13. 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.
    

    View Slide

14. Microservices
    Monolithic Architecture Microservices Architecture
    

    View Slide

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

    View Slide

16. 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
    

    View Slide

17. 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
    

    View Slide

18. 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
    

    View Slide

19. 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
    

    View Slide

20. 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.
    

    View Slide

21. 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.
    

    View Slide

22. 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.
    

    View Slide

23. 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.
    

    View Slide

24. 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
    

    View Slide

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

    View Slide

26. 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.
    

    View Slide

27. 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.
    

    View Slide

28. 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.
    

    View Slide

29. 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
    

    View Slide

30. 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
    

    View Slide

31. 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.
    

    View Slide

32. 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.
    

    View Slide

33. Kubernetes Deployment Strategies
    Blue green deployment.
    

    View Slide

34. 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.
    

    View Slide

35. Kubernetes Deployment Strategies
    Canary deployment.
    

    View Slide

36. 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.
    

    View Slide

37. 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
    .
    

    View Slide

38. 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.
    

    View Slide

39. 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.
    

    View Slide

40. High Level Digital Architecture
    

    View Slide

41. Thank You
    

    View Slide