Microservices are an architectural approach to decompose complex applications into smaller, independent services. AWS customers benefit from increased agility, simplified scalability, resiliency, and faster deployments by migrating from monoliths to microservices based architecture. In this session, we will provide an overview of the benefits and challenges of microservices, and share best practices for architecting and deploying microservices on AWS. We will dive into different approaches you can take to run microservices applications at scale and explore how services like Amazon ECS, AWS Lambda, and AWS X-Ray make it simpler to design and maintain these applications. Learning Objectives: 1. Understand the fundamentals of the microservices architectural approach 2. Learn best practices for designing microservices on AWS 3. Learn the basics of Amazon EC2 Container Service, AWS Lambda, and AWS X-Ray

1. An overview of designing
microservices based applications on
AWS
Peter Dalbhanjan, Solutions Architect, AWS

2. Evolution from Monoliths to Microservices
Approaches for Building Microservices Applications on AWS
Core Principles of Microservices
Demo

3. Account Support
Support
Managed
Services
Professional
Services
Partner
Ecosystem
Training &
Certification
Solution
Architects
Account
Management
Security &
Pricing Reports
Technical Acct.
Management
Marketplace
Business
Applications
DevOps Tools
Business
Intelligence
Security
Networking
Database &
Storage
SaaS
Subscriptions
Operating
Systems
Mobile
Build, Test,
Monitor Apps
Push
Notifications
Build, Deploy,
Manage APIs
Device Testing
Identity
Enterprise
Applications
Document
Sharing
Email &
Calendaring
Hosted
Desktops
Application
Streaming
Backup
Game
Development
3D Game
Engine
Multi-player
Backends
Mgmt. Tools
Monitoring
Auditing
Service Catalog
Server
Management
Configuration
Tracking
Optimization
Resource
Templates
Automation
Analytics
Query Large
Data Sets
Elasticsearch
Business
Analytics
Hadoop/Spark
Real-time Data
Streaming
Orchestration
Workflows
Managed
Search
Managed ETL
Artificial
Intelligence
Voice & Text
Chatbots
Machine
Learning
Text-to-Speech
Image Analysis
IoT
Rules Engine
Local Compute
and Sync
Device
Shadows
Device
Gateway
Registry
Hybrid
Devices & Edge
Systems
Data
Integration
Integrated
Networking
Resource
Management
VMware on
AWS
Identity
Federation
Migration
Application
Discovery
Application
Migration
Database
Migration
Server
Migration
Data Migration
Infrastructure Regions
Availability
Zones
Points of
Presence
Compute Containers
Event-driven
Computing
Virtual
Machines
Simple Servers Auto Scaling Batch
Web
Applications
Storage Object Storage Archive Block Storage
Managed File
Storage
Exabyte-scale
Data Transport
Database MariaDB
Data
Warehousing
NoSQLAurora MySQL Oracle SQL ServerPostgreSQL
Application
Services
Transcoding Step Functions Messaging
Security
Certificate
Management
Web App.
Firewall
Identity &
Access
Key Storage &
Management
DDoS
Protection
Application
Analysis
Active
Directory
Dev Tools
Private Git
Repositories
Continuous
Delivery
Build, Test, and
Debug
Deployment
Networking
Isolated
Resources
Dedicated
Connections
Load Balancing Scalable DNSGlobal CDN
The AWS
Platform

4. * As of 1 March 2017
2010
61
1,017
159
2012 2014 2016
516

5. “The Monolith”

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

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

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

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

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

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

14. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (VP, Cloud Architecture Strategy at AWS)

15. Services communicate with
each other over the
network
“service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (VP, Cloud Architecture Strategy at AWS)

16. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (VP, Cloud Architecture Strategy at AWS)
You can update the services
independently; updating
one service doesn’t require
changing any other services.

17. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (VP, Cloud Architecture Strategy at AWS)
Self-contained; you can
update the code without
knowing anything about the
internals of other
microservices

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

19. “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”

20. Anatomy of a Micro-service

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

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

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

24. Avoid Software Coupling

25. Drivers
micro-service
Payments
micro-service Location
micro-service
Ordering
micro-service
Restaurant
micro-service
Ecosystem of microservices

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

31. Drivers
micro-service
Payments
micro-service Location
micro-service
Ordering
micro-service
Restaurant
micro-service
Typical microservices application

32. Micro-service Design
Approach #1
EC2

33. Micro-service Design
EC2

34. Micro-service Design
EC2

35. Micro-service Design
EC2EC2 EC2 EC2

36. Micro-service Design
EC2EC2 EC2 EC2
Elastic Load
Balancer

37. Micro-service Design
EC2EC2 EC2 EC2
Elastic Load
Balancer
AWS Elastic
Beanstalk

38. Elastic Beanstalk vs. DIY
Your code
HTTP server
Application server
Language interpreter
Operating system
Host
Elastic Beanstalk configures each
EC2 instance in your environment
with the components necessary to
run applications for the selected
platform. No more worrying about
logging into instances to install and
configure your application stack.
Focus on building your application
Provided by you
Provided and managed by Elastic Beanstalk
On-instance configuration

39. Micro-service Design
Approach #2
Containers
Using ECS

40. Amazon
EC2 Container Service (ECS)
is the cluster management system to
run your Docker containers

41. Cluster Management Made Easy
• Nothing to run
• Complete state
• Control and monitoring
• Scale
Use Amazon EC2 Container Service for container workloads
Amazon
EC2 Container
Service (ECS)

42. Flexible Scheduling
• Applications
• Batch jobs
• Multiple schedulers
Use Amazon EC2 Container Service for container workloads
Amazon
EC2 Container
Service (ECS)

43. Designed for Use with Other AWS Services
• Elastic Load Balancing
• Amazon Elastic Block Store
• Amazon Virtual Private Cloud
• AWS Identity and Access Management
• AWS CloudTrail
Use Amazon EC2 Container Service for container workloads
Amazon
EC2 Container
Service (ECS)

44. Micro-service Design
EC2EC2 EC2 EC2
Elastic Load
Balancer

45. Micro-service Design
EC2EC2 EC2 EC2
Elastic Load
Balancer

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

47. Micro-service Design
Approach #3
API Gateway
+ Lambda

48. AWS Lambda
lets you run code
without managing servers

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

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

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

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

53. Micro-service A Micro-service B
public API public API
Principle 1: Microservices only rely on each other’s public API
DynamoDB

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

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

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

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

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

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

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

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

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

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

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

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

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

67. Principle 3: Secure Your Services
• Defense-in-depth
• Network level (e.g. VPC, Security Groups, TLS)
• Server/container-level
• App-level
• IAM policies
• IAM roles on ECS tasks
• CloudTrail logs
• Authentication & Authorization
• Client-to-service, as well as service-to-service
• IAM-based Authentication
• Secrets management
• Parameter Store
• S3 bucket policies + KMS + IAM
• Open-source tools (e.g. Vault, Keywhiz)
Amazon
EC2 Container
Service (ECS)

68. 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
• Stage-level and Method-level throttling
• Authentication & Authorization
• Client-to-service, as well as service-to-service
• AWS Cognito: user pools, federated identities
• 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

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

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

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

72. …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. service dependency, request/response time
Distributed tracing
• AWS X-Ray
• 3rd party: Zipkin, OpenTracing
User-experience metrics
• Status codes, latency, error counts, time to first byte
Principle 4: Be a good citizen within the ecosystem
(Distributed monitoring, logging and tracing)

73. AWS X-Ray
Distributed tracing service that
enables developers to analyze the
behavior of their applications

74. AWS X-Ray
traces requests
made to your
application
X-Ray service
X-Ray combines
the data
gathered from
each service
into singular
units called
traces
View the service
map to see
trace data such
as latencies,
HTTP statuses,
and metadata
for each service
Drill into the
service showing
unusual
behavior to
identify the root
issue
X-Ray collects data
about the request
from each of the
underlying
applications services
it passes through

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

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

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

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

79. 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)

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

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

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

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

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

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

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

87. Principle 6: Automate everything
AWS CodeCommit AWS CodePipeline AWS CodeDeploy
ELB
Auto
ScalingEC2 Lambda
ECS
DynamoDBRDS ElastiCache
SQS SWF SESSNS
API GatewayCloudWatch Cloud Trail
Kinesis
Elastic
Beanstalk

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

89. 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
Ÿ Container journey? (use ECS)
Ÿ Polyglot 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

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

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

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

93. Additional AWS resources:
• Microservices on AWS whitepaper:
https://d0.awsstatic.com/whitepapers/microservices-on-
aws.pdf
• 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/
• 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

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