Architecture: When, how, and if to Adopt Microservices

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Amit Jha
Solution Architect – Global Financial Services
AWS Startup Day
If when and how to adopt microservices

“The Monolith”
Monoliths can be GOOD when you are starting
out
Always build to keep things as simple as
possible
When your application or company grows,
Monoliths begin slowing you down.
Let’s look at the challenges as you grow..

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

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
Challenges with monolithic software

releasetestbuild
delivery pipeline
app
(aka the“monolith”)
developers
Monolith development lifecycle

Shared libraries
Too much software coupling

Shared libraries
Shared data
Too much software coupling

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

Cross functional teams à self-contained
services
Image from Martin Fowler’s article on microservices, at

Full ownership
Full accountability
Aligned incentives
“DevOps”
Non-pizza image from Martin Fowler’s article on microservices, at
Cross functional teams à self-contained
services
(“Two-pizza teams”)

releasetestbuild
Focused agile teams
2-pizza
team
delivery pipeline service

releasetestbuild
releasetestbuild
Focused agile teams
2-pizza
team

releasetestbuild
releasetestbuild
Focused agile teams
2-pizza
team
releasetestbuild

releasetestbuild
releasetestbuild
Focused agile teams
2-pizza
team
releasetestbuild
releasetestbuild

releasetestbuild
releasetestbuild
Focused agile teams
2-pizza
team
releasetestbuild
releasetestbuild
releasetestbuild

releasetestbuild
releasetestbuild
Focused agile teams
2-pizza
team
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild

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

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

“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

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

“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

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

Application/Logic
(code, libraries, etc)
Data Store
(eg, RDS, DynamoDB

Public API
POST /restaurants
GET /restaurants
Application/Logic
(code, libraries, etc)
Data Store
(eg, RDS, DynamoDB

Drivers
micro-services
Payments
micro-service Location
micro-services
Ordering
micro-services
Restaurant
micro-service
Ecosystem of Microservices

AWS Services (Enablers for Microservices)…

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

Micro-service Design
EC2EC2 EC2 EC2

EC2EC2 EC2 EC2
Elastic Load
Balancer

EC2EC2 EC2 EC2
Elastic Load
Balancer
AWS Elastic
Beanstalk

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

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

EC2EC2 EC2 EC2
Elastic Load
Balancer
Amazon
EC2 Container
Service (ECS)
to manage
containers

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

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

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

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

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

Gilt
Luxury designer brands at
members-only prices

Gilt
Luxury designer brands at
members-only prices
.. Sale every day at noon
EST

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

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

Principle 1:
Hide your data!

Nope!
Principle 1:
Hide your data!

Principle 1:
storeRestaurant (id, name, cuisine)
Version 1.0.0
public API
Micro-service A
Evolve API in backward-compatible way .. And document!

Principle 1:
storeRestaurant (id, name, arbitrary_metadata)
addReview (restaurantId, rating, comments)
Version 1.0.0
Version 1.1.0
public API
Micro-service A

Version 1.0.0
Version 1.1.0
Version 2.0.0
public API
Micro-service A
Principle 1:

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

DynamoDB
Embrace polyglot persistence
Principle 2:
Use the right tool for the job

DynamoDB
Amazon
Elasticsearch
Service
Principle 2:

RDS
Aurora
Amazon
Elasticsearch
Service
Principle 2:

RDS
Aurora
Amazon
Elasticsearch
Service
Embrace polyglot programming frameworks
Principle 2:

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

• 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
• Token-based auth (JWT tokens, OAuth 2.0)
• IAM-based Authentication
• Secrets management
• S3 bucket policies + KMS + IAM
• Open-source tools (e.g. Vault, Keywhiz)
API Gateway
Principle 3:
Secure your services

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

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.
Principle 4:
Be a good citizen within the ecosystem
Proper retries with
exponential backoff

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
Have clear SLAs
Principle 4:

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
Distributed monitoring, logging, and tracing
Principle 4:

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

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

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

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

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

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
Additional Resources

Architecture: When, how, and if to Adopt Microservices

Architecture: When, how, and if to Adopt Microservices

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Architecture: When, how, and if to Adopt Microservices

Semelhante a Architecture: When, how, and if to Adopt Microservices (20)

Mais de Amazon Web Services

Mais de Amazon Web Services (20)

Architecture: When, how, and if to Adopt Microservices