2. What to expect from the session?
• Review microservices architecture and how it differs
from monolithic and service-oriented architectures
• Key microservices design principles
• Example design patterns for Micro-services in AWS
• Demo
• Q&A
3. Monolithic vs. SOA vs. Microservices
SOA
Coarse-
grained
Microservices
Fine-grained
Monolithic
Single Unit
6. Break warehouse processes into few big blocks
INBOUND
• Track products traveling to the
warehouse
• Receive products
• Prepare products to be stored
• Store products
• Handle inbound defects
• …
OUTBOUND
• Pick customer orders
• Prepare shipments
• Track shipments
• Handle outbound defects
• …
7. Set up Software Teams
INBOUND
• Track products traveling to the warehouse
• Receive products
• Prepare products to be stored
• Store products in the warehouse
• Handle inbound defects
• …
OUTBOUND
• Pick customer orders
• Prepare shipments
• Track shipments
• Report defects
• Handle outbound defects
• …
Inbound Software Team Outbound Software Team
8. Software Teams and Dependencies
Inbound Software Team
50+ developers
Shared libraries
Outbound Software Team
50+ developers
Inbound Software Monolith Outbound Software Monolith
High software
coupling!
9. Long Build/Test/Release Cycles
Inbound Software Team
Outbound Software Team
Build Test Release
Build Test Release
• “I’m constantly having to resolve commit conflicts and merges. This is taking too much of my time!”
• “Our last build attempt failed after 4 hours. We don’t know who broke the build as 30 commits were made”
Massive builds
Long time to
run tests
Ever growing
release binaries
10. Problems With Monolithic Software
System operation is a nightmare
(module X is failing, who’s the owner?)
Lack of agility
(very long time to add new features)
Lack of innovation
(team always busy fixing inefficiencies)
Long Build/Test/Release Cycles
(who broke the build?)
Software architecture is hard to maintain and evolve
Scalability is compromised
(vertical scalability)
Slow development pace
(developers busy fixing issues)
Customers frustrated
(new releases take months)
11. Conway’s Law:
“Any organization that designs a system (defined broadly) will
produce a design whose structure is a copy of the organization's
communication structure.”
Melvyn Conway, 1967
So, it’s not only about changing the software architecture
but also changing the way software teams are organized.
… but How?
http://www.melconway.com/Home/Conways_Law.html
13. What are Microservices?
“A software architecture style in which complex
applications are composed of small, independent
processes communicating with each other using
language-agnostic APIs. These services are small, highly
decoupled and focus on doing a small task, facilitating a
modular approach to system-building.”
14. The Anatomy of a Microservice
Micro-service = Fine-grained Service-oriented architecture + “small” public API
Micro-service
Software Modules
(application code, libraries, etc)
Data Store
(eg, DynamoDB, RDS,
ElastiCache, S3)
Public API
addProductDetails(ProductId id, ProductDetails details)
removeProductDetails(ProductId id)
getProductDetails(ProductId id) : ProductDetails
15. Web of Microservices
Store products in the warehouse
Pick products for customers Report defects
Track shipments
Product Details
16.
17. Benefits of Microservices for Amazon
Build Test Release
Build Test Release
• 50 Million Deployments a Year
• Software enhancements delivered every second
Build Test Release
Build Test Release
Build Test Release
Build Test Release
… … … … … …
Gigantic Web of Micro-services at Amazon
2-pizza Amazon Development Teams
18. Characteristics of Microservice Architectures
Do one
thing well
Independent
Decentralized
Black box
Polyglot
You build it, you run it
20. public API
Principle 1: Microservices only rely on each other’s public API
public API
Microservice A Microservice B
21. public API public API
Principle 1: Microservices only rely on each other’s public API
(Hide Your Data)
Microservice A Microservice B
22. public API
Nope!
Microservice A Microservice B
Principle 1: Microservices only rely on each other’s public API
(Hide Your Data)
public API
23. public API
Microservice A Microservice B
Principle 1: Microservices only rely on each other’s public API
(Hide Your Data)
public API
24. storeRestaurant (id, name, cuisine)
Version 1.0.0
public API
Microservice A
Principle 1: Microservices only rely on each other’s public API
(Evolve API in backward-compatible way…and document!)
25. storeRestaurant (id, name, cuisine)
storeRestaurant (id, name, cuisine)
storeRestaurant (id, name, arbitrary_metadata)
addReview (restaurantId, rating, comments)
Version 1.0.0
Version 1.1.0
public API
Microservice A
Principle 1: Microservices only rely on each other’s public API
(Evolve API in backward-compatible way…and document!)
26. storeRestaurant (id, name, cuisine)
storeRestaurant (id, name, cuisine)
storeRestaurant (id, name, arbitrary_metadata)
addReview (restaurantId, rating, comments)
storeRestaurant (id, name, arbitrary_metadata)
addReview (restaurantId, rating, comments)
Version 1.0.0
Version 1.1.0
Version 2.0.0
public API
Microservice A
Principle 1: Microservices only rely on each other’s public API
(Evolve API in backward-compatible way…and document!)
27. public API public API
DynamoDB
Microservice A Microservice B
Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
28. public API public API
DynamoDB
Microservice A Microservice B
Amazon
Elasticsearch
Service
Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
29. public API public API
RDS
MySQL
Microservice A Microservice B
Amazon
Elasticsearc
Service
Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
30. public API public API
RDS
MySQL
Microservice A Microservice B
Amazon
Elasticsearc
Service
Principle 2: Use the right tool for the job
(Embrace polyglot programming frameworks)
31. public API public API
RDS
Aurora
Microservice A Microservice B
Amazon
Elasticsearc
Service
Principle 2: Use the right tool for the job
(Embrace polyglot programming frameworks)
32. Principle 3: Secure Your Services
• Defense-in-depth
• Network level (e.g. VPC, Security Groups, TLS)
• Server/container-level
• App-level
• IAM policies
• Gateway (“Front door”)
• API Throttling
• Authentication & Authorization
• Client-to-service, as well as service-to-service
• API Gateway: custom Lambda authorizers
• IAM-based Authentication
• Token-based auth (JWT tokens, OAuth 2.0)
• Secrets management
• S3 bucket policies + KMS + IAM
• Open-source tools (e.g. Vault, Keywhiz)
API Gateway
33. Hey Sally, we need
to call your micro-
service to fetch
restaurants details.
Sure Paul. Which APIs
you need to call? Once I
know better your use
cases I’ll give you
permission to register your
service as a client on our
service’s directory entry.
Micro-service A Micro-service B
public API public API
Principle 4: Be a good citizen within the ecosystem
34. Restaurant
Micro-service
15 TPS100 TPS5 TPS20 TPS
Before we let you call
our micro-service we
need to understand
your use case,
expected load (TPS)
and accepted latency
Principle 4: Be a good citizen within the ecosystem
35. …and many,
many others!
Distributed monitoring and tracing
• “Is the service meeting its SLA?”
• “Which services were involved in a request?”
• “How did downstream dependencies perform?”
Shared metrics
• e.g. request time, time to first byte
+ User-experience metrics
Distributed tracing
• e.g. AWS X-Ray, Zipkin, OpenTracing, Wingtips
Principle 4: Be a good citizen within the ecosystem
36. Principle 5: Automate everything
AWS
CodeCommit
AWS
CodePipeline
AWS
CodeDeploy
EC2 ELB
Auto
ScalingLambdaECS
DynamoDBRDS ElastiCache SQS SWF
SES SNS
API GatewayCloudWatch Cloud Trail
KinesisElastic
Beanstalk
Teams depend on each other’s libraries + other common libraries
“We’re blocked as we cannot build our software until you hand us the latest version of your library”
Teams depend on each other’s database schema
“We’re afraid the changes we’re making to our database schema will break your code”
Microservices architectures are not a completely new approach to software engineering, but rather a collection and combination of various successful and proven concepts such as object-oriented methodologies, agile software development, service-oriented architectures, API-first design, and Continuous Delivery.
Talk about implications of replicating data – and eventual consistency
The public API is a contract between your micro-services and its clients and once released will have to be maintained for as long as clients rely on it.
Semantic versioning
The public API is a contract between your micro-services and its clients and once released will have to be maintained for as long as clients rely on it.
Semantic versioning
The public API is a contract between your micro-services and its clients and once released will have to be maintained for as long as clients rely on it.
## Semantic Versioning
Adapt and implement good versioning strategy such as Semantic Versioning - http://semver.org
MAJOR - version when you make incompatible API changes
MINOR - version when you add functionality in a backwards-compatible manner, and
PATCH - version when you make backwards-compatible bug fixes
MAJOR version
This goes both ways:
Service registry
Service owners have a responsibility – publish your health, monitorClients have a responsibility to do exponential backoff – in case there are errors
This goes both ways:
Service owners have a responsibility – publish your health, monitorClients have a responsibility to do exponential backoff – in case there are errors
If it moves, it should be tracked and logged
Spend more time working on code that analyses the meaning of metrics than code that collects, moves, stores and displays metrics
Reduce key business metric latency to less than the human attention span (~10s)
Validate your measurement system has enough accuracy and precision. Collect histograms of response time
Monitoring systems need to be more available and scalable than the systems (and services) being monitored
Optimise for monitoring distributed, ephemeral, 'cloud-native', containerised microservices
Fit metrics to models in order to understand relationships (this is a new rule)
But more important than the technologies are the principles we talked about.