1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Architecting Modern Applications on AWS:
VMs, Containers, Microservices, Lambda
and More
2016-11-04
Mackenzie Kosut
@mkosut
AWS Startup Evangelist
Tara E. Walker
@taraw
AWS Technical Evangelist

2. 15 min Evolution from Monoliths to Microservices
15 min
Core Principles of Microservices Approaches to building Microservices on
AWS
15 min Other Architectural Principles
5 min Additional Resources
Architecting Modern Applications on AWS: VMs,
Containers, Microservices, Lambda and More

3. 2006 EC2 & S3
2016 70+ Managed Services
Kinesis Streaming Analytics, Mobile Testing, Redshift
Datawarehouse, Code Deploy/Build Tools, Elastic
Container Service, Application Load Balancer, Lambda, API
Gateway, DynamoDB, Elastic Map Reduce
(Hadoop/Spark/Presto/etc), Elastic Beanstalk, Elastic
Transcoder, RDS, Elasticsearch, more..

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

5. 2009
48
280
722
82
2011 2013 2015
706
September
2016

6. Migrating from Monolith to
Microservice

7. “The Monolith”

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

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

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

12. Too much software coupling

13. Too much software coupling
Shared libraries

14. Too much software coupling
Shared libraries
Shared data

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

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

19. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (VP of Cloud Architecture @ AWS,
former Cloud Architect at Netflix)

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

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

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

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

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

25. Anatomy of a Microservice

26. Anatomy of a Microservice

27. Data Store
(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)
Anatomy of a Microservice

28. Application/Logic
(code, libraries, etc)
Anatomy of a Microservice
Data Store
(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)

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

30. Avoid Software Coupling

31. Drivers
microservices
Payments
microservice Location
microservices
Ordering
microservices
Restaurant
microservice
Ecosystem of Microservices

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

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

36. ... Sale every day at noon EST

38. Microservices Architecture on
Amazon Web Services

39. Application Services
API Gateway
Build, Publish and Manage APIs
 Performance at any scale via worldwide edge locations, traffic
throttling, and API output caching
 Monitor API activity
 Integrates with Lambda functions
 Run multiple versions of the same API
 Fully Managed

40. Elastic Compute Cloud (EC2)
Virtual Servers in the Cloud
 Resizable Compute Capacity
 Complete control of your computing resources
 Reduces time to obtain and boot new server
instances to minutes
 Choose from 30+ different instance types
 Scale as your requirements change
 Pay only for what you use
Compute

41. EC2 Container Service
Run and Manage Docker Containers
 A high performance container management service for
running Docker containers on EC2 instances
 Use the built in scheduler, write your own, or use a
third-party scheduler
 Integrates with other services like ELB and EBS
 No additional charge
 EC2 Container Registry
Compute

42. Lambda
Run Code in Response to Events
 Runs code in response to triggers such as S3 upload,
DynamoDB updates, Kinesis streams, and API
Gateway requests
 Automatically scales
 You only need to provide the code; there is no
infrastructure to manage
 Pay only for what you use
Compute

43. DynamoDB
Predictable and Scalable NoSQL Data Store
 Fast, fully-managed NoSQL Database Service
 Capable of handling any amount of data
 Durable and Highly Available
 All SSD storage
 Simple and Cost Effective
Database

44. Microservices Architecture
Internet
Mobile Apps
Websites
Services
AWS Lambda
functions
AWS
API Gateway
Cache
Endpoints on
Amazon EC2 /ECS
Amazon Elastic
Beanstalk
Any other publicly
accessible endpoint
Amazon
CloudWatch
Monitoring
Amazon
API Gateway

45. Principle 1
Microservices 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/)

46. Microservice A Microservice B
public API public API
Principle 1: Microservices only rely on each other’s public API

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

48. public API public API
Nope!
Principle 1: Microservices only rely on each other’s public API
(Hide Your Data)
Microservice A Microservice B

49. public API public API
Principle 1: Microservices only rely on each other’s public API
(Hide Your Data)
Microservice A Microservice B

50. 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
public API
Microservice A

51. Principle 1: Microservices only rely on each other’s public API
(Evolve API in backward-compatible way…and document!)
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

52. Principle 1: Microservices only rely on each other’s public API
(Evolve API in backward-compatible way…and document!)
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

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

54. public API public API
Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
DynamoDB
Microservice A Microservice B

55. public API public API
Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
DynamoDB
Microservice A Microservice B
Amazon
Elasticsearch
Service

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

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

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

59. Today’s Workshop
This hands-on workshop will demonstrate the basics of building serverless
applications and microservices on AWS using AWS Lambda, Amazon
DynamoDB, Amazon API Gateway, and more.
Building Serverless Microservices on AWS
1:45PM – 2:45PM

61. DynamoDB
Lambda
to retrieve
restaurants
Restaurant microservice
API Gateway
POST GET
Lambda
to store
restaurants

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

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

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

65. Hey Sally, we need to
call your microservice
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.
Microservice A Microservice B
public API public API
Principle 4: Be a good citizen within the ecosystem

66. Principle 4: Be a good citizen within the ecosystem
(Have clear SLAs)
Restaurant
microservice
15 TPS100 TPS5 TPS20 TPS
Before we let you call
our microservice we
need to understand your
use case, expected load
(TPS) and accepted
latency

67. …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)

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

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

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

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

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

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

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

75. Full ownership
Full accountability
Aligned incentives
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)

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

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

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

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

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

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

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

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

84. Summary

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

86. 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
 Polyglot persistence (data layer)
 Polyglot frameworks (app layer)
3. Secure your services
 Defense-in-depth
 Authentication/authorization
6. Automate everything
 Adopt an Automation Strategy
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

87. Benefits of Microservices
Rapid
Build/Test/Release
Cycles
Clear ownership and
accountability
Easier to scale
each individual
microservice
New releases
take minutes
Short time to add
new features
Easier to
maintain and
evolve
Increase innovation
Delighted customers
Increased agility

88. Benefits of Microservices
Rapid
Build/Test/Release
Cycles
Clear ownership and
accountability
Easier to scale
each individual
microservice
New releases
take minutes
Short time to add
new features
Easier to
maintain and
evolve system
Faster innovation
Delighted customers
Increased agility

89. Benefits of Microservices
Rapid
Build/Test/Release
Cycles
Clear ownership and
accountability
Easier to scale
each individual
microservice
New releases
take minutes
Short time to add
new features
Easier to
maintain and
evolve system
Faster innovation
Delighted customers
Increased agility

90. AWS resources:
• Microservices without the Servers
https://aws.amazon.com/blogs/compute/
microservices-without-the-servers
• 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/
• Serverless Webapp - Reference Architecture:
https://github.com/awslabs/lambda-refarch-webapp
• Zombie Microservices Workshop:
https://github.com/awslabs/aws-lambda-zombie-
workshop
Popular open-source tools:
• Serverless – http://serverless.com
• Apex - http://apex.run/
https://aws.amazon.com/devops/
Additional Resources

91. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Thank you!
Mackenzie Kosut
@mkosut
Tara E. Walker
@taraw