Controlling application sprawl within your organization can be a daunting task - especially with today's constantly-evolving and ever-increasing proliferation of languages, frameworks, services, and data stores. IT Managers and operation teams must deal with the day-to-day realities and challenges of IT, as well as meet developers' demands for access to tooling that will help them produce, delivering reliable results to customers.

The rise of the Public PaaS (OpenShift Online included) has granted developers access to new levels of freedom when selecting a language, framework, and set of services, or data stores that are a 'best fit' for the task at hand. Sometimes, it can seem like a never-ending battle.

In the past, application sprawl was managed by enterprises by "standardizing" or "locking down" the range of languages and technologies that developers were allowed to utilize. This enabled IT operation teams to focus on specific of technologies that they could support and meet their compliance and uptime commitments.

Private PaaS delivers both Operational Control and Developer Self-Service

Prior to the emergence of Private PaaS offerings such as OpenShift, Operations and IT Managers wrangled with decisions about how to regulate and secure all the components of applications that they were charged with managing, scaling and guaranteeing uptime on. Private PaaS offers an compelling new way to control application sprawl within the enterprise without depriving developers of the on-demand self-service functionality they desire.

Roles & Responsiblities in a Private PaaS Ecosystem

There are developers, aka those who build the applications that add value to your organization, who enable your end-users (customers, employees, partners) to engage and consume your company's products and services. These are very same developers who have tasted the freedom of a Public PaaS that allowed them to deploy on-demand any version of any language, use the flavor-of-the-month framework, on top of the latest data store without any thought as to whether or not anyone could support or maintain that application if they got hit by a bus. It also more than likely whatever code they wrote is sitting in a public github repo, with a readme.md file and very little commentary to describe it's intricacies and any hidden dependencies. All the things that make the compliance officers and risk managers in corporate IT offices shudder with despair.

And then, there are the gatekeepers, these come in all shapes and sizes: sysadmins, operation teams, IT managers, compliance officers, risk managers; all whom are constantly battling to mitigate risk, ensure uptime, scale, secure and manage the applications and services that enable their organizations to succeed.

With the OpenShift PaaS model, it is the PaaS Administrators aka Gatekeepers that choose the set of installed technology "cartridges" that are made available for developers to use.

Adding Building Blocks

OpenShift's application deployment methodology is based on a idea of composing the building blocks of the application to enable more granular control of the parts of the software components required for running the applications. OpenShift's extensibility model is based on the concept of 'cartridges' which break down the components of user's applications into re-usable building blocks. OpenShift cartridges provide the necessary command and control for the functionality of software that is running users' applications. OpenShift currently has many language cartridges (JBoss EAP, JBoss EWS, PHP, Ruby, Rails, etc.) as well as many DB cartridges (Postgres, Mysql, Mongo, etc.). Read more here

If the PaaS Adminstrator chooses not to install a particular cartridge at the initial deployment of the PaaS, they can do so later after careful vetting of the technology and consideration of the implications of adding that particular language, framework, service or data store based on their IT team's ability to ensure they can properly support that new technology. However, a cartridge must be installed before application developers can create applications that use it.

Upgrading Building Blocks

Command and control remains within the Operations team rather than in the hands of the developers thus ensuring that the technologies that are deployed into production environments are properly vetted and managed. The OpenShift runtime contains an upgrade system used to upgrade the cartridges in a gear to the latest available version. The oo-admin-upgrade command provides the CLI for the upgrade system and can be used to upgrade all gears in an OpenShift environment, all gears on a node, or a single gear. This command queries the openshift broker to determine the locations of the indicated gears to migrate and makes mcollective calls to trigger the upgrade for a gear. Read more here.

Developers get agility of self-service on-demand capabilities

With Private Paas deployments, developers are free to use any of the available cartridges in any manner they wish, composing applications using the cartridges that best suit their needs all with the same self-service, on-demand user experience they expect from a PaaS whether public or private. This is also a big win for the Operations teams as the developers' requests for compute resources is now automated in a secure, compliant manner that can easily be monitored and scoped to meet the business needs.

Freedom to explore new technologies

OpenShift has also includes the ability to enable a 'DIY' cartridge that provides a minimal, free-form scaffolding which leaves all details of the cartridge to the application developer and enables Online users to extend OpenShift's range on the fly. Read more here..

PaaS administrators can set up test and sandbox Private PaaS with the 'DIY' cartridge included and safely allow developers to test and vet all the new technologies without affecting production environments. Developers can also deploy OpenShift locally themselves via a VM running in Virtual Box and test out new technology on their own machines.

Then once the new technology is properly vetted and the compliance and risk managers have had their say, the new technology cartridge can be added to the production system by the PaaS administrator/Gatekeeper and made available to all the developer teams across the enterprise to add to their toolbox.

Note: Before writing your own cartridge, you should search the current list of Red Hat and OpenShift Community provided cartridges.

Conclusion

OpenShift's Private PaaS model enables the fine granular control of the building blocks of applications. OpenShift gives Operations the ability to upgrade and manage new versions of technologies & services without depriving developers of the self-service on-demand computing resources they crave and without causing IT compliance officers and risk managers nightmares.

Next Steps:

Categories

OpenShift Container Platform, Thought Leadership, OpenShift Online

< Back to the blog