SlideShare a Scribd company logo
1 of 46
Introduction to
Microservices
About Me!
Anil Allewar
• Technology Evangelist
& speaker
• Core interests: Cloud,
Enterprise, Mobile
Agenda
• What are Microservices?
• SaaS and 12-Factor apps
• Typical Use Cases
• Why Microservices?
• Characteristics
Software Architecture Evolution
http://www.kanbansolutions.com/blog/microservices-architecture-friend-or-foe/
Monolith
Microservices
Crux of Microservices
Bounded business
context
What are Microservices actually?
Services build around
bounded business
context
Independent
development, testing and
deployment
Interact with end-user
and with each other
using well defined
contract
De-centralized data
management and
governance
Automated
deployments
Intelligence in the
endpoints and dumb
pipes
Agenda
• What are Microservices?
• SaaS and 12-Factor apps
• Typical Use Cases
• Why Microservices?
• Characteristics
SaaS & 12-Factor Apps
Software-As-A-Service
• Subscribe to software – periodic contract
• Scalability – horizontal
• Multi-tenancy
12-Factor apps
• Methodology for building SaaS apps
Majority of Microservices & distributed system concerns
are defined by 12-factor methodology
12-Factors
1. Codebase
• Single codebase for one app - tracked in revision control
• If more than 1 app then each has it’s own codebase - distributed system
2. Dependencies
• Declared explicitly through dependency manifest - gradle, maven, npm
• Dependency isolation - no implicit dependencies, gradle
dependencyManagement for exact version of dependency
• Simplify developer setup
• Project dependencies - build system (gradle)
• Runtime dependencies - containers (docker, linux lxc)
12-Factors
3. Processes
• Stateless - share nothing
• Persistent data needs to be stored in stateful backing service like database
4. Port binding
• Export HTTP as a service by binding to a port
• In built web server like Tomcat for Spring boot
5. Concurrency
• Different process models for different tasks - WebServer for HTTP, workers for
background
• Multiple processes on multiple machines - easy to scale out
12-Factors
6. Config
• Strict separation of config from code
• Hosted externally or setup as environment variables
7. Backing services
• Databases, message queue system, S3 etc
• Treat as attached resources accessed over a URL
• No code changes needed for resource swap - local mySQL with RDS
8. Build, release run
• Strictly separate build (say gradle), release(say Jenkins) and run (say docker
orchestration)
• Ability to rollback to previous release
12-Factors
9. Disposability
• Started or stopped at moments notice
• Pets v/s Cattle
10. Dev/prod parity
• DevOps, quick deploys
• Use Docker and external configuration
11. Logs
• Treat logs as event streams routed to common destination
• ELK stack, Fluent etc
12-Factors
12. Admin processes
• One off administrative maintenance tasks like database migration,
running one-time scripts
• Must ship with application code
Agenda
• What are Microservices?
• SaaS and 12-Factor apps
• Typical Use Cases
• Why Microservices?
• Characteristics
Communication
Silos
Business Agility
Scale Cube
To ensure scalability – applications should be able to scale in at-least 2 axis
Agenda
• What are Microservices?
• SaaS and 12-Factor apps
• Typical Use Cases
• Why Microservices?
• Characteristics
Who is doing microservices?
Monolith
Horizontal
scaling
3-4 months
gestation
Fear of release
Quicker competitorsGo-live firefighting
Unintended side
effects
Recruitment
Monolith
Release – 4
months
Chipping The Monolith
Large Distributed System
APIGateway
(Zuul)
Config
Server
Registry/Di
scovery
(Eureka)
Circuit
Breaker
(Hystrix)
Web Portal
Web
Service 1
Web
Service 2
Web
Service 3
Web
Service 4
DB2DB1
Auth Server
Auth-DB
Ribbon RibbonRibbon
Web
Apps
Mobile
Apps
3rd Party
Integration
Github
Registry
Dashboard
Health
Dashboard
OAuth 2.0
Security
Metering
Load Bal
Routing
Agenda
• What are Microservices?
• SaaS and 12-Factor apps
• Typical Use Cases
• Why Microservices?
• Characteristics
Characteristics of Microservices
Componentization via Services
Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design
Aligned towards developing cloud native SaaS application following Twelve Factor Apps
Componentization via Services
Any Failure means
redeploy entire application
Failures means only that
microservice is redeployed.
Circuit Breakers can help stop
propagate the effect
May or May not have
published interfaces
between components
Restful APIs mostly are the
published interfaces.
Organized around Business Capabilities
Products not Projects
Project Model
Product Model
Amazon Model- You Build it, You run it !
Decentralized Governance
nodejavarubyR
hbase
redismysql
Decentralized Data Management
Infrastructure Automation
Continuous Delivery A Must
Monolith Microservice
Design for failure
Microservices needs following to function
1. Circuit Breaker – Fallback Response
2. Detect Failure Early
3. Automatic Restore
Evolutionary Design
Drive modularity through the pattern of change
Ongoing service decomposition - independent
replacement and upgradeability
You want to keep things that change at the same time in
the same module
Microservices - Challenges
If you can’t build a well-designed modular monolith, what makes
you think Microservices is the answer? – Simon Brown
If not well designed – Microservices would become distributed ball
of mud (though more modular!)
Well defined software modules in monolith(Domain Driven Design)
is pre-requisite to converting it to micro-services
Hence always try to start as monolith (more agile) and then
decompose to Micro-services once modularity & complexity is
prime concern
Organization & Architecture Changes
Attempt Microservices to transform your business
Microservices will trigger organization change
Learning organization
Deliberate & discuss – benefits v/s risks
Versioning of contracts between services
Dormant Monolith
Automation and DevOps intrinsic to Microservices
Organization & Architecture Changes
Monolith first - Version 1.x of system
Domain driven design – services with well defined seams
Peel off Microservices once complexity and scaling needs
affect productivity & innovation
Invest in product management and QA
Containers & Orchestration
Considerations
Upfront planning & decomposition of business services - else
spaghetti architecture
Avoid distributed monolith – Things that change at the same
time should be in the same service
Monitoring Microservices is order of magnitude harder –
deployment map & health status
Centralized logging, alerting and distributed tracing - critical to
debug & resolve production issues
Circuit breakers to prevent chain of failure
Considerations
Issue in service A could be because of input from service B or
messaging queue - APM tools & strong service contracts to
isolate root cause
Services graph - Dependency and version management
IT Governance – streamline tools & methodology
Track what service API gets exposed and their security
Consumer driven contracts for robust API – check out Pact /
PactJVM
Microservices Frameworks
Spring Stack - Java
Spring Boot, Spring Cloud withNetflix OSS/Consul
Most stable and mature Microservices platform
Opinionated view of building production applications
using Spring framework – convention over configuration
Supports both synchronous HTTP and reactive micro-
services
Additional support for streams, tasks, AWS, distributed
tracing etc.
Vert.x
Vert.x is a tool-kit for building reactive applications on the
JVM
Event-driven and non-blocking using asynchronous
message passing
Can be used with multiple languages including Java,
JavaScript, Groovy, Ruby, and Ceylon
Based on Java 8 so you can write elegant code using
lambda and streams
Lightbend Lagom
Lagom is an integrated microservice platform built in Scala
APIs initially are provided for Java services, with Scala to
follow
Provides for asynchronous communications and event-
sourcing (capture all changes to the application as a
sequence of events)
Seneca
Seneca is a Microservices toolkit for Node.js
Seneca has the following three core features:
• Pattern matching: Instead of fragile service discovery, you just let the
world know what sort of messages you care about.
• Transport independence: You can send messages between services in
many ways, all hidden from your business logic.
• Componentization: Functionality is expressed as a set of plugins which
can be composed together as Microservices.
Contact Me
anilallewar@yahoo.co.in
https://www.linkedin.com/in/anilallewar
https://github.com/anilallewar
http://www.slideshare.net/anilallewar
@anilallewar

More Related Content

What's hot

What's hot (20)

Monoliths and Microservices
Monoliths and Microservices Monoliths and Microservices
Monoliths and Microservices
 
Microservice Architecture Patterns, by Richard Langlois P. Eng.
Microservice Architecture Patterns, by Richard Langlois P. Eng.Microservice Architecture Patterns, by Richard Langlois P. Eng.
Microservice Architecture Patterns, by Richard Langlois P. Eng.
 
Introduction To Microservices
Introduction To MicroservicesIntroduction To Microservices
Introduction To Microservices
 
Architecture: Microservices
Architecture: MicroservicesArchitecture: Microservices
Architecture: Microservices
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
 
Micro services Architecture
Micro services ArchitectureMicro services Architecture
Micro services Architecture
 
Understanding MicroSERVICE Architecture with Java & Spring Boot
Understanding MicroSERVICE Architecture with Java & Spring BootUnderstanding MicroSERVICE Architecture with Java & Spring Boot
Understanding MicroSERVICE Architecture with Java & Spring Boot
 
Design patterns for microservice architecture
Design patterns for microservice architectureDesign patterns for microservice architecture
Design patterns for microservice architecture
 
Microservice vs. Monolithic Architecture
Microservice vs. Monolithic ArchitectureMicroservice vs. Monolithic Architecture
Microservice vs. Monolithic Architecture
 
Microservices architecture
Microservices architectureMicroservices architecture
Microservices architecture
 
Springboot Microservices
Springboot MicroservicesSpringboot Microservices
Springboot Microservices
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
 
Introduction to AWS Lambda and Serverless Applications
Introduction to AWS Lambda and Serverless ApplicationsIntroduction to AWS Lambda and Serverless Applications
Introduction to AWS Lambda and Serverless Applications
 
Microservice Architecture
Microservice ArchitectureMicroservice Architecture
Microservice Architecture
 
Microservices
MicroservicesMicroservices
Microservices
 
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...Microservice Architecture | Microservices Tutorial for Beginners | Microservi...
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...
 
Microservice architecture design principles
Microservice architecture design principlesMicroservice architecture design principles
Microservice architecture design principles
 
02 api gateway
02 api gateway02 api gateway
02 api gateway
 
Microservices in Practice
Microservices in PracticeMicroservices in Practice
Microservices in Practice
 
Microservices Architectures on Amazon Web Services
Microservices Architectures on Amazon Web ServicesMicroservices Architectures on Amazon Web Services
Microservices Architectures on Amazon Web Services
 

Similar to Introduction to microservices

Similar to Introduction to microservices (20)

Best Practices Building Cloud Scale Apps with Microservices
Best Practices Building Cloud Scale Apps with MicroservicesBest Practices Building Cloud Scale Apps with Microservices
Best Practices Building Cloud Scale Apps with Microservices
 
170215 msa intro
170215 msa intro170215 msa intro
170215 msa intro
 
Microservices for Enterprises
Microservices for Enterprises Microservices for Enterprises
Microservices for Enterprises
 
Application Centric Microservices from Redhat Summit 2015
Application Centric Microservices from Redhat Summit 2015Application Centric Microservices from Redhat Summit 2015
Application Centric Microservices from Redhat Summit 2015
 
[WSO2Con EU 2017] Microservices for Enterprises
[WSO2Con EU 2017] Microservices for Enterprises[WSO2Con EU 2017] Microservices for Enterprises
[WSO2Con EU 2017] Microservices for Enterprises
 
Microservices Architecture, Monolith Migration Patterns
Microservices Architecture, Monolith Migration PatternsMicroservices Architecture, Monolith Migration Patterns
Microservices Architecture, Monolith Migration Patterns
 
MicroserviceArchitecture in detail over Monolith.
MicroserviceArchitecture in detail over Monolith.MicroserviceArchitecture in detail over Monolith.
MicroserviceArchitecture in detail over Monolith.
 
#dbhouseparty - Should I be building Microservices?
#dbhouseparty - Should I be building Microservices?#dbhouseparty - Should I be building Microservices?
#dbhouseparty - Should I be building Microservices?
 
microservices-is-it-the-holy-grail-a-perspective.pdf
microservices-is-it-the-holy-grail-a-perspective.pdfmicroservices-is-it-the-holy-grail-a-perspective.pdf
microservices-is-it-the-holy-grail-a-perspective.pdf
 
Stay productive while slicing up the monolith
Stay productive while slicing up the monolithStay productive while slicing up the monolith
Stay productive while slicing up the monolith
 
Stay productive while slicing up the monolith
Stay productive while slicing up the monolithStay productive while slicing up the monolith
Stay productive while slicing up the monolith
 
Pros & Cons of Microservices Architecture
Pros & Cons of Microservices ArchitecturePros & Cons of Microservices Architecture
Pros & Cons of Microservices Architecture
 
Microservices Docker Kubernetes Istio Kanban DevOps SRE
Microservices Docker Kubernetes Istio Kanban DevOps SREMicroservices Docker Kubernetes Istio Kanban DevOps SRE
Microservices Docker Kubernetes Istio Kanban DevOps SRE
 
Microservices: Where do they fit within a rapidly evolving integration archit...
Microservices: Where do they fit within a rapidly evolving integration archit...Microservices: Where do they fit within a rapidly evolving integration archit...
Microservices: Where do they fit within a rapidly evolving integration archit...
 
Micro service session 1
Micro service   session 1Micro service   session 1
Micro service session 1
 
Microservices
MicroservicesMicroservices
Microservices
 
Cloud Native In-Depth
Cloud Native In-DepthCloud Native In-Depth
Cloud Native In-Depth
 
Monoliths to Microservices with Jave EE and Spring Boot
Monoliths to Microservices with Jave EE and Spring BootMonoliths to Microservices with Jave EE and Spring Boot
Monoliths to Microservices with Jave EE and Spring Boot
 
3298 microservices and how they relate to esb api and messaging - inter con...
3298   microservices and how they relate to esb api and messaging - inter con...3298   microservices and how they relate to esb api and messaging - inter con...
3298 microservices and how they relate to esb api and messaging - inter con...
 
03 monoliths to microservices with java ee and spring boot
03 monoliths to microservices with java ee and spring boot03 monoliths to microservices with java ee and spring boot
03 monoliths to microservices with java ee and spring boot
 

Recently uploaded

%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
masabamasaba
 
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
masabamasaba
 
%+27788225528 love spells in Atlanta Psychic Readings, Attraction spells,Brin...
%+27788225528 love spells in Atlanta Psychic Readings, Attraction spells,Brin...%+27788225528 love spells in Atlanta Psychic Readings, Attraction spells,Brin...
%+27788225528 love spells in Atlanta Psychic Readings, Attraction spells,Brin...
masabamasaba
 
%+27788225528 love spells in Boston Psychic Readings, Attraction spells,Bring...
%+27788225528 love spells in Boston Psychic Readings, Attraction spells,Bring...%+27788225528 love spells in Boston Psychic Readings, Attraction spells,Bring...
%+27788225528 love spells in Boston Psychic Readings, Attraction spells,Bring...
masabamasaba
 

Recently uploaded (20)

Direct Style Effect Systems - The Print[A] Example - A Comprehension Aid
Direct Style Effect Systems -The Print[A] Example- A Comprehension AidDirect Style Effect Systems -The Print[A] Example- A Comprehension Aid
Direct Style Effect Systems - The Print[A] Example - A Comprehension Aid
 
%in kaalfontein+277-882-255-28 abortion pills for sale in kaalfontein
%in kaalfontein+277-882-255-28 abortion pills for sale in kaalfontein%in kaalfontein+277-882-255-28 abortion pills for sale in kaalfontein
%in kaalfontein+277-882-255-28 abortion pills for sale in kaalfontein
 
VTU technical seminar 8Th Sem on Scikit-learn
VTU technical seminar 8Th Sem on Scikit-learnVTU technical seminar 8Th Sem on Scikit-learn
VTU technical seminar 8Th Sem on Scikit-learn
 
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
 
%+27788225528 love spells in Vancouver Psychic Readings, Attraction spells,Br...
%+27788225528 love spells in Vancouver Psychic Readings, Attraction spells,Br...%+27788225528 love spells in Vancouver Psychic Readings, Attraction spells,Br...
%+27788225528 love spells in Vancouver Psychic Readings, Attraction spells,Br...
 
Microsoft AI Transformation Partner Playbook.pdf
Microsoft AI Transformation Partner Playbook.pdfMicrosoft AI Transformation Partner Playbook.pdf
Microsoft AI Transformation Partner Playbook.pdf
 
The Top App Development Trends Shaping the Industry in 2024-25 .pdf
The Top App Development Trends Shaping the Industry in 2024-25 .pdfThe Top App Development Trends Shaping the Industry in 2024-25 .pdf
The Top App Development Trends Shaping the Industry in 2024-25 .pdf
 
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
 
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
 
Crypto Cloud Review - How To Earn Up To $500 Per DAY Of Bitcoin 100% On AutoP...
Crypto Cloud Review - How To Earn Up To $500 Per DAY Of Bitcoin 100% On AutoP...Crypto Cloud Review - How To Earn Up To $500 Per DAY Of Bitcoin 100% On AutoP...
Crypto Cloud Review - How To Earn Up To $500 Per DAY Of Bitcoin 100% On AutoP...
 
Exploring the Best Video Editing App.pdf
Exploring the Best Video Editing App.pdfExploring the Best Video Editing App.pdf
Exploring the Best Video Editing App.pdf
 
%in Midrand+277-882-255-28 abortion pills for sale in midrand
%in Midrand+277-882-255-28 abortion pills for sale in midrand%in Midrand+277-882-255-28 abortion pills for sale in midrand
%in Midrand+277-882-255-28 abortion pills for sale in midrand
 
%+27788225528 love spells in Atlanta Psychic Readings, Attraction spells,Brin...
%+27788225528 love spells in Atlanta Psychic Readings, Attraction spells,Brin...%+27788225528 love spells in Atlanta Psychic Readings, Attraction spells,Brin...
%+27788225528 love spells in Atlanta Psychic Readings, Attraction spells,Brin...
 
call girls in Vaishali (Ghaziabad) 🔝 >༒8448380779 🔝 genuine Escort Service 🔝✔️✔️
call girls in Vaishali (Ghaziabad) 🔝 >༒8448380779 🔝 genuine Escort Service 🔝✔️✔️call girls in Vaishali (Ghaziabad) 🔝 >༒8448380779 🔝 genuine Escort Service 🔝✔️✔️
call girls in Vaishali (Ghaziabad) 🔝 >༒8448380779 🔝 genuine Escort Service 🔝✔️✔️
 
%in Harare+277-882-255-28 abortion pills for sale in Harare
%in Harare+277-882-255-28 abortion pills for sale in Harare%in Harare+277-882-255-28 abortion pills for sale in Harare
%in Harare+277-882-255-28 abortion pills for sale in Harare
 
Payment Gateway Testing Simplified_ A Step-by-Step Guide for Beginners.pdf
Payment Gateway Testing Simplified_ A Step-by-Step Guide for Beginners.pdfPayment Gateway Testing Simplified_ A Step-by-Step Guide for Beginners.pdf
Payment Gateway Testing Simplified_ A Step-by-Step Guide for Beginners.pdf
 
Generic or specific? Making sensible software design decisions
Generic or specific? Making sensible software design decisionsGeneric or specific? Making sensible software design decisions
Generic or specific? Making sensible software design decisions
 
%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
 
8257 interfacing 2 in microprocessor for btech students
8257 interfacing 2 in microprocessor for btech students8257 interfacing 2 in microprocessor for btech students
8257 interfacing 2 in microprocessor for btech students
 
%+27788225528 love spells in Boston Psychic Readings, Attraction spells,Bring...
%+27788225528 love spells in Boston Psychic Readings, Attraction spells,Bring...%+27788225528 love spells in Boston Psychic Readings, Attraction spells,Bring...
%+27788225528 love spells in Boston Psychic Readings, Attraction spells,Bring...
 

Introduction to microservices

  • 2. About Me! Anil Allewar • Technology Evangelist & speaker • Core interests: Cloud, Enterprise, Mobile
  • 3. Agenda • What are Microservices? • SaaS and 12-Factor apps • Typical Use Cases • Why Microservices? • Characteristics
  • 7. Crux of Microservices Bounded business context
  • 8. What are Microservices actually? Services build around bounded business context Independent development, testing and deployment Interact with end-user and with each other using well defined contract De-centralized data management and governance Automated deployments Intelligence in the endpoints and dumb pipes
  • 9. Agenda • What are Microservices? • SaaS and 12-Factor apps • Typical Use Cases • Why Microservices? • Characteristics
  • 10. SaaS & 12-Factor Apps Software-As-A-Service • Subscribe to software – periodic contract • Scalability – horizontal • Multi-tenancy 12-Factor apps • Methodology for building SaaS apps Majority of Microservices & distributed system concerns are defined by 12-factor methodology
  • 11. 12-Factors 1. Codebase • Single codebase for one app - tracked in revision control • If more than 1 app then each has it’s own codebase - distributed system 2. Dependencies • Declared explicitly through dependency manifest - gradle, maven, npm • Dependency isolation - no implicit dependencies, gradle dependencyManagement for exact version of dependency • Simplify developer setup • Project dependencies - build system (gradle) • Runtime dependencies - containers (docker, linux lxc)
  • 12. 12-Factors 3. Processes • Stateless - share nothing • Persistent data needs to be stored in stateful backing service like database 4. Port binding • Export HTTP as a service by binding to a port • In built web server like Tomcat for Spring boot 5. Concurrency • Different process models for different tasks - WebServer for HTTP, workers for background • Multiple processes on multiple machines - easy to scale out
  • 13. 12-Factors 6. Config • Strict separation of config from code • Hosted externally or setup as environment variables 7. Backing services • Databases, message queue system, S3 etc • Treat as attached resources accessed over a URL • No code changes needed for resource swap - local mySQL with RDS 8. Build, release run • Strictly separate build (say gradle), release(say Jenkins) and run (say docker orchestration) • Ability to rollback to previous release
  • 14. 12-Factors 9. Disposability • Started or stopped at moments notice • Pets v/s Cattle 10. Dev/prod parity • DevOps, quick deploys • Use Docker and external configuration 11. Logs • Treat logs as event streams routed to common destination • ELK stack, Fluent etc
  • 15. 12-Factors 12. Admin processes • One off administrative maintenance tasks like database migration, running one-time scripts • Must ship with application code
  • 16. Agenda • What are Microservices? • SaaS and 12-Factor apps • Typical Use Cases • Why Microservices? • Characteristics
  • 18. Silos
  • 20. Scale Cube To ensure scalability – applications should be able to scale in at-least 2 axis
  • 21. Agenda • What are Microservices? • SaaS and 12-Factor apps • Typical Use Cases • Why Microservices? • Characteristics
  • 22. Who is doing microservices?
  • 23. Monolith Horizontal scaling 3-4 months gestation Fear of release Quicker competitorsGo-live firefighting Unintended side effects Recruitment Monolith Release – 4 months
  • 25. Large Distributed System APIGateway (Zuul) Config Server Registry/Di scovery (Eureka) Circuit Breaker (Hystrix) Web Portal Web Service 1 Web Service 2 Web Service 3 Web Service 4 DB2DB1 Auth Server Auth-DB Ribbon RibbonRibbon Web Apps Mobile Apps 3rd Party Integration Github Registry Dashboard Health Dashboard OAuth 2.0 Security Metering Load Bal Routing
  • 26. Agenda • What are Microservices? • SaaS and 12-Factor apps • Typical Use Cases • Why Microservices? • Characteristics
  • 27. Characteristics of Microservices Componentization via Services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Evolutionary Design Aligned towards developing cloud native SaaS application following Twelve Factor Apps
  • 28. Componentization via Services Any Failure means redeploy entire application Failures means only that microservice is redeployed. Circuit Breakers can help stop propagate the effect May or May not have published interfaces between components Restful APIs mostly are the published interfaces.
  • 30. Products not Projects Project Model Product Model Amazon Model- You Build it, You run it !
  • 33. Infrastructure Automation Continuous Delivery A Must Monolith Microservice
  • 34. Design for failure Microservices needs following to function 1. Circuit Breaker – Fallback Response 2. Detect Failure Early 3. Automatic Restore
  • 35. Evolutionary Design Drive modularity through the pattern of change Ongoing service decomposition - independent replacement and upgradeability You want to keep things that change at the same time in the same module
  • 36. Microservices - Challenges If you can’t build a well-designed modular monolith, what makes you think Microservices is the answer? – Simon Brown If not well designed – Microservices would become distributed ball of mud (though more modular!) Well defined software modules in monolith(Domain Driven Design) is pre-requisite to converting it to micro-services Hence always try to start as monolith (more agile) and then decompose to Micro-services once modularity & complexity is prime concern
  • 37. Organization & Architecture Changes Attempt Microservices to transform your business Microservices will trigger organization change Learning organization Deliberate & discuss – benefits v/s risks Versioning of contracts between services Dormant Monolith Automation and DevOps intrinsic to Microservices
  • 38. Organization & Architecture Changes Monolith first - Version 1.x of system Domain driven design – services with well defined seams Peel off Microservices once complexity and scaling needs affect productivity & innovation Invest in product management and QA Containers & Orchestration
  • 39. Considerations Upfront planning & decomposition of business services - else spaghetti architecture Avoid distributed monolith – Things that change at the same time should be in the same service Monitoring Microservices is order of magnitude harder – deployment map & health status Centralized logging, alerting and distributed tracing - critical to debug & resolve production issues Circuit breakers to prevent chain of failure
  • 40. Considerations Issue in service A could be because of input from service B or messaging queue - APM tools & strong service contracts to isolate root cause Services graph - Dependency and version management IT Governance – streamline tools & methodology Track what service API gets exposed and their security Consumer driven contracts for robust API – check out Pact / PactJVM
  • 42. Spring Stack - Java Spring Boot, Spring Cloud withNetflix OSS/Consul Most stable and mature Microservices platform Opinionated view of building production applications using Spring framework – convention over configuration Supports both synchronous HTTP and reactive micro- services Additional support for streams, tasks, AWS, distributed tracing etc.
  • 43. Vert.x Vert.x is a tool-kit for building reactive applications on the JVM Event-driven and non-blocking using asynchronous message passing Can be used with multiple languages including Java, JavaScript, Groovy, Ruby, and Ceylon Based on Java 8 so you can write elegant code using lambda and streams
  • 44. Lightbend Lagom Lagom is an integrated microservice platform built in Scala APIs initially are provided for Java services, with Scala to follow Provides for asynchronous communications and event- sourcing (capture all changes to the application as a sequence of events)
  • 45. Seneca Seneca is a Microservices toolkit for Node.js Seneca has the following three core features: • Pattern matching: Instead of fragile service discovery, you just let the world know what sort of messages you care about. • Transport independence: You can send messages between services in many ways, all hidden from your business logic. • Componentization: Functionality is expressed as a set of plugins which can be composed together as Microservices.

Editor's Notes

  1. Microservices Loosely coupled service oriented architecture with bounded context - Adrian Cockcroft Developing single application as a suite of independent small services Each service is running in it’s own process and communicating over lightweight protocols like HTTP (synchronous) or over a lightweight message bus like Akka (reactive / asynchronous)
  2. Services build around bounded business context - Bounded Context is a central pattern in Domain-Driven Design Dividing the business model into different bounded context – the bounded context can have unified model like order and order items Explicit about relationship between the context Creating whole domain model is not feasible or costs too much resources
  3. Loosely coupled service oriented architecture with bounded context – Adrian Cockcroft
  4. In the new world, it is not the big fish which eats the small fish, it’s the fast fish which eats the slow fish. —Klaus Schwab, Chairman World Economic Forum
  5. http://theartofscalability.com/ - Abbot & Fisher X Axis – Horizontal scaling Handles 1/N of the load Load balancers needs to do round-robin or resource based allocation of requests If caching, then potentially all data can be cached at each application copy Can’t handle increased application complexity and cost of development Y Axis – Functional decomposition Microservices architecture is one implementation of this scaling methodology Z axis – Partitioning / Sharding Each server runs identical copy of the application But each server is responsible for serving requests for a particular subset of data, say employees between ids 1-1000, 1001-2000 and so on Load balancer needs to be smart – route traffic based on partitioning rules Solves some of the problems of X-axis scaling – notably cache and fault isolation Still Can’t handle increased application complexity and cost of development
  6. Microservices will trigger organization change Cross functional teams that owns the whole functionality – Dev, QA, Product Owner, DBA -> Conway’s law Freedom and responsibility You build it, you run it! Learning Organization Continuously transform itself to stay ahead of competitors Microservices are not about agility, being tech savvy or cloud transformation – it’s about innovation & building business model Smaller agile team of developers – Innovative, nimble & embracing change Lean startup – MVP, feedback -> continue/pivot/stop Versioning of Contracts Enforce version contracts so that different versions of Microservices can communicate with one another Deploy only versions that play well with each other Forward compatibility & Backward compatibity Benefits Release cycle - 4-6 weeks Fully independent team Parallel development Cleaner API design “Fear of change” to “Eagerness to peel off the monolith” Challenges What to peel off Distributed systems are complex Versioning of contracts Operations overhead Testing
  7. Monolith first! Don’t even consider Microservices unless your system is really complex System complexity and business component boundaries evolve Monolith provides agility, innovation and speed when starting with MVP Microservices come with a premium of managing suite of services Martin Fowler Almost all the successful microservice stories have started with a monolith that got too big and was broken up Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. Recommend Microservices first approach for Monolith rewrite When you know the domain really really well! Containers & Orchestration Package services as containers - run on any platform Container Orchestration – Kubernetes, Swarm, Rancher Monitoring Failover and auto-scaling CI/CD Workflows – code defined, testable and repeatable Benefits Common infrastructure Products as monolith –respond to MVP feedback and pivot/continue Scaling independently Teams talk to each other Opened new possibilities – from on-prem Enterprise to SaaS on cloud Challenges Tools and design of distributed systems Monitoring – Way harder than monolith Cloud native deployment Domain driven design – services with well defined seams