Microservices architectures are changing the way that organizations build their applications and infrastructure. Companies can now achieve new levels of scale and efficiency by disaggregating their large, monolithic applications into small, independent “micro services”, each of which perform different functions. In this session, we’ll introduce the concept of microservices, help you evaluate whether your organization is ready for microservices, and discuss methods for implementing these architectures.
11. Challenges with monolithic software
Long
Build/Test/Release
Cycles
(who broke the
build?)
Operations
is a nightmare
(module X is failing,
who’s the owner?)
Difficult to
scale
New releases
take months
Long time to add
new features
Architecture
is hard to
maintain and
evolve
Lack of innovation
Frustrated
customers
Lack of
agility
12. Challenges with monolithic software
Long
Build/Test/Release
Cycles
(who broke the
build?)
Operations
is a nightmare
(module X is failing,
who’s the owner?)
Difficult to
scale
New releases
take months
Long time to add
new features
Architecture is
hard to maintain
and evolve
Lack of innovation
Frustrated
customers
Lack of
agility
13. Challenges with monolithic software
Long
Build/Test/Release
Cycles
(who broke the
build?)
Operations
is a nightmare
(module X is failing,
who’s the owner?)
Difficult to
scale
New releases
take months
Long time to add
new features
Architecture is
hard to maintain
and evolve
Lack of innovation
Frustrated
customers
Lack of
agility
14. “20080219BonMorningDSC_0022B” by Sunphol Sorakul . No alterations other than cropping. https://www.flickr.com/photos/83424882@N00/3483881705/
Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
19. Evolving towards microservices
“IMG_1760” by Robert Couse-Baker. No alterations other than cropping. https://www.flickr.com/photos/29233640@N07/14859431605/
Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
25. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (former Cloud Architect at Netflix,
now Technology Fellow at Battery Ventures)
You can update the
services independently;
updating one service
doesn’t require changing
any other services.
26. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (former Cloud Architect at Netflix,
now Technology Fellow at Battery Ventures)
Self-contained; you can
update the code without
knowing anything about
the internals of other
microservices
27. “Do one thing, and do it well”
“Swiss Army” by by Jim Pennucci. No alterations other than cropping. https://www.flickr.com/photos/pennuja/5363518281/
Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
28. “Tools” by Tony Walmsley: No alterations other than cropping. https://www.flickr.com/photos/twalmsley/6825340663/
Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
“Do one thing, and do it well”
32. Public API
POST /restaurants
GET /restaurants
Application/Logic
(code, libraries, etc)
Anatomy of a Micro-service
Data Store
(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)
38. = 50 million deployments a year
Thousands of teams
× Microservice architecture
× Continuous delivery
× Multiple environments
(5708 per hour, or every 0.63 second)
43. Principle 1
Micro-services
only rely on each
other’s public
API
“Contracts” by NobMouse. No alterations other than cropping.
https://www.flickr.com/photos/nobmouse/4052848608/
Image used with permissions under Creative Commons license 2.0, Attribution
Generic License (https://creativecommons.org/licenses/by/2.0/)
44. public API
Principle 1: Micro-services only rely on each other’s public API
public API
Micro-service A Micro-service B
45. public API public API
Principle 1: Micro-services only rely on each other’s public API
(Hide Your Data)
Micro-service A Micro-service B
46. public API
Nope!
Micro-service A Micro-service B
Principle 1: Micro-services only rely on each other’s public API
(Hide Your Data)
public API
47. public API
Micro-service A Micro-service B
Principle 1: Micro-services only rely on each other’s public API
(Hide Your Data)
public API
48. storeRestaurant (id, name, cuisine)
Version 1.0.0
public API
Micro-service A
Principle 1: Micro-services only rely on each other’s public API
(Evolve API in backward-compatible way…and document!)
49. 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
Micro-service A
Principle 1: Micro-services only rely on each other’s public API
(Evolve API in backward-compatible way…and document!)
50. 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
Micro-service A
Principle 1: Micro-services only rely on each other’s public API
(Evolve API in backward-compatible way…and document!)
51. Principle 2
Use the right tool
for the job
“Tools #2” by Juan Pablo Olmo. No alterations other than cropping.
https://www.flickr.com/photos/juanpol/1562101472/
Image used with permissions under Creative Commons license 2.0, Attribution
Generic License (https://creativecommons.org/licenses/by/2.0/)
52. public API public API
DynamoDB
Micro-service A Micro-service B
Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
53. public API public API
DynamoDB
Micro-service A Micro-service B
Amazon
Elasticsearc
Service
Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
54. public API public API
RDS
MySQL
Micro-service A Micro-service B
Amazon
Elasticsearc
Service
Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
55. public API public API
RDS
MySQL
Micro-service A Micro-service B
Amazon
Elasticsearc
Service
Principle 2: Use the right tool for the job
(Embrace polyglot programming frameworks)
56. public API public API
RDS
Aurora
Micro-service A Micro-service B
Amazon
Elasticsearc
Service
Principle 2: Use the right tool for the job
(Embrace polyglot programming frameworks)
69. • Prototype in less than 2 months
• Deployment time: hours
minutes
• Each team can now develop its
respective applications
independently
Coursera
13 million users from 190 countries
1,000 courses from 119 institutions
78. Lambda
automatically
scales
Upload your code
(Java, JavaScript,
Python)
Pay for only the
compute time
you use
(sub-second
metering)
Set up your code to
trigger from other AWS
services, webservice
calls, or app activity
81. Create a unified
API frontend for
multiple
micro-services
Authenticate and
authorize requests
82. Create a unified
API frontend for
multiple
micro-services
Authenticate and
authorize requests
Handles DDoS
protection and API
throttling
83. Create a unified
API frontend for
multiple
micro-services
…as well as
monitoring, logging,
rollbacks,
client SDK
generation…
Authenticate and
authorize requests
Handles DDoS
protection and API
throttling
90. Highly Scalable
• Inherently scalable
Secure
• API Gateway acts as “front door”
• Can add authN/authZ; or throttle API if needed
• S3 bucket policies
• IAM Roles for Lambda invocations
Cost-efficient
• Only pay for actual micro-service usage
93. Principle 3
Secure Your
Services
“security” by Dave Bleasdale. No alterations other than cropping.
https://www.flickr.com/photos/sidelong/3878741556/
Image used with permissions under Creative Commons license 2.0,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
94. 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
95. Principle 4
Be a good citizen
within the
ecosystem
“Lamington National Park, rainforest” by Jussarian. No alterations other than
cropping.
https://www.flickr.com/photos/kerr_at_large/87771074/
Image used with permissions under Creative Commons license 2.0,
96. 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
97. 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
98. …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. Zipkin, OpenTracing, Wingtips
Principle 4: Be a good citizen within the ecosystem
99. Principle 5
More than just
technology
transformation
“rowing on the river in Bedford” by Matthew Hunt. No alterations other than cropping.
https://www.flickr.com/photos/mattphotos/19189529/
Image used with permissions under Creative Commons license 2.0,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
100. “Any organization that designs a system
will inevitably produce a design whose
structure is a copy of the organization’s
communication structure.”
Melvin E. Conway, 1967
Conway’s Law
101. Decentralize governance and data management
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
102. Decentralize governance and data management
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
103. Silo’d functional teams silo’d application architectures
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
104. Silo’d functional teams silo’d application architectures
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
105. Cross functional teams self-contained services
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
106. Cross functional teams self-contained services
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
107. Cross functional teams self-contained services
(“Two-pizza teams” at Amazon)
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
108. Full ownership
Full accountability
Aligned incentives
“DevOps”
Cross functional teams self-contained services
(“Two-pizza teams” at Amazon)
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
109. Principle 6
Automate Everything
“Robot” by Robin Zebrowski. No alterations other than cropping.
https://www.flickr.com/photos/firepile/438134733/
Image used with permissions under Creative Commons license 2.0,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
116. Principle 6: Automate everything
AWS
CodeCommit
AWS
CodePipeline
AWS
CodeDeploy
EC2 ELB
Auto
ScalingLambdaECS
DynamoDBRDS ElastiCache SQS SWF
SES SNS
API GatewayCloudWatch Cloud Trail
KinesisElastic
Beanstalk
117. It’s a journey…
Expect challenges along the way…
• Understanding of business domains
• Coordinating transactions across
multiple services
• Eventual Consistency
• Service discovery
• Lots of moving parts requires
increased coordination
• Complexity of testing / deploying /
operating a distributed system
• Cultural transformation
118. Principles of Microservices
1. Rely only on the public API
Hide your data
Document your APIs
Define a versioning strategy
2. Use the right tool for the job
Polygot persistence (data layer)
Polyglot frameworks (app layer)
3. Secure your services
Defense-in-depth
Authentication/authorization
6. Automate everything
Adopt DevOps
4. Be a good citizen within the ecosystem
Have SLAs
Distributed monitoring, logging, tracing
5. More than just technology transformation
Embrace organizational change
Favor small focused dev teams
119. Benefits of microservices
Rapid
Build/Test/Release
Cycles
Clear ownership and
accountability
Easier to scale
each individual
micro-service
New releases
take minutes
Short time to add
new features
Easier to maintain
and evolve
Increase innovation
Delighted customers
Increased agility
120. Benefits of microservices
Rapid
Build/Test/Release
Cycles
Clear ownership and
accountability
Easier to scale
each individual
micro-service
New releases
take minutes
Short time to add
new features
Easier to
maintain and
evolve system
Faster innovation
Delighted customers
Increased agility
121. Benefits of microservices
Rapid
Build/Test/Release
Cycles
Clear ownership and
accountability
Easier to scale
each individual
micro-service
New releases
take minutes
Short time to add
new features
Easier to
maintain and
evolve system
Faster innovation
Delighted customers
Increased agility
122. Additional AWS resources:
• Zombie Microservices Workshop:
https://github.com/awslabs/aws-lambda-zombie-workshop
• Serverless Webapp - Reference Architecture:
https://github.com/awslabs/lambda-refarch-webapp
• Microservices with ECS:
https://aws.amazon.com/blogs/compute/using-amazon-
api-gateway-with-microservices-deployed-on-amazon-ecs/
• Serverless Service Discovery:
https://aws.amazon.com/blogs/developer/
serverless-service-discovery-part-1-get-started/
• ECS Service Discovery:
https://aws.amazon.com/blogs/compute/
service-discovery-an-amazon-ecs-reference-architecture/
• Microservices without the Servers
https://aws.amazon.com/blogs/compute/
microservices-without-the-servers
Popular open-source tools:
• Serverless – http://serverless.com
• Apex - http://apex.run/
https://aws.amazon.com/devops/
Additional resources