In an early incarnation of my working life, I worked for a while in a nightclub serving food. Most nights the amount of food that needed to be cooked was minimal, sometimes it was only staff food. A lot of the time there wasn't actually much work to do, so I'd spend most of the evenings stood in my chef whites and chequered trousers surveying the dance floor.
The chequered trousers acted as a magnet, so I'd frequently get accosted and experience some of the more enjoyable benefits of spending most evenings working in a club. I had a manager at the time who was quite a friendly chap and he’d habitually wander around surveying the workers and the clubbers. Coming past and noticing me on the boundary of my diner area, he’d grumble that the kitchen wasn't absolutely spotless. My usual retort was that I could clean the kitchen at any point in the evening. He would then usually encourage me to get it over and done with, and then he'd let me be free.
People tended to become more interesting to observe the later it got, so I soon realised that time spent enjoying the latter part of the evening was much better than time spent enjoying the first part. As a result, I got the cleaning down to a fine art, learning to clean as quickly as possible and even starting to clean whilst I cooked.
This manager's stance has stayed with me throughout my career and it seems to keep people happy. As long as all of the work is done, the pressure is off. If you can finish a day’s work within a few hours of starting, you are free for the rest of the day to do more interesting things.
Over time, this manager's viewpoint has morphed and grown with me. Over various jobs, I found that I could get more work done by automating things.
Initially, this started off as stringing a few commands together and repeating the commands on demand. Over time, the level of automation grew and the complexity of the task at hand grew. So instead of stopping, killing and restarting a Java server, this grew into handling the full lifecycle of virtual machines (create, update, delete), and then grew from there into handling the automation of environments.
Things then seemed to virtually stagnate for a while. Sure, the process of the automation got better, so things improved from hobbled-together shell scripts to configuration management tools but in general, things didn't move much. With each new job, the process would be more or less the same: automate environment creation and tie this into a CI/CD (Continuous Integration/Continuous Delivery/Deployment) pipeline. Each one was virtually a custom PaaS (Platform as a Service) with a CI/CD process bolted on. As each job used different components, each job meant a new way of doing the same thing. Some of the ideas could be taken along, but the nitty-gritty bits couldn't.
Recently, I discovered Cloud Foundry. To say it was a revelation is an understatement – I'd discovered a product that meant I would no longer have to build custom PaaS-type solutions. No longer did I have to spend months of a project just building the underlying platform automation before the company could be let loose to embrace continuous integration, delivery and deployment.
Of course, there was some effort involved in creating the automation for deployment of Cloud Foundry itself and its underlying infrastructure (AWS, VMware, etc.), but once that was completed I could turn up to a new job and have a fully working PaaS within hours. Within a day, I could have the basics of a CI/CD pipeline in place.
If everyone in the country who wanted to drive a car had to first build their own road, the country would be covered in roads and there'd be very little driving going on as people would be road-building. If we extend this idea to trains, then we'd end up with different types of tracks and the chance of one train being able to use someone else’s tracks would be minimal. In fact, this happened – the initial boom in trains caused a range of different track types, but over time people realised the folly and standardised to one type of track*, which then meant different companies’ trains could be run on different companies’ tracks; this then meant you could own a train without having to build the tracks it would run on.
Cloud Foundry is like the train tracks or the roads, it provides the underlying surface/platform for more interesting things to happen.
Cloud Foundry isn't the entire solution. Having a PaaS just takes away the boring, mundane parts. Most companies aren't DevOps shops, they don't earn money from DevOps itself, they can't sell their DevOps solution, so each company that spends money and time building a custom PaaS is doing something outside of their core business. Once a PaaS is in place, a company can concentrate on doing something that makes them money or, in the case of non-money-making organisations, provides a service.
If a company can embrace continuous delivery/deployment, then the time from wanting a feature to launching the feature can be greatly reduced. This can be a game-changer. Imagine the ability to have an idea in the morning, code it in the afternoon and have the feature live in the evening. Imagine the ability to have an event and being able to deploy new features, or tuning, whilst that event is happening. Imagine being able to increase the capacity of your systems within a few minutes.
DevOps is all about being lazy and automating things. The more things can be automated, the more time you have to do other, more interesting things. Cloud Foundry gives you that automation and empowers developers to concentrate on their application without having to worry about the underlying deployment. You give Cloud Foundry your application and it gives you back the ability to be lazy and/or do more important things.
You can find out here more about IndigoBlue's DevOps+ practice and how it can help your organisation.
* well at least most countries did, some still have a range and lots of countries differ from other countries.