Sascha Möllering | zanox AG

Cloud Workshop

About me

Sascha Möllering

sascha@autoscaling.io

Lead Engineer / DevOps Hipster

zanox AG

http://autoscaling.io

@sascha242

About meJava Magazin 11.14

Architektur im Kontext der Cloud: Patterns und Best Practices

AWS Virtual Cloud Summit

Continuous delivery in AWS using Docker

http://aws-summit.de/

Entwickler Spezial: Docker

Über den Wolken: Ein Erfahrungsbericht zum Docker-Einsatz in der Amazon Cloud

Agenda

• AWS Overview

• Creating a cloud service

• Real World example

• Cloud deployment

• Q&A

How can we scale?

RegionRegionUS-WEST (N. California)

US-WEST (N. California) EU-WEST (Ireland)

EU-WEST (Ireland)

ASIA PAC (Tokyo)

ASIA PAC (Tokyo)

ASIA PAC (Singapore)

ASIA PAC (Singapore)

US-WEST (Oregon)US-WEST (Oregon)

SOUTH AMERICA (Sao Paulo)

SOUTH AMERICA (Sao Paulo)

US-EAST (Virginia)US-EAST (Virginia)

GOV CLOUDGOV CLOUD

ASIA PAC (Sydney)

ASIA PAC (Sydney)

Regions

Regions

EU-CENTRAL (Frankfurt)

EU-CENTRAL (Frankfurt)

AWS Overview

ZonesZones

Availability

Zone

Availability

Zone

AWS Overview

AWS Overview

EC2: Resizable compute capacity

AutoScaling: scale up or down

Route 53: Domain Name System

ELB: Load Balancing

Elastic IP: Static IP address

AWS Overview

RDS: Managed database service

DynamoDB: NoSQL implementation

Redshift: data warehouse solution

ElastiCache: Managed cache

Kinesis: Service for streaming data

AWS Overview

S3: Highly-scalable object storage

CloudFront: CDN implementation

CloudWatch: Monitoring service

IAM: Identity and Access Management

EMR: Managed Hadoop

CloudFormation: Configuration Mgmt

Starting point

• How can we leverage the Cloud?

• Our application:– Simple Java based web application

– One application

– One database

– Runs in our own DC

Creating a cloud service

• Initial setup:– Route53 for DNS

– One Elastic IP (static IPs for the Cloud)

– One EC2 instance• Web Application

• Database

– One AZ

Creating a cloud service

Availability Zone

Creating a cloud service

• Simple approach to scale:– Different EC2 instance type

• More RAM• More CPU power• More IOPS

• Approach will hit a barrier

Creating a cloud service

• Problems:– No failover– No redundancy– Database and application on one instance– Does not scale very well

Creating a cloud service

• Separate Web Application from DB– One EC2 instance for the Web Application– One EC2 instance for the DB– Or: Managed DB service (RDS)

• One AZ

Creating a cloud service

Availability Zone

Database

Creating a cloud service

• Problems:– No failover– No redundancy– Does still not scale very well

Creating a cloud service

• Add an ELB

• Add EC2 instance for Web Application

• Different AZs

• Standby DB instance– Multi AZ setup in RDS

Creating a cloud service

Creating a cloud service

Availability Zone

Database

Availability Zone

Database

Creating a cloud service

• Problems:– Still limited scaling capabilities– If one EC2 instance crashes, 50% less

capability

Creating a cloud service

• Add additional EC2 instances

• Add read replicas in RDS

Creating a cloud service

Availability Zone

Database

Availability Zone

Database

Creating a cloud service

• Problems:– Naive implementation– Does not leverage AWS services– Limited scaling– Can be quite expensive

Creating a cloud service

• Refactoring

• Introduce caches to take load from DB

• Use S3 and CloudFront to ship static content

• Store session data in DynamoDB

• Add Autoscaling

Creating a cloud service

• Autoscaling– Automatic resizing of compute clusters

based on demand– Integrated to Amazon CloudWatch– Maximum and minimum pool sizes– Autoscaling policies triggered by

CloudWatch alarms

Creating a cloud service

Requests

Elastic Load Balancing

Latency Metrics CPU Metrics

Amazon CloudWatch

MetricMonitoring

Alarm

Notification

Scale up/down

Creating a cloud service

Availability Zone

Auto Scaling group

Creating a cloud service

• Started with a simple web application

• Added several Amazon services

• Managed to shift load from application to services

• Added caches and CDN

• Added Autoscaling

Creating a cloud service

• Next steps:– SOA/Microservices – Loose coupling: decouple interactions– Amazon services, don‘t reinvent the wheel– Database federation– Database sharding

Docker Deployment

• Amazon Services with Docker support:

– Amazon OpsWorks*

– Elastic Beanstalk

– EC2 Container Service

*by adding a custom Docker Layer

Docker Deployment

• On EC2 level:– Using the Docker remote API

– EC2 User Data

Docker Deployment

• Remote API– API to access Docker daemon

– Can be bound to specific host/port

– E.g. Jenkins can trigger deployments

– GET /containers/json

Docker Deployment

• EC2 User Data– Data to configure instance during launch

• Install Docker

• Start Daemon

• Run Docker container

Demo

• Elastic architecture that grows and shrinks

• Multiple AZs

• Use case: simple web app

• Elastic Beanstalk and Docker

• Postgres RDS DB

Demo

• JHipster– Yeoman generator– Yeoman is a scaffolding tool for webapps– Creates Spring Boot/AngularJS projects

Demo

• Support for:– Maven/Gradle– Spring Security– Spring Data JPA– Elasticsearch– MongoDB– Cassandra– ...

Demo

Demo

Elastic Beanstalk

• Docker support:– Dockerrun.aws.json specifies runtime– Dockerfile is an alternative

• EC2 instances using Docker 1.6

• No direct port mapping

• Local nginx reverse proxy

• Connects to IP of Docker container

Elastic Beanstalk

• Dockerrun.aws.json:– Specifies Docker image (support for private

registries as well)– Defines port for local nginx– Support for volumes and logging as well

Elastic Beanstalk

Elastic Beanstalk

But … we didn’t specify RDS connection strings in our Container?

• RDS specific values are exposed as ENV-variables

• Mapped into the Docker container

• Used by the application to connect to Postgres

Elastic Beanstalk

Elastic Beanstalk

Elastic Beanstalk

• nginx local proxy

• Config in sites-enabled and conf.d

• proxy-pass is http://docker

• Maps to container-ip

Elastic Beanstalk

Elastic Beanstalk

Elastic Beanstalk

Q&A