Strategies for Securing Availability and Optimizing Application Performance in the Cloud

Editor's Notes

• #11: In Red Hat fashion, we are leveraging the best of community-powered innovation to drive the development of OpenShift Origin. OpenShift Origin then becomes the “Upstream” project for Red Hat’s PaaS offerings, OpenShift Online and OpenShift Enterprise. These two enterprise-class PaaS solutions leverage the combination of the innovation provided by the community and the enterprise support provided by Red Hat. Whether you want to utilize PaaS in the public cloud, or on-premise, the OpenShift technology is available to you.<next slide>
• #12: OpenShift utilizes the RHEL instances and delegates them to one of two different functions.Some of the instances are designated as OpenShift Brokers which serve as the control plane, or management system, for the PaaS. Brokers can be configured in a redundant configuration for HA and failover. Utilizing messaging and automation technologies, the Brokers keep the PaaS running.The rest of the RHEL instances are designated as OpenShift Nodes and these instances are where user applications will reside.<next slide>
• #13: These slices of RHEL are called OpenShift Gears. OpenShift Gears are super-secure and highly efficient containers that host user applications in OpenShift. To the user, the Gear appears like an instance of RHEL. They can even SSH in to the gear. They can see their processes, their memory, and their filesystem, but they are prevented from seeing or impacting anyone else’s environment or the system as a whole.SELinux was built by Red Hat in conjunction with the National Security Agency in order to support some of their strict requirements. It is a “Deny everything, and allow by exception” policy subsystem that allows very strict control of what processes and users can do. In OpenShift, SELinux policies are used to enable hi security in a container based multitenant environment. Likewise, Control Groups are used to carefully control what resources an OpenShift Gear is able to consume. Cgroups allow Gears to consume CPU and RAM but also limits that consumption based on configurable policies. And finally NameSpaces are used to allow each Gear to have it’s own file system complete with the system directories that it may need including /tmp, /var, and others.Red Hat has been able to leverage these technologies to build a secure and yet efficient multi-tenant PaaS because Red Hat has incredible knowledge with respect to the Operating System underneath, Red Hat Enterprise Linux. With some of the best linux kernel coders in the world, Red Hat has used these smarts to build a cloud Platform-as-a-Service on top of the industry leading enterprise Linux operating system.OpenShift Gears represent the resulting benefit of leveraging this wealth of knowledge in the Operating System Platform to build a Cloud Application Platform that is both super-secure and highly efficient.<Optional statements>The OpenShift Gear-based architecture provides two other key benefits:Deploying multi-tenancy inside of RHEL Nodes allows many, many applications to be maintained by deploying maintenance to a much smaller set of RHEL Operating System instances. The Sys Admins job becomes much easier when they only need to patch and perform maintenance on a small number of nodes instead of 1000s of Virtual Machine instances (as would be the case with VM-based multi-tenancy).OpenShift also has the ability to “Idle” Gears that are not actively being used. In this situation the Broker will take a snapshot of an application Gear and write it to disk to take it out of RAM. Network connections are maintained so when an application URL is requested, the Gear will be “un-idled” and able to service the request quickly. This Idling technology allows many more Gears to be supported within one instance of RHEL because not all Gears will be active at the same time. Implemented for the OpenShift hosted service, this Idling capability is also beneficial to the enterprise that wants to optimize resource consumption as much as possible.<next slide>
• #14: So, let’s take a look at how a Developer would use OpenShift once the Brokers and Nodes are up and running.When a Developer wants to create a new application, the first thing to do is to instantiate a container for the application language runtime and middleware in the PaaS. With OpenShift the Developer can do this using their choice of interface. They can work from the command line via OpenShift’s RHC command-line tool set, they can work from the OpenShift Web Console interface, or they can work from their Eclipse-based IDE.When the Developer gives the command to create a new application, the OpenShift Broker looks at the Nodes, determines the best place to create the application based on resources and/or policy and then it creates the Gear for the user’s application and provides the connectivity information back to the user.<next slide>
• #15: As part of the application creation process, the user specifies what Language they want to program in and what middleware or database services they want to use. OpenShift installs these via OpenShift Cartridges. The OpenShift Cartridge technology is an extensible mechanism for providing application development services to the Developer.When database cartridges are installed in a second gear (the default configuration, BTW), OpenShift will automatically wire the two gears together on the network and it will automatically create the new datasource definition within the Jboss configuration, for example.<next slide>
• #16: OpenShift provides built-in Cartridges for most of the popular programming languages including Java, Ruby, Node.JS, PHP, Python, and Perl along with the many Frameworks that can be used with these languages. With OpenShift, Developers can pick the language that either is best suited to solve the problem at hand, or is the one that they are most comfortable with. Our goal is to allow Developers to work the way they want to work.OpenShift also provides MySQL and Postgres as relational database options and MongoDB as a NoSQL alternative.In addition to these built-in capabilities OpenShift also provides the ability to create Custom Cartridges so that a user can add their own desired middleware service.<next slide>
• #17: So, once the Gear is fully configured and Cartridges are installed, the Developer can then begin coding. As code is completed, the Developer pushes the code to OpenShift via the Git protocol. Git is a popular Source Code Control system used in the Open Source development world. A Git repository is created in the Gear and the Developer uses the Git “Push” command, or the IDE, to push the latest code into the repository over an SSH encrypted channel using the Git protocol.Depending on the programming language, once the code is pushed, the application will show the updates immediately. This accelerates the Application Development Lifecycle by providing immediate feedback on application changes.<next slide>
• #18: The advances that OpenShift provides in the automation of both the Application Development Lifecycle and the management and hosting of applications allow OpenShift help IT organizations take a step in the direction of implementing the IT Factory business model in order to increase efficiency and velocity. OpenShift becomes the Assembly Line for IT Services and Applications.<Next slide>