enterprise summit – architecting microservices on aws final v2
TRANSCRIPT
© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Level 200 (Introductory)
Pierre Steckmeyer, AWS Solutions ArchitectSeptember 28th, 2016
Architecting Microservices on AWSDivide and conquer for agility and scalability:
ENTERPRISE APPS
DEVELOPMENT & OPERATIONSMOBILE SERVICESAPP SERVICESANALYTICS
DataWarehousing
Hadoop/Spark
Streaming Data Collection
Machine Learning
Elastic Search
Virtual Desktops
Sharing & Collaboration
Corporate Email
Backup
Queuing & Notifications
Workflow
Search
Transcoding
One-click App Deployment
Identity
Sync
Single Integrated Console
PushNotifications
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
DatabasesDevOps Tools
NetworkingSecurity Storage
RegionsAvailability Zones
Points of Presence
INFRASTRUCTURE
CORE SERVICES
ComputeVMs, Auto-scaling, & Load Balancing
StorageObject, Blocks, Archival, Import/Export
DatabasesRelational, NoSQL, Caching, Migration
NetworkingVPC, 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
HYBRIDARCHITECTURE
Data Backups
Integrated App Deployments
DirectConnect
IdentityFederation
IntegratedResource Management
Integrated Networking
API Gateway
IoT
Rules Engine
Device Shadows
Device SDKs
Registry
Device Gateway
Streaming Data Analysis
Business Intelligence
MobileAnalytics
* As of 1 Feb 2016
2009
48
280
722
82
2011 2013 2015
“The Monolith”
Challenges with monolithic software
Long Build/Test/Release Cycles(who broke the build?)
Operationsis a nightmare(module X is failing, who’s the owner?)
Difficult to scale
New releasestake months
Long time to addnew features
Architecture is hard to maintain and evolve
Lack of innovation
Frustrated customers
Lack of agility
Challenges with monolithic software
Long Build/Test/Release Cycles(who broke the build?)
Operationsis a nightmare(module X is failing, who’s the owner?)
Difficult to scale
New releasestake months
Long time to addnew features
Architecture is hard to maintain and evolve
Lack of innovation
Frustrated customers
Lack of agility
Challenges with monolithic software
Long Build/Test/Release Cycles(who broke the build?)
Operationsis a nightmare(module X is failing, who’s the owner?)
Difficult to scale
New releasestake months
Long time to addnew features
Architecture is hard to maintain and evolve
Lack of innovation
Frustrated customers
Lack of agility
“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/)
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/)
Too much software coupling
Too much software coupling
Shared libraries
Too much software coupling
Shared libraries
Shared data
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/)
“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/)
“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)
“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)
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)
You can update the services independently; updating one service doesn’t require changing any other services.
“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
“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/)
“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”
Anatomy of a Microservice
Data Store(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)
Anatomy of a Microservice
Application/Logic(code, libraries, etc)
Anatomy of a Microservice
Data Store(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)
Public API
POST /restaurantsGET /restaurants
Application/Logic(code, libraries, etc)
Anatomy of a Microservice
Data Store(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)
Avoid Software Coupling
Driversmicroservices
Paymentsmicroservice Location
microservices
Orderingmicroservices
Restaurantmicroservice
Ecosystem of microservices
= 50 million deployments a year
Thousands of teams
× Microservice architecture
× Continuous delivery
× Multiple environments
(5708 per hour, or every 0.63 second)
Gilt: Luxury designer brands at members-only prices
... Sale every day at noon EST
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/)
Microservice A Microservice B
public API public API
Principle 1: Microservices only rely on each other’s public API
public API public API
Principle 1: Microservices only rely on each other’s public API(Hide Your Data)
Microservice A Microservice B
public API public API
Nope!
Principle 1: Microservices only rely on each other’s public API(Hide Your Data)
Microservice A Microservice B
public API public API
Principle 1: Microservices only rely on each other’s public API(Hide Your Data)
Microservice A Microservice B
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
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
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
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/)
public API public API
Principle 2: Use the right tool for the job(Embrace polyglot persistence)
DynamoDB
Microservice A Microservice B
public API public API
Principle 2: Use the right tool for the job(Embrace polyglot persistence)
DynamoDB
Microservice A Microservice B
AmazonElasticsearchService
public API public API
Principle 2: Use the right tool for the job(Embrace polyglot persistence)
RDSAurora
Microservice A Microservice B
AmazonElasticsearchService
public API public API
Principle 2: Use the right tool for the job(Embrace polyglot programming frameworks)
RDSAurora
Microservice A Microservice B
AmazonElasticsearchService
public API public API
Principle 2: Use the right tool for the job(Embrace polyglot programming frameworks)
RDSAurora
Microservice A Microservice B
AmazonElasticsearchService
Let’s builda microservice!
Restaurant Microservice
GET /restaurants
POST /restaurants
Restaurant Microservice
Approach #1
EC2
Restaurant Microservice
EC2
Restaurant Microservice
EC2
Restaurant Microservice
EC2EC2 EC2 EC2
Restaurant Microservice
EC2EC2 EC2 EC2
Elastic Load Balancer
Restaurant Microservice
Approach #2
ContainersUsing ECS
Restaurant Microservice
EC2EC2 EC2 EC2
Elastic Load Balancer
Restaurant Microservice
EC2EC2 EC2 EC2
Elastic Load Balancer
Restaurant Microservice
EC2EC2 EC2 EC2
Elastic Load Balancer
AmazonEC2 ContainerService (ECS)
to managecontainers
• Prototype in less than 2 months
• Deployment time: hours minutes
• Each team can now develop itsrespective applications independently
Coursera13 million users from 190 countries1,000 courses from 119 institutions
Restaurant Microservice
Approach #3
API Gateway+ Lambda
DynamoDB
Restaurant Microservice
DynamoDB
Lambda
Restaurant Microservice
DynamoDB
Lambda
Restaurant Microservice
API Gateway
AWS Lambda
lets you run code
without managing servers
Upload your code(Java, JavaScript,
Python)
Upload your code(Java, JavaScript,
Python)
Set up your code to trigger from other AWS
services, webservicecalls, or app activity
Lambda automatically
scales
Upload your code(Java, JavaScript,
Python)
Set up your code to trigger from other AWS
services, webservicecalls, or app activity
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, webservicecalls, or app activity
AWS API Gateway
is the easiest way to deploy microservices
Create a unified API frontend for
multiplemicroservices
Create a unified API frontend for
multiplemicroservices
Authenticate and authorize requests
Create a unified API frontend for
multiplemicroservices
Authenticate and authorize requests
Handles DDoSprotection and API throttling
Create a unified API frontend for
multiplemicroservices
…as well as monitoring,
logging, rollbacks,
client SDK generation…
Authenticate and authorize requests
Handles DDoSprotection and API throttling
Restaurant Microservice
DynamoDB
Restaurant Microservice
DynamoDB
Lambdato retrieverestaurants
Restaurant Microservice
Lambdato store
restaurants
DynamoDB
Lambdato retrieverestaurants
Restaurant Microservice
API Gateway
POST GET
Lambdato store
restaurants
DynamoDB
Lambdato retrieverestaurants
Restaurant Microservice
API Gateway
POST GET
Web UI
Lambdato store
restaurants
DynamoDB
Lambdato retrieverestaurants
Restaurant Microservice
API Gateway
POST GET
Web UI
Lambdato store
restaurants
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
Microservice A Microservice B
public API public API
From a few…
Driversmicroservices
Paymentsmicroservice Location
microservices
Orderingmicroservices
Restaurantmicroservice
…to an ecosystem
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/)
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
Principle 4
Be a good citizenwithin 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/)
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
Principle 4: Be a good citizen within the ecosystem(Have clear SLAs)
RestaurantMicroservice
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
…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)
Principle 5
More than justtechnology 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/)
“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’scommunication structure.”
Melvin E. Conway, 1967
Conway’s Law
Decentralize governance and data management
Image from Martin Fowler’s article on microservices, athttp://martinfowler.com/articles/microservices.html
No alterations other than cropping.Permission to reproduce: http://martinfowler.com/faq.html
Decentralize governance and data management
Image from Martin Fowler’s article on microservices, athttp://martinfowler.com/articles/microservices.html
No alterations other than cropping.Permission to reproduce: http://martinfowler.com/faq.html
Silo’d functional teams silo’d application architectures
Image from Martin Fowler’s article on microservices, athttp://martinfowler.com/articles/microservices.html
No alterations other than cropping.Permission to reproduce: http://martinfowler.com/faq.html
Silo’d functional teams silo’d application architectures
Image from Martin Fowler’s article on microservices, athttp://martinfowler.com/articles/microservices.html
No alterations other than cropping.Permission to reproduce: http://martinfowler.com/faq.html
Cross functional teams self-contained services
Image from Martin Fowler’s article on microservices, athttp://martinfowler.com/articles/microservices.html
No alterations other than cropping.Permission to reproduce: http://martinfowler.com/faq.html
Cross functional teams self-contained services
Image from Martin Fowler’s article on microservices, athttp://martinfowler.com/articles/microservices.html
No alterations other than cropping.Permission to reproduce: http://martinfowler.com/faq.html
Non-pizza image from Martin Fowler’s article on microservices, athttp://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)
Full ownership
Full accountability
Aligned incentives
“DevOps”
Non-pizza image from Martin Fowler’s article on microservices, athttp://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)
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/)
releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service
releasetestbuild
releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service
releasetestbuild
releasetestbuild
releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
Focused agile teams
2-pizza team delivery pipeline service
Principle 6: Automate everything
AWS
CodeCommit
AWS
CodePipeline
AWS
CodeDeploy
EC2 ELBAuto
ScalingLambdaECS
DynamoDBRDS ElastiCache SQS SWF
SES SNS
API GatewayCloudWatch Cloud Trail
KinesisElasticBeanstalk
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
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
Benefits of microservices
Rapid Build/Test/Release Cycles
Clear ownership andaccountability
Easier to scaleeach individual microservice
New releasestake minutes
Short time to addnew features
Easier to maintain and evolve
Increase innovation
Delighted customers
Increased agility
Benefits of microservices
Rapid Build/Test/Release Cycles
Clear ownership andaccountability
Easier to scaleeach individual microservice
New releasestake minutes
Short time to addnew features
Easier to maintain and evolve system
Faster innovation
Delighted customers
Increased agility
Benefits of microservices
Rapid Build/Test/Release Cycles
Clear ownership andaccountability
Easier to scaleeach individual microservice
New releasestake minutes
Short time to addnew features
Easier to maintain and evolve system
Faster innovation
Delighted customers
Increased agility
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 Servershttps://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
© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Pierre Steckmeyer
Thank you!