Post on 11-Jun-2020
Managing Chaos – 100 Microservices, 1 Product
April 25th 2019
@ishaGoel88 2
3
Microservices are like these small islands of functionality that can be deployed independently, and they sit atop an underlying messaging infrastructure.
Microservices represents a fundamental shift in how IT approaches software development.
Services are modelled around Business Domain
Reuse - Services can have multiple uses
Autonomous, Cross-functional Teams
Improved Productivity and Speed
Flexibility in Using Technologies and Scalability
Resilience – fault tolerance
4
Think of some Challenges – With Microservices
5
More Parts => More Complexity How to partition/ identify Services Inter Services Communication Security Complexity of Debugging Complex Deployments Need for Automation Complex Testing Maintain all Environment’s Sanity in a Reliable State Healthchecks & Monitoring
AGENDA 1. A Template Microservices Implementation
2. The Unknown Challenges 3. Q & A
6
A Template Microservices Implementation
7
Transformation as the Key – To bring together multiple existing Systems
Technology drivers:
8
EVOLUTIONARY ARCHITECTURE – USING MODERN/NOVEL TECHNOLOGY
SCALABLE, RESILIENT, AVAILABLE & HIGH PERFORMANCE
AUTOMATED & DEVOPS ENABLED
SEAMLESS & STANDARDIZED INTEGRATION
FLEXIBLE & RESPONSIVE USER EXPERIENCE
GUIDING PRINCIPLES
Architectural options and decisions have to be based on industry best practices and Sapient’s depth of experience, in order to de-risk implementation and establish a simple, strategic, enduring and extensible architectural solution.
9
REFERENCE TECHNOLOGY STACK
10
REFERENCE LOGICAL ARCHITECTURE
11
Challenges with the Architectural decision
12
The Unknown Challenges
13
Multiple Parallel Releases Development
Configuration Management
API Orchestration & Logging
Monolithic Database
Deployments
The Unknown Challenges
14
Multiple Parallel Releases Development
Configuration Management
API Orchestration & Logging
Monolithic Database
Deployments
Multiple Parallel Releases Development
15
Challenges with parallel multi Release development • Merging multiple Release Streams • Days required to stabilize Environments post merge. High Regression • Last minute Rush to Turn off Feature or cherry picking to merge feature from another release
PC: gocd.org
16
Feature Toggles – • In a single branch development, particularly when we want to keep integrating frequently, we might find
ourselves not ready to release a certain piece of functionality. Feature flags can come in handy to enable us to keep releasing without making our changes available until complete.
• In Environment specific configuration, we could take advantage of feature flags to toggle the right setup in the right environment.
17
Approach • Segregate functions, classes. Apply patterns, for e.g., Strategy. • API Versioning – Create new Endpoints altogether. • Apply If-else conditions based on the feature flag.
Post Release Cleanup • Cleanup would be an important activity after the Main Release. • Its important to tag Code that needs to be cleaned up after the Release. Deprecated Annotation (@Deprecated) or
Javadoc tag needs to be used wherever applicable. • A Custom annotation might come handy to identify the removable code.
The Unknown Challenges
18
Multiple Parallel Releases Development
Configuration Management
API Orchestration & Logging
Monolithic Database
Deployments
Configuration Management
19
All application properties were maintained in deployment repositories for each environment. • Property change needed deployment of application resulting in downtime • Property misses between environment upgrades • Effort intensive
20
Configuration Service –
• All properties to be managed in environment specific branch • One property file specific to each Service and common properties across services to be kept in
application.properties file • Configuration Service to expose endpoint to poll the Git repositories for property changes and publish to all
the Services via MQ.
The Unknown Challenges
21
Multiple Parallel Releases Development
Configuration Management
API Orchestration & Logging
Monolithic Database
Deployments
API Orchestration & Logging
22
API orchestration provides • An approach to integration that decouples APIs from each other • Capabilities for message routing, security, transformation and reliability • A way to manage and monitor your integrations centrally • Mediation, to provide multiple channels/interfaces for the same underlying implementation
23
• Centralized and Externalized Log Storage
• Log Structured Data • Searchable Logs
• Generate Correlation Id on the 1st Microservice call and pass the same to all the downstream Services.
• We used UserId to work as the Correlation Id.
The Unknown Challenges
24
Multiple Parallel Releases Development
Configuration Management
API Orchestration & Logging
Monolithic Database
Deployments
25
Monolothic Database
Ideally, Microservices should follow: - Distributed Data Management - Domain Driven Design - Event driven architecture, no distributed transactions
Limitation for not going with Distributed Databases.
The Unknown Challenges
26
Multiple Parallel Releases Development
Configuration Management
API Orchestration & Logging
Monolithic Database
Deployments
Challenges with Deployments – • Time consuming deployments • Zero-downtime deployment
Deployments
27
Content & Service
System, Domain, UI Services
Database Scripts
Deployable Artefacts
References:
1.https://paulhammant.com/2013/04/05/what-is-trunk-based-development/
2.https://spring.io/guides/gs/centralized-configuration/
3.https://dzone.com/articles/correlation-id-for-logging-in-microservices
4.https://dzone.com/articles/zero-downtime-deployments-with-containers
5.https://dzone.com/articles/blue-green-deployments-ab-testing-and-canary-relea-2
28
thank you
copyright publicis sapient | confidential 29
30