The introduction covers the following
1. What are Microservices and why should be use this paradigm?
2. 12 factor apps and how Microservices make it easier to create them
3. Characteristics of Microservices
Note: Please download the slides to view animations.
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
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.
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.
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)
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
Loosely coupled service oriented architecture with bounded context – Adrian Cockcroft
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
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
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
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