Rust Never Sleeps: How to Keep Your Application Platform Current

One of the most maddening aspects of being a software developer, and specifically a Java software developer, is the constant task of ensuring your application platform is up to date so that your application is not exposed to security or other defect vulnerabilities. It is challenging enough to ensure your code meets the customer requirements and is maintainable by different resources by ever-decreasing timelines over the course of its life. With constant demands to add features and functionality to ensure your application is compelling compared to its competitors, the platform version configuration management  is often overlooked by the development. The focus on the health of the platform also slips when the application is in 'maintenance mode' and its age or importance in the organization does not warrant the investment need to upgrade and test the ageing platform. Why should they be... its Operations' problem now! For active applications, most lead developers cross their collective fingers that no vulnerabilities adversely impacts their application as they work with Product Owners to prioritize their backlog of tasks/user stories/etc.  It is difficult enough to ensure all developer environments are standardized let alone the downstream environments like Test, Staging, Load, etc. up to and including Production.

I'm sure that most developers are not very vocal as to the risk of not keeping pace with their components of their application platform as their Operations counterparts are with operating system, storage, network, and other peripheral software versioning. However, the impact of de-prioritizing platform upgrades and/or ignoring the risks incurred by not moving all pieces of your application in a coordinated fashion is devastating. If this technical debt builds beyond several major versions, the application (regardless of its merits and functional importance to the organization) is looked upon as unreliable and is targeted for re-factoring or complete overhaul. The costs of the complete rewrite is never compared to simply investing a small portions of the development and operation teams’ efforts to keep up with the latest stable platform versions. In the public sector, these rewrite costs are amplified by the acquisition activities required to ensure proper selection of vendors to complete the work and the governance required to ensure all requirements and deadlines are met.

This brings me to the recent “end of life” of Java 7 and if you have not upgraded to Java 8 yet, you probably are already aware that any applications built on Java 7 will not have the support to detect security or defect vulnerabilities nor, more importantly, notifications of these vulnerabilities you need to take corrective action. This leaves your applications open to attacks and risks, not to mention your application development reputation. Conversely, had minimal steps been taken in a continuous improvement culture, weaving in mandatory upgrades to all system components should be standard operating procedure and not cause fire fights in the first quarter of this year to hurriedly change, test, repair, test, deploy while leaving all features and/or enhancements on hold. Let’s not mention the orphans left behind because there are not enough funds to invest in such activities. This brings the second wave of hidden effort that is requiring Operations to maintain several versions of Java if more than one application runs on a server. Sooner or later as a lead software developer, a System Admin will tap you on the shoulder and want to have a discussion.

I must admit I'm guilty of all the infractions above and have been burned by looking at the horizon for application feature functionality and enhancements while the underlying platform decayed. It often took heroics by some of my senior developers to take them offline of the team functions to focus on platform upgrades when it simply became too much risk or the discussion with Operations became too personally humiliating. I then saw the light and regardless of what development approach I employed (waterfall or Agile), I began weaving in tasks to releases that addressed operational value along with functional value. A gentle push-back on the business unit requests to prioritize operational tasks and an education on the risks of not doing so was also needed to communicate the concept of blowing a hole in one side of the same boat does no good for the crew regardless of whose side the hole is on. This fostered good relationships with our Operations teams as we had their interest at heart as well as the business needs which led to “all for one” attitude which is the essence of the DevOps principle.

Given the amount of skinned knees I endured, I'm very excited about the advent of the Platform-as-a-Service (PaaS) as a service model as it allows an organization to standardize development platforms across the application life cycle and allows Operations to be “involved” from the start of development as opposed to being impacted at the end (production deployment) and living with the debt incurred by others. I have implemented and used an enterprise PaaS, Red Hat's OpenShift Enterprise (OSE), and am very impressed by its capabilities and how it standardizes a developer and operational environment.  The wide selection of the choices of language frameworks does not hinder a developer from selecting a framework that meets their needs once they know the application requirements.  Even in the rare case that project requirements dictate a specific framework and application platform, a developer can create and install a Do It Yourself (DIY) cartridge to pull required software components/dependencies. Having said that, I cannot emphasis enough the benefit of having consistent components across your enterprise so that shadow IT activities start to creep into your processes. The pockets of "oh they're different" or "he/she really knows what he/she's doing and we trust her" only create software drift and in the long run cause a loss of productivity of someone's team... hopefully not yours.  This is counter to the DevOps culture organizations are seeking.

When it comes to application software version drift, Operations can heavily influence the priority of software versions by communicating upgrades to the platform to the development teams. Upgrade effort can be distributed to the PaaS Operations team who will have the task of deploying new versions of operating systems, application platforms, databases, etc. and with good continuous integration workflows in place, any impacts to these changes will be realized upon the next application build and testing cycle as opposed to separate development team's constraints. Moreover, the vendors of the PaaS have the onus of ensuring vulnerabilities and upgrades are monitored and implemented based on priority thus offloading effort in an even more distributed fashion. If I were to be assigned a project to deliver today and not being biased on any specific language constraints, I would lobby my business unit to invest in a PaaS. With PaaS I would have options of various languages and would select one once I knew the requirements and have the comfort of knowing the entire platform I develop within will have the same versions of the application components as the platform it will be deployed to production. My ability to collaborate with Operations staff to prepare a deployment environment will already be solved, or at least on the opponent's one yard line.

Since the PaaS, specifically the cartridges in OSE, are provided for and maintained by the vendor, Operations can be leveraged to assist development with ensuring proper versions are maintained for all application stacks residing in the PaaS. In order to protect yourself from end of life support threats in the future, consider implementing a PaaS for new applications with a vigorous continuous integration work flow. For existing applications, migrate them to a PaaS like OSE so that the versioning gotcha debt is distributed across your IT organization and the attention is not always given to the flashiest project, or application, of the moment. The analogy of “blowing a hole in the other side of the boat” is still valid when your resources have to be diverted to the legacy system that just sprung a production leak due to inattention.