Aws Microservices

Microservices
on AWS
Overview
AWS Partner Network

2016/September
2016 Amazon Web Services LLC and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.
Agenda
1. From monolithic systems to microservices

2. The microservices way of building systems
3. Microservices and DevOps
4. Microservices on AWS
5. And some public cases
2016 Amazon Web Services, Inc. or its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent.
From monolithic applications

to
Microservices
a short story about common challenges the IT community faced
through time
This is how we used to design

applications
User
interfac
e
Module 1
Databas
e
Use case 1
Use case 1
Module 2
<<includes>>
Use case 2
<<extends>>
Use case 4
Use case 2
Use case 3
Relational
Use case 3
Module 3
Use case 4
NFS
This is how we used to organize the

team
This is how we used to deploy

applications
Application
Web Server
(User Experience)
Application Server
(Business Services)
Module 1
Module 2
Use case 1
Use case 2
Module 3
Use case 3
User interface
Use case 4
Database
This is how we used to deploy

applications
Web Server
Application Server
Application 1
Application 2
Application 3
Database
with some variations

Web Server
Application Server
Application 1
Application 2
Application 3
Database
But systems are built over

application dependencies
Some System
Application
A
Application A
Application B
Application
B
Application
C
Application C
And we decided to use a service

bus
Welcome SOA
Application A
Application B
Application C
Service BUS
Then we (re)discovered virtualization

Web Server
Database
Application Server
Application 1
Application 2
Application 3
Initially for
development / QA
And here we are

Infrastructure problems solved Development problems NOT
Consolidation of hosts on blade
solved
servers
Consolidation of storages on
SANs
Simplification of infrastructure
management
If the systems are slow:
developers fault
Heavy applications
Code complexity and maintainability
Waterfall development
Tightly coupled
Scaling problems
One size does not fits all
Web-Middle-Data architecture
Lack of ownership
Deployment become the

bottleneck
Failure dependencies
So, we started to question

App 3
Memory or CPU
App 2
App 1
Application Server/
Service BUS
Operating System
Do I I really need all the overhead

of appsrv/svcbus for all services
(or any)?
Do these applications really need
to live together (and bother each
other)?
Do all the applications share the
same requirements for availability,
scalability and fault tolerance?
Can we change applications
frequently without beginning a
war with our
infra-team?
So, we started to question
Memory or CPU
App 3
Do I I really need all the overhead

of appsrv/svcbus for all services
(or any)?
Do
we
really
need
App 2
Do these applications really need
uniqueto standard
live together (and bother each
other)?
App 1
techs and
Do all the applications share the
practices
for for availability,
same requirements
Application Server/
scalability and fault tolerance?
Service BUS
everything?
Can we change applications
Operating System
frequently without beginning a

war with our
infra-team?
And, as we are questioning, maybe we should

re:Invent the way we build applications
User
interfac
e
Module 1
Use case 1
Module 2
Databas
e
CPU
Mem
I/O
DB
Function 1
Function 2
Function 3
Function 4
Use case 2
Use case 3
Module 3
Function 5
Function 6
Function 7
Function 8
Function 9
Use case 4
Function 10
Concur
.
and re:Invent the way we deploy applications

User
interfac
e
Module 1
Databas
e
Function 1
API Call
(CodeLess)
Use case 1
Function 2
Module 2
Function 3
Container
Use case 2
Function 9
Use case 3
Function 10
Module 3
Use case 4
Function 6
Function 4
Function 5
Serverles
s
Function 7
Function 8
and re:Invent the way we organize our teams
The Microservices
way of building systems
Microservices architecture
The microservice architectural style is an approach to
developing a single application as a suite of small
services, each running in its own process and
communicating with lightweight mechanisms, often an HTTP
resource API. These services are built around business
capabilities and independently deployable by fully
automated deployment machinery. There is a bare
minimum of centralized management of these services,
which may be written in different programming
languages and use different data storage technologies.
-- James Lewis and Martin Fowler
Monolithic vs SOA vs Microservices
Monolithic
Single Unit
SOA
Coarsegrained
Microservices Architecture
Microservice
s
Fine-grained
Small Autonomous services Loosely coupled service oriented

that work together
architecture with bounded context
Sam Newman
- Adrian Cockcroft
(author of Building Microservices)
(former cloud architect at Netflix)
Key elements of microservices

Applications are decomposed into small, stateless services
- Single Responsibility Principle - do one thing but do it well
- Separation of concerns - provides isolation of the code base
and more flexibility in the implementation
- Independently managed - clear ownership
Composability
- Write programs to work together
Services become the unit of scale with their own SLAs and
availability profiles
Key elements of microservices

Decentraliz
ed
Elastic
Independen
t
Resilient
Ownership
Composable
Polyglot
Minimal
Complete
Do one
thing well
Blackbox
Registration
Discovery
Wiring
Administrati
on
Versioning
State
Management
Service
Metadata
Public API
Caching
Automated
Deployment
Automated
Management
Automated
Monitoring
Proper options for scaling (and

more)
Functional
Decompositi
on
Amazon
DynamoDB
Amazon
RDS
Amazon
Redshift
Amazon
ElastiCache
Amazon
S3
Application
g
in
n
a
t
io Master
Da rtit
(shard 1)
Pa
Read Replica
Read Replica
Master
Master
(shard 2)
(shard 3)
Read Replica
Read Replica
Taxation
Scale on memory
Checkout
Scale on CPU
Instance Type: m3.medium
Instance Type: c3.xlarge
Read Replica
Read Replica
Cloning
Amazon
EFS
Making the idea tangible

1
1..*
Order
*
0..1
How many microservices

you can imagine here?
OrderItem
*
CRUD for Product details can be based

on Non-relational db (Doc) and store
images on an object storage.
In fact, retrievals can be
implemented by direct API calls (no
server, no code). Implemented by
the Catalog Team.
getProductPrice can be a based on

relacional data, but
getSpecialPriceList(customer) can be
based on DocDb.
Implemented by the Pricing Team,
different techs.
Stock updates can be asynchronously

triggered by order processing.
Customer
1
1
*
SpecialPriceLi
st
*
1
Product
1
*
PriceList
*
1
Region
Microservice challenges
Distributed computing is hard
Fun with Transactions
Multiple Databases across multiple services
Fun with Eventual Consistency
Lots of moving parts
Service discovery
Increase coordination
Increase message routing
Complexity of testing a distributed system
Complexity of deploying and operating a distributed system

Microservices
and DevOps
DevOps
What is it ?
A philosophy? Cultural change? Paradigm shift ?
Alignment of development and IT operations with better
communication and collaboration ?
Improvement in software deployment ?
Breaking down the barriers between development and IT operations ?
Akin to Agile software development applied to infrastructure and IT
operations
Code
Its all of the above Principles !!!
Developer
W
a
l
l
ITOperations
Automating Everything
Automation is an enabling aspect of optimization
Any procedure that can be specified, can be automated.

Werner Vogels
New mindset surround infrastructure
Everything about an environment is described by code
Infrastructure code is on equal footing with application code
Automation is delivered with services
Automation drives tooling and framework requirements
Frequent releases drive frequent evolution

Re-Think Deployment
Manual Deployment
User Experience
Business Services
Production
Release
Packaged Version
Data Access Layer
Automated Delivery Pipeline

Commi
t
Unit
Test
Syste
m Test
Commi
t
Unit
Test
Syste
m Test
Commi
t
Unit
Test
Syste
m Test
UAT
Stagin
g
Prod
Microservice development
lifecycle
develope
rs
services
build
test
release
build
test
release
build
test
release
build
test
release
build
test
release
build
test
release
delivery pipelines
Decentralized
Two-pizza teams
Agility, autonomy,
accountability, and
ownership
DevOps
Deploying More Frequently Lowers Risk

Frequent Release
Events:
Agile Methodology
Change
Change
Rare Release Events:

Waterfall
Methodology
Time
Larger Effort
Increased Risk
Time
Smaller Effort
Minimized Risk
Deployments at Amazon.com
~11.6s
~1,079
~10,000
~30,000
Mean time between deployments

(weekday)
Max number of deployments in a

single hour
Mean number of hosts

simultaneously receiving a
deployment
Max number of hosts

simultaneously receiving a
deployment
2011
numbers
Thousands of teams
Microservice architecture
Continuous delivery
Multiple environments
= 50 million deployments a year
2014
numbers
Microservices
on
AWS
(or, a sneak peek on some AWS microservices capabilities)
On
How AWS can help with operational

complexity?
Demand Resources
No capacity guessing
Resources in any size
Parallel environments
Built-in features
Monitoring via CloudWatch
Security: IAM, CloudTrail,
KMS, CloudHSM
Logging: CloudWatch logs
Scalability: Auto-scaling, ELB,
S3
Availability: multiple regions,
AZs
Options
Standard services, standard
servers, your own servers,
managed services, no servers
Managed/Programmable
Services
Stop RIGHT NOW
If you are writing your own
Notification system
E-mail component
Search engine
Workflow engine
Queue
Transcoding system
Monitoring system
Managed/Programable
Infrastructure as code
Automatic/Programmable
provisioning from single
services to a full network
AWS Deploy and Management

Tooling
Continuous
Delivery
Continuous Integration
Code
Build
Test
Continuous Deployment
Deploy
Provision
Monitor
AWS Elastic Beanstalk

AWS
Code
Commit
AWS CodePipeline
AWS
OpsWorks
AWS
Code
Deploy
AWS Cloud
Formation
Amazon
ECS
AWS
Cloud
Watch

Tooling
Continuous
Delivery
Continuous Integration
Code
Build
Test
Continuous Deployment
Deploy
Provision
Monitor

AWS
Code
Commit
AWS CodePipeline
AWS
OpsWorks
AWS
Code
Deploy
AWS Cloud
Formation
Amazon
ECS
AWS
Cloud
Watch

Tooling
AWS CodeDeploy
AWS OpsWorks
Convenience
Control
Typical
microservices architectures
Microservices architectures
Content
Delivery
API
Layer
Elastic Load
Balancing
CloudFron
t
Application
Layer
Amazon
EC2
Elastic Load
Balancing
Persistency
Layer
Amazon
EC2
Amazon
RDS
Autoscaling
group
Autoscaling
group
Amazon
ElastiCache
Static content
Amazon
S3
Content
Delivery
API
Layer
Application
Layer
Elastic Load
Balancing
CloudFron
t
Persistency
Layer
Amazon
EC2
Amazon
RDS
Amazon API
Gateway
Static content
Amazon
S3
Managing multiple versions

and stages
Monitoring 3rd party
developer access
Access authorization
Traffic spikes
Caching
Swagger Support
Request/Response
Transformation
API Mocking
Autoscaling
group
Amazon
ElastiCache
Content
Delivery
API
Layer
Application
Layer
Elastic Load
Balancing
CloudFron
t
Persistency
Layer
EC2
Container
Service
Amazon
RDS
Amazon API
Gateway
Static content
Amazon
S3
Manage Docker images

Container registry
Container deployment
Container scheduling
Container cluster
configuration and
management
Amazon
EC2
Amazon
ElastiCache
Autoscaling
group
Content
Delivery
API
Layer
Application
Layer
Elastic Load
Balancing
CloudFron
t
Persistency
Layer
EC2
Container
Service
Amazon
DynamoDB
Amazon API
Gateway
Amazon
EC2
Static content
Amazon
S3
Autoscaling
group
Single digit
millisecond
latency at any
scale
Highly
scalable
NoSQL
database
Content
Delivery
API
Layer
Application
Layer
Persistency
Layer
CloudFron
t
Lambda calls
Amazon API
Gateway
Static content
AWS
Lambda
Amazon
S3
Lambda
triggers
Serverles
s
First 1
million requests
computin
per month are free
$0.20 per 1g
million
requests thereafter
($0.0000002 per request)
Pay for 100ms units *
Memory size (charged
$0.00001667 for every
GB-second used).
https://aws.amazon.com/blogs/compute/microservices-without-the-s
ervers
Amazon
DynamoDB
Codeless computing
Amazon
CloudFront
Amazon API
Gateway
Amazon
DynamoDB
Amazon
S3
https://aws.amazon.com/blogs/compute/using-amazon-api-gateway-as-a-proxy-for-dynamodb/
A sample architecture
https://aws.amazon.com/solutions/case-studies/localytics/
And for monitoring

Amazon
ECS
AWS
Lambda
CloudWatch
logs
Amazon
Kinesis
Firehose
Amazon
Redshift
Amazon
QuickSight
Amazon
EC2
... you have options

Amazon
ECS
AWS
Lambda
CloudWatch
logs
Amazon
Elasticsearch
Service
Amazon
EC2
Some public cases
https://
www.youtube.com/watch?v=JWXoX50hWXA
https://www.youtube.com/watch?v=a45J6xAGUvA
https://www.youtube.com/watch?v=C4c0pkY4NgQ
https://www.youtube.com/watch?v=3e2YgLHKePI
And dont reinvent the wheel, embrace Open Source

Netflix: Dozens of tools
https://netflix.github.io/
Airbnb: SmartStack
http://
nerds.airbnb.com/smartstack-service-discovery-cloud/
Twitter: Mesos
https://mesos.apache.org/
LinkedIn: Rest.li
https://github.com/linkedin/rest.li
Use our partners
And take a look to a good detailed reference

AWS Summit Series 2016 | Chicago - Deep Dive on Microservices and
Amazon ECS
https://
www.youtube.com/watch?v=QuYNxoqz0oY
Capgemini CWIN Challenge

Your company was select to build a new application for your states
government.
Through this application, cities citizens can post an collaboratively
prioritize public issues and government can map and track
priorities and issues resolutions.
Citizens want to register and track issues resolutions.
Government want to be transparent, focus on priorities, track
resolution times and improve communication with community
representatives.
Propose a cost-efficient replicable microservices-based architecture
for this new groundbreaking application.

Aws Microservices

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aws Microservices

Uploaded by

Copyright:

Available Formats

Microservices

AWS Partner Network

1. From monolithic systems to microservices

From monolithic applications

This is how we used to design

This is how we used to organize the

This is how we used to deploy

This is how we used to deploy

with some variations

But systems are built over

And we decided to use a service

Then we (re)discovered virtualization

And here we are

Code complexity and maintainability

One size does not fits all

Deployment become the

So, we started to question

Do I I really need all the overhead

So, we started to question

Do I I really need all the overhead

frequently without beginning a

And, as we are questioning, maybe we should

and re:Invent the way we deploy applications

and re:Invent the way we organize our teams

Monolithic vs SOA vs Microservices

Small Autonomous services Loosely coupled service oriented

(author of Building Microservices)

(former cloud architect at Netflix)

Key elements of microservices

Key elements of microservices

Proper options for scaling (and

Instance Type: m3.medium

Instance Type: c3.xlarge

Making the idea tangible

How many microservices

CRUD for Product details can be based

getProductPrice can be a based on

Stock updates can be asynchronously

Distributed computing is hard

Fun with Transactions

Multiple Databases across multiple services

Fun with Eventual Consistency

Lots of moving parts

Increase message routing

Complexity of testing a distributed system

Complexity of deploying and operating a distributed system

Its all of the above Principles !!!

Automation is an enabling aspect of optimization

Any procedure that can be specified, can be automated.

New mindset surround infrastructure

Everything about an environment is described by code

Infrastructure code is on equal footing with application code

Automation is delivered with services

Automation drives tooling and framework requirements

Frequent releases drive frequent evolution

Data Access Layer

Automated Delivery Pipeline

Deploying More Frequently Lowers Risk

Rare Release Events:

Mean time between deployments

Max number of deployments in a

Mean number of hosts

Max number of hosts

How AWS can help with operational