This document provides an overview of microservices architecture and how BuzzFeed uses it with Amazon ECS and Docker containers. It discusses the benefits of microservices and characteristics. It then details how BuzzFeed developed their WatchBot platform on Amazon ECS, including that they now have over 400 services deployed across 7 clusters in 2 regions, with over 180 users and 39,000 deploys. The document also discusses lessons learned in developing the platform and current challenges.

1. © 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

2. What to Expect from the Session
• Microservices Architecture
• Amazon ECS
• The Twelve-Factor App with Amazon ECS
• Task Placement
• BuzzFeed’s story

3. Microservices Architecture

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

5. Monolithic vs. Microservices
webserver
.package
Order UI
Order Service
Inventory
Service
Shipping
Service
OrderUI
Inventory
Service
Order
Service
Shipping
Service

6. Characteristics of Microservice Architectures
Do one
thing wellIndependent
Decentralized
Black box
Polyglot
You build it, you run it

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

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

9. The Twelve-Factor App with
Amazon ECS
Reference Architectures

10. 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/

11. Reference Architectures

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

13. IAM Roles for Tasks
ECS Cluster
EC2 Instance EC2 Instance
TASK A
TASK B
TASK B
Amazon
DynamoDB
Amazon
S3

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

15. Continuous Deployment
AWS
CodeCommit AWS
CodePipeline
AWS
CodeBuild
Amazon
ECR
Amazon
ECS
instance
Spot
Instance
AWS
CloudFormation
1. Commit
Code
2. Trigger
Pipeline
3.Build
Artifact
5.Update
Stack
6. Update Service
4. Push Image

16. Blue-Green Deployments (DNS based)
TaskTask
Route 53
record set
with
weighted
routing
policy
0%
100%

17. Blue-Green Deployments (Target Group Switch)
TaskTask
Target
group 1
Target
group 2
Target
group 2
Target
group 1
Switch Target
Groups
myproduct.com

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

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

20. Task Placement Examples

21. g2.2xlarge t2.small g2.2xlarge g2.2xlarge
Placement: Targeting Instance Type

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

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

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

25. Running a Service

26. Customers

27. 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
Connect
Customer case: Samsung Electronics – Samsung Connect

28. 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 GW
3rd Party Cloud
Admin
CloudWatch
Scale-in/out
Policy
…..
Microservice
Customer case: Samsung Connect Microservices

29. WatchBot
ECS Cluster
SQS
Watcher
Container
Running
Tasks
14
Data Processing
Services
3500
Peak Container
Instances
500 million
Compute Hours
Used in 2016

30. Building a
platform
on ECS

32. ● ~400 services currently deployed
● ~80 container instances
● 7 clusters
● 2 regions
● ~16 months in production
● ~180 users
● ~39,000 deploys
Where are we now?

33. How did we get here?

34. How did we get here?

35. How did we get here?
microservices.gif from Justin Duke
(@justinmduke)

36. What we learned

37. Make your
development &
deployment
workflow as
frictionless as
possible

38. Target
abstractions,
force
consistency

39. Leverage the
whole AWS
platform

40. Make everything
self-service

41. Some challenges

42. Network-level
access control
and isolation

43. Quickly & safely
rolling clusters

44. Sharing ECR
registries

45. Efficiency

46. What's next?

48. Will McCutchen
Platform Infrastructure
will.mccutchen@buzzfeed.com
twitter.com/mccutchen

49. Thank You

50. Thank You!