AWS re:Invent 2016: Born in the Cloud; Built Like a Startup (ARC205)

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

Paul Underwood, Solution Architect, AWS

Keith Horwood, CEO and Founder, Polybit

November 29, 2016

Born in the CloudBuilt like a Startup

ARC205

What to Expect from the Session

How to think like a startup when deploying

your next workload on AWS.

Whether you work for an enterprise or a

small business.


My expectations:

• 100-level AWS

constructs

• Familiarity with

AWS services


My expectations:

• 100-level AWS

constructs


AWS services

Architectures we will cover:

• N-tier

• Containerized

• Serverless

Implications on:

• Cost

• Performance

• Team structure


My expectations:

• 100-level AWS

constructs


AWS services

Architectures we will cover:

• N-tier

• Containerized

• Serverless

Implications on:

• Cost

• Performance

• Team structure

Deep dive w/

Polybit:

• Practical

DevOps

techniques in an

increasingly

serverless world

What are startups thinking about?

Expecting

scale

Focus on

features

Lean IT

department

Low cost ==

Long runway

Isn't everybody?

What else are we thinking about?

Reliability Performance Cost efficiency Security

Can building like a startup align these goals?


Expecting

scale

Focus on

features

Lean IT

departmentLow cost ==

Long runway

OK, so how have people done

this historically?

Using these kinds of frameworks…

How? Monolithic/N-tier architectures

Data Center 1

Your infrastructure provider

Data Center 2

Load Balancer

DB Master DB Stby

App Server App Server

How do startups do this on AWS?

git clone git://myrepo && cd myrepo

eb init

eb create prod

pg_restore -v –h mydb.rds.amazonaws.com latest.dump

eb setenv SHARED_KEY_OF_SOME_SORT=34dsa…2x32vxj

/// Changes

eb create test

git add . && git commit -m “profound change“

eb deploy

/// Test

eb switch prod && eb deploy

ExampleApp-Test

This gets us VM-based N-tier on AWS

ExampleApp-Prod

Availability Zone A Availability Zone B

Elastic Load

Balancing

EC2

RDS Stby

EC2

ExampleApp-Test

Plus some significant benefits

ExampleApp-Prod


ELB

EC2

RDS Stby

EC2

Amazon CloudWatch

• Service-wide

resource

monitoring

• Log management

AWS Security

• Identity and access

management

• VPC networking

Specialist services

• Block/object

storage

• Caching

• DNS

ExampleApp-Test

The quickest path to

best practices

AWS Elastic Beanstalk – Making N-Tier Easier

ExampleApp-Prod


ELB

EC2

RDS Stby

EC2AWS Elastic Beanstalk

• Builds you into best

practices from the start

• Integrates with

developer workflows

• Use the Elastic

Beanstalk Command

Line Interface

Amazon CloudWatch

• Service-wide

resource

monitoring

• Log management

AWS Security

• Identity and access

management

• VPC networking

Specialist Services

• Block/Object

Storage

• Caching

• DNS

What does this cost?

“Development-grade” stack “Production-grade” stack

Tier Spec Monthly

Cost

Load

Balancer

1x $18.30

Application

Server

1 x t2.micro $9.52

Database

Server

1 x t2.micro

100 GB

$23.95

Total Monthly $51.77

Tier Spec Monthly

Cost

Load

Balancer

1x $18.30

Application

Server

2 x

m4.large

$121.18

Database

Server

2 x

m4.large

100 GB

$198.93


Containerized Architectures

Containers in theory look like conventional N-tier

VM-based N-tier Container-based N-tTier

Web

Server

Web

Server

ELB

Web

Server

Web

Server

DBStby

HypervisorCont. InstancesCont. InstancesCont. Instances

In practice, leverage the platform

VM-based N-tier Amazon ECS-based N-tier

Web

Server

Web

Server

ELB

Web

Server

Web

Server

DBStby

HypervisorCont. InstancesCont. InstancesCont. Instances

Application

Load Balancer

RDS Standby RDS Master

How startups are building containers on AWS

## set up

aws ecs get-login

docker build –t <tagName> .

docker tag <tagName>:latest <repoUrl>/<tagName>:latest

ecs-cli configure --region us-west-2 --cluster <clusterName>

ecs-cli up --keypair <keyPairID> --capability-iam --size 2 --type …

## auto-generate service and task definition, no ALB, no ASG

ecs-cli compose service create --file docker-compose.yml

ecs-cli compose service start

## instead, use ECS to define more sophisticated services

aws ecs create-service --service-name <serviceName> --cli-input-jsonfile://sophisticated-service-def.json

What does ECS give us?

SchedulerCont. InstancesCont. InstancesCont. Instances

Application

Load Balancer

RDS Standby RDS Master

Container Registry

Dockerfiles

docker-compose.yml

Services/tasks

*Amazon RDS managed

But what about?

SchedulerCont. InstancesCont. InstancesCont. Instances

Service discovery

Container instance

scaling

Container Registry

Dockerfiles

docker-compose.yml

Services/tasks

Container-level

logging

Application

Load Balancer

RDS Standby


“Production-grade”

Amazon EC2 stack

(40% utilization)Tier Spec Monthly

Cost

Load

Balancer

1x $18.30

Application

Server

2 x

m4.large

$121.18

Database

Server

2 x

m4.large

100 GB

$198.93


“Production-grade” ECS stack

(80% utilization)

Tier Spec Monthly

Cost

Load

Balancer

1x $18.30

Container

Instances

2 x

m4.large

$121.18

Database

Server

2 x

m4.large

100 GB

$198.93


N-tier/Container DevOps

The Stack Challenge

Opinion time:

Traditional VM and container

architectures are rooted in

emulating classic physical

servers…

… and therefore inherit the Stack Challenge

Whose responsibility is?

• Server-level configuration:

• Packages/dependencies

• Users/groups

• Build sources

• Files

• Bootstrapping commands

• Services

• Security

• Cluster-level configuration

• Container instances

• Supporting core services

The Stack Challenge

Whose responsibility is?

• Server-level configuration:

• Packages/dependencies

• Users/groups

• Build sources

• Files

• Bootstrapping commands

• Services

• Security

• Cluster-level configuration

• Container instances

• Supporting core services

Tooling can get you so far…

Eventually, you need DevOps staff…

Why???

Developer DevOps

Engineer

!=

What is that rushing sound?

Dev Test Ops Main.

Feature 1

Feature 2

Feature 0

Meanwhile, back at the lab…

Thinking big, inventing, simplifying

Traditional VM and container architectures are rooted in

emulating classic physical servers.

Why should anyone care about servers?

Feature development is far more valuable than solving

server-centric stack challenges.

Why can’t things just scale automatically?

Historical perspective…

2006

EC2

2009

ELB2010

RDS

1946

ENIAC

Monolithic

Cloud VMs

2013

Docker

1979

chroot process isolation

Containers

Tipping point for “modern” startup adoption

What’s next?

Serv

er-

Centr

ic

Arc

hitectu

re

Serverless

A serverless web application architecture

Images/Video

HTML/CSS/JS

Static Asset Requests

Angular/SPA

Amazon

CloudFront/

Amazon S3

Desktop

*aaS

Mobile


Images/Video

HTML/CSS/JS


Dynamic RequestsAWS Lambda

Angular/SPA

Amazon

API Gateway

Amazon

CloudFront/

Amazon S3

api.example.com

Desktop

*aaS

Mobile


Images/Video

HTML/CSS/JS


Dynamic RequestsAWS Lambda

Amazon

DynamoDB

Persistence/Database

Angular/SPA

Amazon

API Gateway

Amazon

CloudFront/

Amazon S3

api.example.com

Desktop

*aaS

Mobile

How to do this on AWS?

Flourish


Imagine the following daily

customer usage pattern:

Cost per user/month:

Assumption Unit

Total Pages / Day 10

Avg Size of Page 200 kb

API Requests / Page 5

Avg size of API Req 4 kb

DB Ops per API Req 2 1r/1w

Storage (per month) 500 kb

Charge Monthly Cost

CloudFront Data Transfer 0.0051

CloudFront Request Pricing 0.0003

S3 Request Pricing (15% cache-hit) 0.00102

S3 Data Transfer 0.004335

API Gateway Data Transfer 0.00054

API Gateway Request Pricing 0.00525

Lambda Request Pricing 0.0003

Lambda Duration Cost 0.000312

DynamoDB IO Pricing 0

DynamoDB Storage 0.000125

Total Monthly Cost / User $0.017282

Microservice thinking

Through a microservice lens on Day 0

Images/Video

HTML/CSS/JS

Service 0:

CoreSiteAWS Lambda

DynamoDB

Angular/SPA

API Gateway

CloudFront/S3

Dev Test

Ops Main.

As microservice complexity scales…

Images/Video

HTML/CSS/JS

Service 1:

CoreSite API

AWS Lambda

DynamoDB

Angular/SPA

API Gateway

CloudFront/S3Dev Test

Ops Main.

Service 0:

CoreSite FrontEnd

Service

Mitosis @ 2

Pizzas

…and so on…

Let your teams pick the right tools for the job

Service 0

Service 2

Service 1

Dev Test

Ops Main.

Dev Test

Ops Main.

Dev Test

Ops Main.


Core Svcs Service 0

Service 2

Service 1

Route 53

DNS

API Gateway

Account Mgmt

Dev Test

Ops Main.

Dev Test

Ops Main.

Dev Test

Ops Main.


Core Svcs Service 0

Service 2

Service 1

Route 53

DNS

API Gateway

Account Mgmt

Dev Test

Ops Main.

Dev Test

Ops Main.

Dev Test

Ops Main.

Big Data

Amazon EMR

Amazon

Kinesis

Amazon

Redshift

Mobile/UX

Amazon

Cognito

Amazon

Mobile Analytics

AWS

Mobile Hub

So, we understand N-tier and container DevOps

Core Svcs Service 0

Service 2

Service 1

Route 53

DNS

API Gateway

Account Mgmt

Dev Test

Ops Main.

Dev Test

Ops Main.

Dev Test

Ops Main.

Big Data

Amazon EMR

Amazon

Kinesis

Amazon

Redshift

Mobile/UX

Amazon

Cognito

Amazon

Mobile Analytics

AWS

Mobile Hub

VM Based N-Tier

Service

Dockerized

Service

Dev Test

Ops Main.

Dev Test

Ops Main.

What about DevOps in a serverless world?

Core Svcs Service 0

Service 2

Service 1

Route 53

DNS

API Gateway

Account Mgmt

Dev Test

Ops Main.

Dev Test

Ops Main.

Dev Test

Ops Main.

Big Data

Amazon EMR

Amazon

Kinesis

Amazon

Redshift

Mobile/UX

Amazon

Cognito

Amazon

Mobile Analytics

AWS

Mobile Hub

Serverless

Service

Dev Test

Ops Main.

Unlocking Practical

Serverless Development

So you want to go serverless…

Scalability Decreased cost

UNIX philosophyOrganizational

Compartmentalization

AWS: The system architecture of the web

Organizational tooling for serverless

- Sharing

- Discovery

- Environments

- Deployment pipelines

- Microservice versioning

- Legacy app interoperability

Discover, create, manage services

https://github.com/poly/stdlib

Install CLI

$ npm install lib –g

Initialize Workspace

$ lib init

Create Service

$ lib create

Test Service Locally

$ f .

Deploy Service [dev]

$ lib up dev

Test Service Remotely

$ f username/service@dev


Discover, create, manage services

https://stdlib.com/search

https://stdlib.com/search

Sharing and discovery

DNS

(Route 53)Gateway

(API Gateway)

Client Request

https://f.yourdomain.com/your-service

your-service

(Lambda)

Environment and deployment

MY_VARIABLE=test

STRIPE_API_KEY=watlol

DATABASE_URL=localhost

// load .env files

require(‘dotenv’);

const stripe = require(‘stripe’);

// do something

process.env.STRIPE_API_KEY

.env index.js


- package.json

- .dev.env

- .staging.env

- .prod.env

- .gitignore

- index.js

files

$ deploy-command --env prod

deploy

- package.json

- .env

- index.js


$ deploy-command --env prod

deploy

- package.json

- .env

- index.js

your-service_prod

(Lambda)

Microservice versioning

Client Request

your-service/VERSION

your-service:VERSION

(Lambda)


$ deploy-command --version VER

deploy

{“Publish”: true}

your-service:Number

(Lambda)

{“Version”:

Number}

createAlias

“VER” :: Number


$ deploy-command --version 1.0.0

deploy

{“Publish”: true}

your-service:NUMBER

(Lambda)

{“Version”:

“NUMBER”}

Mapping:

“1.0.0” :: Number


DNS

(Route 53)

Gateway

(Elastic Beanstalk)

Client Request

your-service/VERSION

your-service

(Lambda)

Version Mapping

(DynamoDB)

Legacy app interoperability

aws-sdk

lambda.invoke(…)

http

f.yourdomain.com/(…)


- Sharing

- Discovery

- Environments





Route 53 API Gateway Lambda

EBS DynamoDBNode.js: “dotenv”…

CLI tools...

One organizational solution

Test Service Locally

$ f .

Deploy Service [dev]

$ lib up dev

Test Service Remotely

$ f username/service@dev

- Sharing

- Discovery

- Environments






https://stdlib.com/reinvent-2016

@polybit

@keithwhor

Your Library for Microservices

https://stdlib.com/reinvent-2016

Final thought…

A well-defined microservice implies its own architecture


Expecting

scale

Focus on

features

Lean IT

departmentLow cost ==

Long runway

Thank you!Paul Underwood – [email protected]

Keith Horwood – [email protected]

Please don’t forget to fill out your survey!

mailto:[email protected]

mailto:[email protected]

AWS re:Invent 2016: Born in the Cloud; Built Like a Startup (ARC205)

Technology

Transcript of AWS re:Invent 2016: Born in the Cloud; Built Like a Startup (ARC205)