This document provides an introduction to microservices. It begins by outlining the challenges of monolithic architecture such as long build/release cycles and difficulty scaling. It then introduces microservices as a way to decompose monolithic applications into independently deployable services. Key benefits of microservices include improved agility, scalability, and innovation. The document discusses microservice design principles like communicating over APIs, using the right tools for each service, securing services, and being a good citizen in the ecosystem. It provides examples of how to implement a restaurant microservice using AWS services like API Gateway, Lambda, DynamoDB and containers.

1. Introduction to Microservices
Peter Dalbhanjan, Solutions Architect, AWS

8. ENTERPRISE
APPS
DEVELOPMENT & OPERATIONSMOBILE SERVICESAPP SERVICESANALYTICS
Data
Warehousing
Hadoop/
Spark
Streaming Data
Collection
Machine
Learning
Elastic
Search
Virtual
Desktops
Sharing &
Collaboration
Corporate
Email
Backup
Queuing &
Notifications
Workflow
Search
Email
Transcoding
One-click App
Deployment
Identity
Sync
Single Integrated
Console
Push
Notifications
DevOps Resource
Management
Application Lifecycle
Management
Containers
Triggers
Resource
Templates
TECHNICAL &
BUSINESS
SUPPORT
Account
Management
Support
Professional
Services
Training &
Certification
Security &
Pricing
Reports
Partner
Ecosystem
Solutions
Architects
MARKETPLACE
Business
Apps
Business
Intelligence
Databases
DevOps
Tools
NetworkingSecurity Storage
Regions
Availability
Zones
Points of
Presence
INFRASTRUCTURE
CORE SERVICES
Compute
VMs, Auto-scaling, &
Load Balancing
Storage
Object, Blocks, Archival,
Import/Export
Databases
Relational, NoSQL,
Caching, Migration
Networking
VPC, DX, DNS
CDN
Access
Control
Identity
Management
Key
Management &
Storage
Monitoring
& Logs
Assessment
and reporting
Resource &
Usage Auditing
SECURITY & COMPLIANCE
Configuration
Compliance
Web application
firewall
HYBRID
ARCHITECTURE
Data Backups
Integrated
App
Deployments
Direct
Connect
Identity
Federation
Integrated
Resource
Management
Integrated
Networking
API
Gateway
IoT
Rules
Engine
Device
Shadows
Device SDKs
Registry
Device
Gateway
Streaming Data
Analysis
Business
Intelligence
Mobile
Analytics

9. * As of 1 Feb 2016
2009
48
280
722
82
2011 2013 2015

10. “The Monolith”

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/)

15. Monolith development lifecycle
releasetestbuild
delivery pipeline
app
(aka the“monolith”)developers
Photo by Sage Ross. No alterations other than cropping. https://www.flickr.com/photos/ragesoss/2931770125/
Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

16. Too much software coupling

17. Too much software coupling
Shared libraries

18. Too much software coupling
Shared libraries
Shared data

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/)

20. “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/)

23. “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)

24. Services communicate with
each other over the
network
“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)

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”

29. Anatomy of a Micro-service

30. Data Store
(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)
Anatomy of a Micro-service

31. Application/Logic
(code, libraries, etc)
Anatomy of a Micro-service
Data Store
(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)

32. Application/Logic
(code, libraries, etc)
Anatomy of a Micro-service
Data Store
(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)
Public API
POST /restaurants
GET /restaurants

33. Avoid Software Coupling

34. Drivers
micro-services
Payments
micro-service Location
micro-services
Ordering
micro-services
Restaurant
micro-service
Ecosystem of micro-services

38. = 50 million deployments a year
Thousands of teams
× Microservice architecture
× Continuous delivery
× Multiple environments
(5708 per hour, or every 0.63 second)

39. Gilt: Luxury designer brands at members-only prices

40. ... Sale every day at noon EST

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. Micro-service A Micro-service B
public API public API
Principle 1: Microservices only rely on each other’s public API
DynamoDB

45. Micro-service A Micro-service B
public API public API
Principle 1: Microservices only rely on each other’s public API
(Hide Your Data)
DynamoDB

46. Micro-service A Micro-service B
public API public API
Principle 1: Microservices only rely on each other’s public API
(Hide Your Data)
Nope!
DynamoDB

47. Micro-service A Micro-service B
public API public API
Principle 1: Microservices only rely on each other’s public API
(Hide Your Data)
DynamoDB

48. Micro-service A
public API
Principle 1: Microservices only rely on each other’s public API
(Evolve API in backward-compatible way…and
document!)
storeRestaurant (id, name, cuisine)
Version 1.0.0

49. Micro-service A
public API
Principle 1: Microservices only rely on each other’s public API
(Evolve API in backward-compatible way…and
document!)
storeRestaurant (id, name, cuisine)
Version 1.0.0
storeRestaurant (id, name, cuisine)
storeRestaurant (id, name,
arbitrary_metadata)
addReview (restaurantId, rating, comments)
Version 1.1.0

50. Micro-service A
public API
Principle 1: Microservices only rely on each other’s public API
(Evolve API in backward-compatible way…and
document!)
storeRestaurant (id, name, cuisine)
Version 1.0.0
storeRestaurant (id, name, cuisine)
storeRestaurant (id, name,
arbitrary_metadata)
addReview (restaurantId, rating, comments)
Version 1.1.0
storeRestaurant (id, name,
arbitrary_metadata)
addReview (restaurantId, rating, comments)
Version 2.0.0

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. Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
Micro-service A Micro-service B
public API public API
DynamoDB

53. Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
Micro-service A Micro-service B
public API public API
DynamoDB
Amazon
Elasticsearch
Service

54. Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
Micro-service A Micro-service B
public API public API
Amazon
Elasticsearch
Service
RDS
Aurora

55. Principle 2: Use the right tool for the job
(Embrace polyglot programming frameworks)
Micro-service A Micro-service B
public API public API
Amazon
Elasticsearch
Service
RDS
Aurora

56. Principle 2: Use the right tool for the job
(Embrace polyglot programming frameworks)
Micro-service A Micro-service B
public API public API
Amazon
Elasticsearch
Service
RDS
Aurora

57. Let’s build
a microservice!

59. Restaurant Micro-service
GET /restaurants
POST /restaurants

60. Restaurant Micro-service
Approach #1
EC2

61. Restaurant Micro-service
EC2

62. Restaurant Micro-service
EC2

63. Restaurant Micro-service
EC2EC2 EC2 EC2

64. Restaurant Micro-service
EC2EC2 EC2 EC2
Elastic Load
Balancer

65. Restaurant Micro-service
Approach #2
Containers
Using ECS

66. Restaurant Micro-service
EC2EC2 EC2 EC2
Elastic Load
Balancer

67. Restaurant Micro-service
EC2EC2 EC2 EC2
Elastic Load
Balancer

68. Restaurant Micro-service
EC2EC2 EC2 EC2
Elastic Load
Balancer
Amazon
EC2 Container
Service (ECS)
to manage
containers

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

70. Restaurant Micro-service
Approach #3
API Gateway
+ Lambda

71. DynamoDB
Restaurant Micro-service

72. DynamoDB
Lambda
Restaurant Micro-service

73. DynamoDB
Lambda
Restaurant Micro-service
API Gateway

74. AWS Lambda
lets you run code
without managing servers

75. Upload your code
(Java, JavaScript,
Python)

76. Upload your code
(Java, JavaScript,
Python)
Set up your code to
trigger from other AWS
services, webservice
calls, or app activity

77. Lambda
automatically
scales
Upload your code
(Java, JavaScript,
Python)
Set up your code to
trigger from other AWS
services, webservice
calls, or app activity

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

79. AWS API Gateway
is the easiest way to
deploy micro-services

80. Create a unified
API frontend for
multiple
micro-services

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

85. Restaurant Microservice

86. DynamoDB
Restaurant Microservice

87. DynamoDB
Lambda
to retrieve
restaurants
Restaurant Microservice
Lambda
to store
restaurants

88. DynamoDB
Lambda
to retrieve
restaurants
Restaurant Microservice
API Gateway
POST GET
Lambda
to store
restaurants

89. DynamoDB
Lambda
to retrieve
restaurants
Restaurant Microservice
API Gateway
POST GET
Web UI
Lambda
to store
restaurants

91. DynamoDB
Lambda
to retrieve
restaurants
Restaurant Microservice
API Gateway
POST GET
Web UI
Lambda
to store
restaurants

92. 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 microservice usage

93. Micro-service A Micro-service B
public API public API
DynamoDB
From a few…

94. Drivers
micro-services
Payments
micro-service Location
micro-services
Ordering
micro-services
Restaurant
micro-service
…to an ecosystem

95. 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/)

96. 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

97. 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,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

98. 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

99. Principle 4: Be a good citizen within the ecosystem
(Have clear SLAs)
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

100. …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
Distributed tracing
• e.g. Zipkin, OpenTracing
User-experience metrics
Principle 4: Be a good citizen within the ecosystem
(Distributed monitoring, logging and tracing)

101. 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/)

102. “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

103. 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

104. 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

105. 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

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
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. Non-pizza 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
Cross functional teams  self-contained services
(“Two-pizza teams” at Amazon)

109. Full ownership
Full accountability
Aligned incentives
“DevOps”
Non-pizza 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
Cross functional teams  self-contained services
(“Two-pizza teams” at Amazon)

110. 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/)

111. releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service

112. releasetestbuild
releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service

113. releasetestbuild
releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service
releasetestbuild

114. releasetestbuild
releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service
releasetestbuild
releasetestbuild

115. releasetestbuild
releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service
releasetestbuild
releasetestbuild
releasetestbuild

116. releasetestbuild
releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild

117. 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

118. It’s a journey…
Expect challenges along the way…
• Understanding of business domains
• Coordinating txns across multiple services
• Eventual Consistency
• Service discovery
• Lots of moving parts requires increased
coordination
• Complexity of testing / deploying /
operating a distributed system
• Cultural transformation

119. 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

120. Benefits of microservices
Rapid
Build/Test/Release
Cycles
Clear ownership and
accountability
Easier to scale
each
individual
micro-service

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

122. 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

123. 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

124. Thank you!
Peter Dalbhanjan
dalbhanj@amazon.com