container days: architecting modern apps on aws

91
© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Architecting Modern Applications on AWS: VMs, Containers, Microservices, Lambda and More 2016-11-04 Mackenzie Kosut @mkosut AWS Startup Evangelist Tara E. Walker @taraw AWS Technical Evangelist

Upload: tara-walker

Post on 11-Jan-2017

97 views

Category:

Technology


0 download

TRANSCRIPT

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

Architecting Modern Applications on AWS: VMs, Containers, Microservices, Lambda

and More

2016-11-04

Mackenzie Kosut@mkosut AWS Startup Evangelist

Tara E. Walker@taraw

AWS Technical Evangelist

15 min Evolution from Monoliths to Microservices

15 minCore Principles of Microservices Approaches to building Microservices on AWS

15 min Other Architectural Principles

5 min Additional Resources

Architecting Modern Applications on AWS: VMs, Containers, Microservices, Lambda and More

2006 EC2 & S3

2016 70+ Managed Services

Kinesis Streaming Analytics, Mobile Testing, Redshift Datawarehouse, Code Deploy/Build Tools, Elastic Container Service, Application Load Balancer, Lambda, API Gateway, DynamoDB, Elastic Map Reduce (Hadoop/Spark/Presto/etc), Elastic Beanstalk, Elastic Transcoder, RDS, Elasticsearch, more..

ENTERPRISE APPS

DEVELOPMENT & OPERATIONSMOBILE SERVICESAPP SERVICESANALYTICS

DataWarehousing

Hadoop/Spark

Streaming Data Collection

Machine Learning

Elastic Search

Virtual Desktops

Sharing & Collaboration

Corporate Email

Backup

Queuing & Notifications

Workflow

Search

Email

Transcoding

One-click App Deployment

Identity

Sync

Single Integrated Console

PushNotifications

DevOps Resource Management

Application Lifecycle Management

Containers

Triggers

Resource Templates

TECHNICAL & BUSINESS SUPPORT

Account Management

Support

Professional Services

Training & Certification

Security & Pricing Reports

Partner Ecosystem

Solutions Architects

MARKETPLACE

Business Apps

Business Intelligence

DatabasesDevOps Tools

NetworkingSecurity Storage

RegionsAvailability Zones

Points of Presence

INFRASTRUCTURE

CORE SERVICES

ComputeVMs, Auto-scaling, & Load Balancing

StorageObject, Blocks, Archival, Import/Export

DatabasesRelational, NoSQL, Caching, Migration

NetworkingVPC, DX, DNS

CDN

Access Control

Identity Management

Key Management & Storage

Monitoring & Logs

Assessment and reporting

Resource & Usage Auditing

SECURITY & COMPLIANCE

Configuration Compliance

Web application firewall

HYBRIDARCHITECTURE

Data Backups

Integrated App Deployments

DirectConnect

IdentityFederation

IntegratedResource Management

Integrated Networking

API Gateway

IoT

Rules Engine

Device Shadows

Device SDKs

Registry

Device Gateway

Streaming Data Analysis

Business Intelligence

MobileAnalytics

2009

48

280

722

82

2011 2013 2015

706

September2016

Migrating from Monolith to Microservice

“The Monolith”

Challenges with monolithic software

Long Build/Test/Release Cycles(who broke the build?)

Operationsis a nightmare(module X is failing, who’s the owner?)

Difficult to scale

New releasestake months

Long time to addnew features

Architecture is hard to maintain and evolve

Lack of innovation

Frustrated customers

Lack of agility

Challenges with monolithic software

Long Build/Test/Release Cycles(who broke the build?)

Operationsis a nightmare(module X is failing, who’s the owner?)

Difficult to scale

New releasestake months

Long time to addnew features

Architecture is hard to maintain and evolve

Lack of innovation

Frustrated customers

Lack of agility

Challenges with monolithic software

Long Build/Test/Release Cycles(who broke the build?)

Operationsis a nightmare(module X is failing, who’s the owner?)

Difficult to scale

New releasestake months

Long time to addnew features

Architecture is hard to maintain and evolve

Lack of innovation

Frustrated customers

Lack of agility

Monolith development lifecycle

releasetestbuild

delivery pipeline

app(aka the“monolith”)developers

Photo by Sage Ross. No alterations other than cropping. https://www.flickr.com/photos/ragesoss/2931770125/Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

Too much software coupling

Too much software coupling

Shared libraries

Too much software coupling

Shared libraries

Shared data

Evolving towards microservices

“IMG_1760” by Robert Couse-Baker. No alterations other than cropping. https://www.flickr.com/photos/29233640@N07/14859431605/Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

“IMG_1760” by Robert Couse-Baker. No alterations other than cropping. https://www.flickr.com/photos/29233640@N07/14859431605/Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

“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

Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)

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

Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)

“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

Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)

“Do one thing, and do it well”

“Swiss Army” by by Jim Pennucci. No alterations other than cropping. https://www.flickr.com/photos/pennuja/5363518281/Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

“Tools” by Tony Walmsley: No alterations other than cropping. https://www.flickr.com/photos/twalmsley/6825340663/Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

“Do one thing, and do it well”

Anatomy of a Microservice

Anatomy of a Microservice

Data Store(eg, RDS, DynamoDB

ElastiCache, ElasticSearch)

Anatomy of a Microservice

Application/Logic(code, libraries, etc)

Anatomy of a Microservice

Data Store(eg, RDS, DynamoDB

ElastiCache, ElasticSearch)

Public API

POST /restaurantsGET /restaurants

Application/Logic(code, libraries, etc)

Anatomy of a Microservice

Data Store(eg, RDS, DynamoDB

ElastiCache, ElasticSearch)

Avoid Software Coupling

Driversmicroservices

Paymentsmicroservice Location

microservices

Orderingmicroservices

Restaurantmicroservice

Ecosystem of Microservices

= 50 million deployments a year

Thousands of teams

× Microservice architecture

× Continuous delivery

× Multiple environments

(5708 per hour, or every 0.63 second)

Gilt: Luxury designer brands at members-only prices

... Sale every day at noon EST

Microservices Architecture on Amazon Web Services

Application Services

API GatewayBuild, 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

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

EC2 Container ServiceRun 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

LambdaRun 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

DynamoDBPredictable 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

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

Microservice A Microservice B

public API public API

Principle 1: Microservices only rely on each other’s public API

public API public API

Principle 1: Microservices only rely on each other’s public API(Hide Your Data)

Microservice A Microservice B

public API public API

Nope!

Principle 1: Microservices only rely on each other’s public API(Hide Your Data)

Microservice A Microservice B

public API public API

Principle 1: Microservices only rely on each other’s public API(Hide Your Data)

Microservice A Microservice B

Principle 1: Microservices only rely on each other’s public API(Evolve API in backward-compatible way…and document!)

storeRestaurant (id, name, cuisine)

Version 1.0.0

public API

Microservice A

Principle 1: Microservices only rely on each other’s public API(Evolve API in backward-compatible way…and document!)

storeRestaurant (id, name, cuisine)

storeRestaurant (id, name, cuisine)storeRestaurant (id, name, arbitrary_metadata)addReview (restaurantId, rating, comments)

Version 1.0.0

Version 1.1.0

public API

Microservice A

Principle 1: Microservices only rely on each other’s public API(Evolve API in backward-compatible way…and document!)

storeRestaurant (id, name, cuisine)

storeRestaurant (id, name, cuisine)storeRestaurant (id, name, arbitrary_metadata)addReview (restaurantId, rating, comments)

storeRestaurant (id, name, arbitrary_metadata)addReview (restaurantId, rating, comments)

Version 1.0.0

Version 1.1.0

Version 2.0.0

public API

Microservice A

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

public API public API

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

DynamoDB

Microservice A Microservice B

public API public API

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

DynamoDB

Microservice A Microservice B

AmazonElasticsearchService

public API public API

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

RDSAurora

Microservice A Microservice B

AmazonElasticsearchService

public API public API

Principle 2: Use the right tool for the job(Embrace polyglot programming frameworks)

RDSAurora

Microservice A Microservice B

AmazonElasticsearchService

public API public API

Principle 2: Use the right tool for the job(Embrace polyglot programming frameworks)

RDSAurora

Microservice A Microservice B

AmazonElasticsearchService

Today’s Workshop

This hands-on workshop will demonstrate the basics of building serverless

applications and microservices on AWS using AWS Lambda, Amazon DynamoDB, Amazon API Gateway, and more.

Building Serverless Microservices on AWS

1:45PM – 2:45PM

DynamoDB

Lambdato retrieverestaurants

Restaurant microservice

API Gateway

POST GET

Lambdato store

restaurants

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

Principle 3: Secure Your Services

• 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• IAM-based Authentication• Token-based auth (JWT tokens, OAuth 2.0)

• Secrets management• S3 bucket policies + KMS + IAM• Open-source tools (e.g. Vault, Keywhiz)

API Gateway

Principle 4

Be a good citizenwithin 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 microserviceto 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.

Microservice A Microservice B

public API public API

Principle 4: Be a good citizen within the ecosystem

Principle 4: Be a good citizen within the ecosystem(Have clear SLAs)

Restaurantmicroservice

15 TPS100 TPS5 TPS20 TPS

Before we let you call our microservice we

need to understand your use case, expected load

(TPS) and accepted latency

…and many,many others!

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

Principle 4: Be a good citizen within the ecosystem(Distributed monitoring, logging and tracing)

Principle 5

More than justtechnology transformation

“rowing on the river in Bedford” by Matthew Hunt. No alterations other than cropping.https://www.flickr.com/photos/mattphotos/19189529/

Image used with permissions under Creative Commons license 2.0,Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’scommunication structure.”

Melvin E. Conway, 1967

Conway’s Law

Silo’d functional teams silo’d application architectures

Image from Martin Fowler’s article on microservices, athttp://martinfowler.com/articles/microservices.html

No alterations other than cropping.Permission to reproduce: http://martinfowler.com/faq.html

Silo’d functional teams silo’d application architectures

Image from Martin Fowler’s article on microservices, athttp://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, athttp://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, athttp://martinfowler.com/articles/microservices.html

No alterations other than cropping.Permission to reproduce: http://martinfowler.com/faq.html

Non-pizza image from Martin Fowler’s article on microservices, athttp://martinfowler.com/articles/microservices.html

No alterations other than cropping.Permission to reproduce: http://martinfowler.com/faq.html

Cross functional teams self-contained services(“Two-pizza teams” at Amazon)

Full ownership

Full accountability

Aligned incentives

Non-pizza image from Martin Fowler’s article on microservices, athttp://martinfowler.com/articles/microservices.html

No alterations other than cropping.Permission to reproduce: http://martinfowler.com/faq.html

Cross functional teams self-contained services(“Two-pizza teams” at Amazon)

Principle 6

Automate Everything

“Robot” by Robin Zebrowski. No alterations other than cropping.https://www.flickr.com/photos/firepile/438134733/

Image used with permissions under Creative Commons license 2.0,Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

releasetestbuild

Focused agile teams

2-pizza team delivery pipeline service

releasetestbuild

releasetestbuild

Focused agile teams

2-pizza team delivery pipeline service

releasetestbuild

releasetestbuild

releasetestbuild

Focused agile teams

2-pizza team delivery pipeline service

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

Focused agile teams

2-pizza team delivery pipeline service

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

Focused agile teams

2-pizza team delivery pipeline service

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

Focused agile teams

2-pizza team delivery pipeline service

Principle 6: Automate everything

AWS

CodeCommit

AWS

CodePipeline

AWS

CodeDeploy

EC2 ELBAuto

ScalingLambdaECS

DynamoDBRDS ElastiCache SQS SWF

SES SNS

API GatewayCloudWatch Cloud Trail

KinesisElasticBeanstalk

951806

Summary

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

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 Polyglot persistence (data layer) Polyglot frameworks (app layer)

3. Secure your services Defense-in-depth Authentication/authorization

6. Automate everything Adopt an Automation Strategy

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

Benefits of Microservices

Rapid Build/Test/Release Cycles

Clear ownership andaccountability

Easier to scaleeach individual microservice

New releasestake minutes

Short time to addnew features

Easier to maintain and evolve

Increase innovation

Delighted customers

Increased agility

Benefits of Microservices

Rapid Build/Test/Release Cycles

Clear ownership andaccountability

Easier to scaleeach individual microservice

New releasestake minutes

Short time to addnew features

Easier to maintain and evolve system

Faster innovation

Delighted customers

Increased agility

Benefits of Microservices

Rapid Build/Test/Release Cycles

Clear ownership andaccountability

Easier to scaleeach individual microservice

New releasestake minutes

Short time to addnew features

Easier to maintain and evolve system

Faster innovation

Delighted customers

Increased agility

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

Popular open-source tools:• Serverless – http://serverless.com• Apex - http://apex.run/

https://aws.amazon.com/devops/

Additional Resources

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

Thank you!

Mackenzie Kosut@mkosut

Tara E. Walker@taraw