This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
Email
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
2009
48
280
722
82
2011 2013 2015
706
September2016
Migrating from Monolith to Microservice
“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
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 (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
“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)
“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)
“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)
“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
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
Microservices Architecture on Amazon Web Services
Application Services
API GatewayBuild, 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
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
EC2 Container ServiceRun 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
LambdaRun 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
DynamoDBPredictable 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
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
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!)
“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 microserviceto 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
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
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
951806
Summary
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 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