In this session, we walk through the simple process of deploying and managing your own Linux-based application in the cloud and also discuss key use-cases and benefits to automated configuration, deployment, and administration of application stacks. Session sponsored by Red Hat.

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

2. A little bit about Red Hat and AWS…

3. TRUSTED IN THE INDUSTRY
Collaborating with AWS
9years
Had a fix within 1 calendar day of being public
98%of critical vulnerabilities
THE OPEN ORGANIZATION
Of Fortune 500 companies trust Red Hat
90%
More thanOver
To enterprise users
99.999%uptime
Red Hat

4. CLOUD LEADERSHIP
Delivering cloud services
10years
Service improvements in 2015
700
Over
RELIABLE, HIGH-PERFORMANCE
INFRASTRUCTURE
Spanning 13 geographic regions
35Availability Zones
With consistency
48,000IOPS/instance
Capable of delivering
Amazon Web Services

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

6. Red Hat OpenShift on AWS

7. Containers - Transform Apps, Infrastructure, &
Process

8.  Enterprise grade
 Built for both traditional (legacy) and cloud-
native applications
 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
applications
 Multi-language
OpenShift Is Red Hat’s
Container Application Platform

9. SECURITY
SCALABILITY
INTEGRATION
MANAGEMENT
CERTIFICATION
Red Hat Addresses Container Adoption

10. Benefits for Developers
● Access a broad selection of application
components
● Deploy application environments on
demand
● Leverage your choice of interface &
integrate with existing tools
● Automate application deployments, builds,
and source-to-image
● Enable collaboration across users, teams, &
projects

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

12. UNTRUSTED
 Will what’s inside the containers
compromise your infrastructure?
 How and when will apps and libraries be
updated?
 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
 Certification Middleware
 Red Hat Container Registry
 Container Development Kit
 Certification as a Service

13. ● 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
Others
X
X
X
X
X

15. 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,
and performance
Benefits of Red Hat OpenShift on AWS

16. 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, you’re 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 Hat’s entire portfolio of software offerings
including full stack Jboss on OpenShift
Benefits of Red Hat OpenShift on AWS

17. OpenShift Architecture

18. OpenShift Runs on Your Choice of Infrastructure

19. Nodes Are Instances of RHEL Where Apps Will Run

20. Apps and Components Run in Containers
Container
Image
Container
Pod

21. Pods Are the Orchestrated Unit in OpenShift

22. Masters Are the Control Plane

23. API and Authentication

24. Desired and Current State

25. Scheduler Pulls from the Registry

26. Orchestration and Scheduling

27. Placement by Policy

28. Services Connect Application Components

29. Health and Scaling

30. What About Unhealthy Pods?

31. The Master Remediates Pod Failures

32. What About App Data?

33. Routing Layer for External Accessibility

34. Access via Web UI, CLI, IDE, API

35. Interacting with OpenShift

36. OpenShift Architecture/Application

37. CA–OpenShift Deployment
Ganesh Janakiraman
Sr. Director – SaaS Ops and Delivery

38. SaaS @CA
• 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

39. CNN Politics App

40. The Problem
Let’s consider an application with a back-end web service.
HTTP
Service
The service could be Tomcat serving HTML, Jetty
serving OData, Node.js serving plain REST APIs, an
instance of Ruby on Rails—doesn’t matter for this
argument.
How can we deploy this service?

41. The Problem
Let’s say 1 instance of that service can handle 100 users and
requires 1 CPU core.
And let’s 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?
HTTP
Server (1 core)
OS
100 users

42. The Problem
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
RoR instances?
That’s a complex problem, and good solutions must meet many criteria.
But here are four key criteria for CA Platform.
100,000 users 1,000

43. Four Key Criteria
So what are some approaches to this problem?
Capex We’re going large scalein 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
the job.Opex
Isolation
To achieve sufficient reliability, we need resource isolation
between service instances—we can’t let one misbehaving
instance take down hundreds of others.
Flexibility
We need to efficiently add, remove, grow, and shrink services.
In real life, that hypothetical set of 1,000 service instances isn’t
static, isn’t uniform, and isn’t the only set of services.

44. Putting all 1,000 services on a small
number of very large servers is a
nonstarter.
Biggest problem in general: Large
servers are dramatically less cost-
effective than small servers. Large
servers make sense only for
specialized workloads that can’t run
on small servers.
1000-core server
Bad Approach: HumongousServers
OS
1,000
44
Capex Awful
Opex OK,but doesn’t matter
Isolation Awful
Flexibility Awful

45. Bad Approach: Horde of TinyServers
... 1,000 total
Putting each service on its own just-big-enough server
doesn’t work either. Even if that server size happens to
be cost-efficient in cores-per-dollar, opex and flexibility
are unacceptable.
Capex
Bad. Cost-optimal server size is usually bigger than 1 service, and
some of our cost (such as OS licensing) scales with the number of
servers.
Opex
Awful 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!

46. Common Approach: Virtualization
Let’s say the cost-optimal server has 8 cores—enough 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
virtualization.
8-core server
× 125 ...?
Capex
Just OK, because those 1,000 OS instances impose significant
additional overhead—we actually need way more than 125 servers.
Opex
Still awful because we still have 1,000 independent OS instances to
manage. (Plus an additional ton of virtualization software to buy and
operate—which is why VMware loves this approach.)
Isolation Good.(Still overkill.)
Flexibility OK. We can change deployment sizing virtually, though not dynamically.

47. 8-core server
OS with 8 containers
Common Approach: OS Containers
× 125
Capex Good. Cost-optimal hardware. OS (and virtualization) overhead is at a minimum.
Opex
OK. Reasonable number of OS instances to manage, but we haven’t
addressed how to manage thousands of services or how to route application
traffic. Typically, that’s a ton of custom automation.
Isolation Goodenough for web services.
Flexibility
OK. Containers are easierto manage than full VMs, but they are still
individually configurable objects that must be externally automated or manually
maintained.
Container
Service
47

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

49. 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
• Source-to-Image

50. Presentation

51. Q&A

52. 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

53. Red Hat Products on AWS
https://aws.amazon.com/partners/redhat/
Quick Start Guide Red Hat OpenShift
https://s3.amazonaws.com/quickstart-
reference/openshift/doc/red-hat-openshift-on-the-aws-
cloud.pdf
Evaluate OpenShift Enterprise
https://access.redhat.com/products/openshift-enterprise-
red-hat/evaluation
Sign up for AWS for free
http://aws.amazon.com/getting-started
Red Hat on AWS
https://aws.amazon.com/partners/redhat/
Red Hat
https://www.redhat.com/en
OpenShift
https://www.openshift.com/
OpenShift Dedicated
https://www.openshift.com/dedicated/
OpenShift on AWS
https://aws.amazon.com/blogs/apn/deploy-red-hat-
openshift-on-amazon-web-services/
Resources

54. Thank you!
Nicholas Gerasimatos - Twitter: @N_Gerasimatos

55. Remember to complete
your evaluations!