Leveraging RHSCL for DevOps

As you certainly know, DevOps is all the rage these days. While DevOps is many things, some pure "buzz" and some legitimate, we aren't going to talk about all that. Instead, let's talk about one small piece of the problem, simplifying the consistency of deployment platforms.

Part of what has made DevOps, and, by extension, Continuous Deployment concepts possible has been the simplification, at least on some vectors, of the modern data center. Starting with virtualization, extending to configuration management and deployment (e.g. satellite and puppet), and finally, the advent of the hybrid cloud, operational functions have become much simpler for the layperson. However, ensuring that your development environment is the same as production is still not a completely solved problem.

Numerous methods and tools exist to try to simplify this problem (to many to reasonably name) many of which are great tools. However, they approach the problem from different perspectives which results in different tradeoffs. Unfortunately, what tradeoffs you can tolerate and which you can optimize for are still somewhat difficult to identify and accurately predict. The documentation and anecdotal user experiences of using these tools are also not great at articulating the tradeoffs that are being made. As the space in which these tools exist is so immature it would be impossible for the tools to accurately reflect all scenarios. The tools would also, probably, be inferior if the authors attempted to guess all possible use cases. As the space matures, we can expect clearer guidelines about which tool to use. However, this article is about hedging bets.

Let's say we (developers) agree with the operations folks to start using RHSCL for all our development. OK, that means that both teams have a known quantity to target for development and deployment. The RHSCL component installs are automatable using a number of tools (like the ones mentioned above) so the deployment in development and production are consistent and repeatable even if the ops and dev teams use different automation tools. The same hedge also holds true if a new tool is discovered to do a better job in either development or production as long as it can automate a simple install.

To further hedge our bets, we need to also incorporate a method of scaling into the public cloud (to enable the hybrid cloud concept). RHSCL components are also starting to become available in OpenShift, Red Hat's Platform-as-a-Service (PaaS). What does this mean? Well, if your application works on the ruby193, python27, or nodejs Software Collections, well, then they will also work on OpenShift.

Another side benefit of leveraging this model (developing against a software collection) also enables OS version independence that was discussed before.