srv409 deep dive on microservices and docker

© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Pierre Steckmeyer, AWS Solutions Architect

Will McCutchen, BuzzFeed Chief Refactoring Officer

August 14, 2017

Deep Dive on Microservices

and Docker

What to Expect from the Session

• Microservices Architecture

• Amazon ECS

• The Twelve-Factor App with Amazon ECS

• Task Placement

• BuzzFeed’s story

Microservices Architecture

What are microservices?

“A software architecture style in which complex

applications are composed of small, independent

processes communicating with each other using

language-agnostic APIs. These services are small, highly

decoupled and focus on doing a small task, facilitating a

modular approach to system-building.” - Wikipedia

https://en.wikipedia.org/wiki/Microservices

Monolithic vs. Microservices

webserver

.package

Order UI

Order Service

Inventory

Service

Shipping

Service

OrderUI

Inventory

Service

Order

Service

Shipping

Service

Characteristics of Microservice Architectures

Do one

thing wellIndependent

Decentralized

Black box

Polyglot

You build it, you run it

Why Amazon ECS

• Fully managed elastic service – You don’t

need to run anything, and the service

scales as your microservices architecture

grows

• Shared state optimistic scheduling

• Integration with Amazon CloudWatch

service for monitoring and logging

• Integration with Code* services for

continuous integration and delivery (CI/CD)

Deploying Containers on ECS – Choose a Scheduler

Batch Jobs

ECS task scheduler

Run tasks once

Batch jobs

RunTask (random)

StartTask (placed)

Long-Running Apps

ECS service scheduler

Health management

Scale-up and scale-down

AZ aware

Grouped containers

The Twelve-Factor App with

Amazon ECS

Reference Architectures

The Twelve-Factor App

1. Codebase

2. Dependencies

3. Config

4. Backing Services

5. Build, Release Run

6. Processes

7. Port Binding

8. Concurrency

9. Disposability

10. Dev/Prod parity

11. Logs

12. Admin Processes

https://12factor.net/

Reference Architectures

Automatic Service Scaling

Publish metrics

Auto Scaling ECS service

Availability

Zone A

Availability

Zone B

TASK A

Add/Remove ECS

tasks

TASK C

TASK BScaling Policies

Amazon

CloudWatch

Amazon ECS

Application

Load Balancer

IAM Roles for Tasks

ECS Cluster

EC2 Instance EC2 Instance

TASK A

TASK B

TASK B

Amazon

DynamoDBAmazon

S3

Secrets Management

•prod.app1.db-pass

•general.license-code

•prod.app2.user-name

ECS Cluster

EC2 Instance EC2 Instance

TASK A

TASK B

TASK B

EC2 System Manager –

Parameter Store

Continuous Deployment

AWS

CodeCommit AWS

CodePipeline

AWS

CodeBuild

Amazon

ECR

Amazon

ECS

instance

Spot

Instance

AWS

CloudFormation

1. Commit

Code

2. Trigger

Pipeline

3.

Bu

ild

Art

ifact

5.

Up

da

te

Sta

ck

6. Update Service

4. Push Image

Blue-Green Deployments (DNS based)

TaskTask

Route 53

record set

with

weighted

routing

policy

0%

100%

Blue-Green Deployments (Target Group Switch)

TaskTask

Target

group 1

Target

group 2

Target

group 2Target

group 1

Switch Target

Groups

myproduct.com

Service Discovery with Route 53 and Application

Load Balancers

Application Load

Balancer

i-aaa i-bbb i-ccc

i-aaa i-bbb i-ccc

oAuth Target Group

8080 8081

Portal Target Group

Weather Target Group

8000 8001 8002

8080

Amazon

Route 53

ECS Cluster

mydomain.com

mydomain.com mydomain.com/weather

mydomain.com/auth

Consuming Events for Service Discovery

app1-tst 10.1.0.11

db1-tst 10.1.0.14

app2 10.1.0.16

db2 10.1.0.18

my-app 10.1.0.20

websrv1 10.1.0.1

websrv2 10.1.0.2

websrv3 10.1.0.4

app-dev1 10.1.0.9

app-dev2 10.1.0.5

app-dev3 10.1.0.8

db-dev 10.1.0.19

Task Placement Examples

g2.2xlarge t2.small g2.2xlarge g2.2xlarge

Placement: Targeting Instance Type

g2.2xlarge t2.small t2.micro t2.medium

t2.medium t2.small g2.2xlarge

t2.small

t2.small t2.medium

us-east-1aus-east-1d

Placement: Targeting Instance Type & Zone

g2.2xlarge t2.small t2.micro t2.medium

t2.medium t2.small g2.2xlarge t2.small

us-east-1aus-east-1d

g2.2xlarge t2.medium

t2.micro t2.small

us-east-1c

Placement: Spread across Zone and Binpack

g2.2xlarge t2.small t2.micro t2.medium

t2.medium t2.small g2.2xlarge t2.small

us-east-1aus-east-1d

g2.2xlarge t2.medium

t2.micro t2.small

us-east-1c

Placement: Affinity and Anti-Affinity

Running a Service

Customers

Problem:

• A large number of smart phone devices and IoT

devices as of the launch of new flagship

smartphone model launch.

• Integration with existing SmartThings service

• Global development team in 4 locations had to develop more than 60 functional modules.

Solution:

• Microservice Architecture on AWS

• Amazon EC2 Container Service, AWS Lambda, Amazon Aurora, Amazon DynamoDB

Business Benefits:

• “Expect a rich IoT experience with Samsung Connect built on Amazon's robust cloud” – VP Subaek Jang

Samsung Connect Service supports a number of smart

phone devices and IoT devices as of the launch of new

flagship smartphone model launches. AWS service such

as AWS EC2 Container Service, AWS Lambda, Amazon

Aurora and Amazon DynamoDB, Samsung could

successfully develop Samsung Connect application with

more than 60 functional modules by 4 global development

teams in Micro-Service Architecture.

• AWS Seoul Summit Keynote -https://youtu.be/061bsq0jVYU?t=1h16m

Samsung Connec t

Customer case: Samsung Electronics – Samsung Connect

IoT Connected

Devices

Event Pipeline

EC2

S3

Galaxy Devices Microservice

Microservice

Microservice

IoT Protocol

Endpoint

ELB/ALB

DynamoDB &

Aurora

Manufacturers

Developers

KMS

CloudHSM

Lambda/

API GW3rd Party Cloud

Admin

CloudWatch

Scale-in/out

Policy

…..

Microservice

Customer case: Samsung Connect Microservices

WatchBot

ECS Cluster

SQS

Watcher

Container

Running

Tasks

14Data Processing

Services

3500Peak Container

Instances

500 millionCompute Hours

Used in 2016

Building a

platform

on ECS

● ~400 services currently deployed

● ~80 container instances

● 7 clusters

● 2 regions

● ~16 months in production

● ~180 users

● ~39,000 deploys

Where are we now?

How did we get here?

How did we get here?

How did we get here?

microservices.gif from Justin Duke

(@justinmduke)

What we learned

Make your development & deployment workflow as frictionless as possible

Target abstractions, force consistency

Leverage the whole AWS platform

Make everything self-service

Some challenges

Network-level access control and isolation

Quickly & safely rolling clusters

Sharing ECR registries

Efficiency

What's next?

Will McCutchenPlatform Infrastructure

will.mccutchen@buzzfeed.com

twitter.com/mccutchen

Thank You

Thank You!