AWS re:Invent 2016: Develop, Build, Deploy, and Manage Containerized Services and Applications on the AWS Cloud (DEV404)
Post on 08-Jan-2017
2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Nicholas Gerasimatos, Red Hat CCSP Cloud Evangelist
November 1, 2016
Develop, Build, Deploy, and Manage
Containerized Services and Applications on
the AWS Cloud
A little bit about Red Hat and AWS
TRUSTED IN THE INDUSTRY
Collaborating with AWS
Had a fix within 1 calendar day of being public
98%of critical vulnerabilities
THE OPEN ORGANIZATION
Of Fortune 500 companies trust Red Hat
To enterprise users
Delivering cloud services
Service improvements in 2015
Spanning 13 geographic regions
48,000IOPS/instanceCapable of delivering
Amazon Web Services
AWS Direct Connect Amazon VPC
VM Import/Export AWS CloudFormation
AWS Identity and Access Management AWS CLOUDYOUR DATA CENTER
Red Hat and AWS Extend Your Existing Data Center
Red Hat OpenShift on AWS
Containers - Transform Apps, Infrastructure, &
Built for both traditional (legacy) and cloud-
Integrated hybrid cloud application platform
for application development and deployment
Portable platform designed to develop, build,
and manage container-based applications
across different environments
Easily turn source code into running
OpenShift Is Red Hats Container Application Platform
Red Hat Addresses Container Adoption
Benefits for Developers
Access a broad selection of application components
Deploy application environments ondemand
Leverage your choice of interface & integrate with existing tools
Automate application deployments, builds,and source-to-image
Enable collaboration across users, teams, & projects
Benefits for IT Operations
Deploy a secure, enterprise-grade container-based application platform
Enable application developers while improving operational efficiency & infrastructure utilization
Utilize advanced scheduling and automated placement with regions and zones for HA
Leverage powerful declarative management for application services
Manage user & team access and integrate with enterprise authentication systems
Will whats inside the containers
compromise your infrastructure?
How and when will apps and libraries be
Will it work from host to host?
Can I use the same solution on-premises
and in the Cloud?
DIY Container Platform vs. Red Hat OpenShift
RED HAT CERTIFIED
Trusted source for the host and the containers
Trusted content inside the container with security fixes
available as part of an enterprise lifecycle
Portability across hosts
OpenShift can be deployed on premises or on AWS
Certified Container Images
Red Hat Container Registry
Container Development Kit
Certification as a Service
A better developer experience
A bigger selection of fully supported services
A more powerful, standards-based orchestration engine
A more secure, standards-based container model
A more reliable, trusted,and fully supported Linux OS foundation
OpenShift Compared to Other Platforms
Red Hat and AWS provide a complete, enterprise-class computing
environment that is simple and scalable
Red Hat gives your organization access to a secure and easy-to-manage
platform that meets the changing needs of your business
OpenShift on Amazon Web Services provides the power and flexibility of
your own OpenShift Container Platform Cluster backed by Red Hat
engineering, operations, and support!
Hosting OpenShift on AWS enables cost-effective security, reliability,
Benefits of Red Hat OpenShift on AWS
Your Red Hat subscription provides access to technical experts and
support services to help you successfully build, deploy, and manage
your enterprise solutions
Access OpenShift through your Red Hat subscription
When you use Red Hat Enterprise Linux on demand, youre only
paying for what you use on Amazon EC2
Pre-existing Red Hat subscriptions can be moved easily to AWS
using Cloud Access
Flexibility to run Red Hats entire portfolio of software offerings
including full stack Jboss on OpenShift
Benefits of Red Hat OpenShift on AWS
OpenShift Runs on Your Choice of Infrastructure
Nodes Are Instances of RHEL Where Apps Will Run
Apps and Components Run in Containers
Pods Are the Orchestrated Unit in OpenShift
Masters Are the Control Plane
API and Authentication
Desired and Current State
Scheduler Pulls from the Registry
Orchestration and Scheduling
Placement by Policy
Services Connect Application Components
Health and Scaling
What About Unhealthy Pods?
The Master Remediates Pod Failures
What About App Data?
Routing Layer for External Accessibility
Access via Web UI, CLI, IDE, API
Interacting with OpenShift
Ganesh JanakiramanSr. Director SaaS Ops and Delivery
Market leading SaaS solutions in: Project and portfolio management Agile management Online payment authentication Performance testing Identity security
Global customer base accessing 24x7x365 mission-critical applications FedRAMP/PCI/SOC 2 compliance certification Global footprint for redundancy and data residency
CNN Politics App
Lets consider an application with a back-end web service.
The service could be Tomcat serving HTML, Jetty
serving OData, Node.js serving plain REST APIs, an
instance of Ruby on Railsdoesnt matter for this
How can we deploy this service?
Lets say 1 instance of that service can handle 100 users and
requires 1 CPU core.
And lets say we have 100 users. We could simply run 1 service
on 1 physical server (or VM) with 1 core. No problem.
But what if we have 100,000 users?
Server (1 core)
With 100,000 users, we need 1,000 service instances,
which need at least 1,000 cores.
How can we deploy an application with 1,000 Tomcats or 1,000
Thats a complex problem, and good solutions must meet many criteria.
But here are four key criteria for CA Platform.
100,000 users 1,000
Four Key Criteria
So what are some approaches to this problem?
Capex Were going large scale in the first place because we are
delivering SaaS, and SaaS profitability calls for the most cost-
efficient hardware, software, and operations labor that can do
To achieve sufficient reliability, we need resource isolation
between service instanceswe cant let one misbehaving
instance take down hundreds of others.
We need to efficiently add, remove, grow, and shrink services. In real life, that hypothetical set of 1,000 service instances isnt static, isnt uniform, and isnt the only set of services.
Putting all 1,000 services on a small
number of very large servers is a
Biggest problem in general: Large
servers are dramatically less cost-
effective than small servers. Large
servers make sense only for
specialized workloads that cant run
on small servers.
Bad Approach: Humongous Servers
Opex OK,but doesnt matter
Bad Approach: Horde of Tiny Servers
... 1,000 total
Putting each service on its own just-big-enough server
doesnt work either. Even if that server size happens to
be cost-efficient in cores-per-dollar, opex and flexibility
CapexBad. Cost-optimal server size is usually bigger than 1 service, and some of our cost (such as OS licensing) scales with the number ofservers.
OpexAwful because we have 1,000 independent OS instances to manage. (The data center automation business from 10 years ago would love to help you try to fix this.)
Isolation Good. (Actually, total overkill for web apps.)
Flexibility Awful, especially if our service outgrows our server!
Common Approach: VirtualizationLets say the cost-optimal server has 8 coresenough raw capacity for 8
services (ignoring overhead). To isolate those 8 services from each other,
we need some way to subdivide our physical servers. Enter
CapexJust OK, because those 1,000 OS instances impose significant
additional overheadwe actually need way more than 125 servers.
OpexStill awful because we still have 1,000 independent OS instances tomanage. (Plus an additional ton of virtualization software to buy and operatewhich is why VMware loves this approach.)
Isolation Good.(Still overkill.)
Flexibility OK. We can change deployment sizing virtually, though not dynamically.
OS with 8 containers
Common Approach: OS Containers
Capex Good. Cost-optimal hardware. OS (and virtualization) overhead is at a minimum.
OK. Reasonable number of OS instances to manage, but we havent
addressed how to manage thousands of services or how to route application
traffic. Typically, thats a ton of custom automation.
Isolation Goodenough for web services.
FlexibilityOK. Containers are easier to manage than full VMs, but they are stillindividually configurable objects that must be externally automated or manuallymaintained.
OpenShift at CA
One of the initial adopters of Red Hat OpenShift since 2012
CA and Red Hat partnership in building internal PaaS
OpenShift 3 adopts Docker and Kubernetes:
Docker brings de facto standard container technology
Kubernetes is a proven container orchestration platform
Red Hat provided web console, RBAC, self- service templates, security, and more
OpenShift in AWS and on VMWare
OpenShift How Do We Use It Today?
Multitenancy using projects provides right isolation
Autoscaling pods with CPU
Different deployment strategies (A/B , rolling) based on project
Resource allocation caps and workload sharing
Integrated Docker Registry
Red Hat Quick Start has been built in collaboration with Red Hat and features OpenShift by Red
Hat on AWS
Quick Starts are automated reference deployments that use AWS CloudFormation templates to
launch, configure, and run the AWS compute, network, storage, and other services required to
deploy a specific workload on AWS
Request a $2000 credit from AWS to deploy Red Hat OpenShift on AWS as a Proof of Concept
with a comprehensive suite of services.
Please visit https://aws.amazon.com/partners/redhat/ to request the POC credits
Overview of the POC Program
Red Hat Products on AWS
Quick Start Guide Red Hat OpenShift
Evaluate OpenShift Enterprise
Sign up for AWS for free
Red Hat on AWS
OpenShift on AWS
Nicholas Gerasimatos - Twitter: @N_Gerasimatos
Remember to complete