Prolong the working life of your cloud applications
Plan for the future
Application lifecycle management (ALM) is a critical foundational concept. We haven't always called it this – and no doubt there will be new names as marketing requires them – but the idea has been there all along.
In the past few years we have started to formalise processes around this concept, just in time for the cloud to come along and change everything.
ALM is simple to understand and fiendishly complex to implement. The concept is that all applications have a lifespan: they are conceived, created, maintained and then retired.
Maintenance includes both development and operational issues such as patching, feature additions, versioning and scaling.
From one viewpoint, this is the definition of our industry. People don't buy computers just for the sake of it; they buy them because the applications you can run on them serve a definable need.
It is the details that matter. ALM treats many elements as black boxes. This is where the operations or development guys wave their magic wands and something occurs.
With the rapid uptake of cloud computing and the rise of the DevOps movement, the shape of the pretty charts and the responsibility arrows are changing.
Not so long ago, most developers had things pretty easy. They had enormous power to dictate the environments their applications ran in, and they didn’t have that many environments to worry about.
If you were writing end-user applications you had a choice of Windows or Apple – and it was considered acceptable simply to ignore Apple.
Server-side stuff was much more difficult. There were a dozen different varieties of Unix and Linux that mattered, and each did things just differently enough to make installing and running your application a bit of a pig.
Masters of the universe
But in this era of developer supremacy, it was also considered acceptable simply to ignore petty details such as ease of installation, and point the finger of blame at operations. Developers defined the environment the application was to run in, and the job of operations was to make it do so.
This generated situations that proved to be painful whenever upgrades or platform changes were called for. As the internet became a tool of business and leisure the problems could only intensify.
The emergence of the web roughly corresponded with some big changes in platforms. Windows became a force within the IT industry. The main Unix platforms started to consolidate while Linux and BSD took off. Apple entered a dark place and virtually every other platform went deeply niche or evaporated altogether.
The web emerged as an application delivery mechanism. Standards were created, abandoned, extended, abused and ignored. Browser development stalled for years while new security bugs threatened everything on the internet – which turned out to be a lot more than should ever have been allowed near it.
Hardware changes hit the industry like a whirlwind. Application developers saw their user base at the beginning of their application's lifespan drinking the internet through a 14.4kbps dial-up straw; by the end they were connected to it 24/7 through a 1.5Mbps broadband link and an 11Mbps Wi-Fi connection.
Operations departments responded by establishing rigid refresh cycles in the hope of providing some form of stability to developers. Management kept cutting back the budgets and developers kept pushing back the refresh cycle dates.
Stop the world
As we entered the new century, something had to give. Developers couldn't possibly address such rapid diversity, and operations teams were stretched to the limit as they tried to find a balance between securing systems, updating them to meet user demand and keeping badly maintained applications running.
In the early 2000s Microsoft merged its consumer and business Windows lines into a single offering. Hardware changes became less radical and more incremental.
The standards wars of the late 90s were mostly a bitter memory. Even the software used for common tasks was being supplied by at most three key players per category. By now even the most bureaucratic management machine was becoming aware of how vital IT was to the successful functioning of a business.
Unfortunately this came about because the preceding 10 years had seen a shocking string of blunders and calamities which meant that the nerds had to be brought to heel.
It is here that ALM started to enter the lexicon of our industry. Bickering operations and development fiefdoms were no longer tolerated. Finger pointing wasn't solving problems and management frameworks emerged to deal with the rapid pace of change in IT.
Peace and harmony
Now we have cloud services. You can roll your own, rent resources from a local service provider or go with one of the heavy-hitter cloud providers.
Developers don't need to fight with operations to get a new environment spun up to work in. They can fill out a form on a web page and have a virtual machine configured to their specifications in minutes.
The operations team does not need to fight with developers to scale applications. New virtual machines can be spun up as demands increase and spun down when they are not needed.
Patches and operating system changes can be tested easily and well in advance of mainstream deployments. Workloads can be moved from on-premises to service provider to public cloud and back again. A nirvana of chaos avoidance is waiting for all, if only we'd embrace it!
Such, at least, is the marketing hullabaloo. Some of it – in fact a lot of it – is actually pretty accurate. If you want to see a bunch of people who can do amazing things with cloud services go to PuppetConf. These people have this stuff in the bag.
Sponsored: Benefits from the lessons learned in HPC