In the old days (all you kids, get off my lawn!) moving an application from any environment to production was, well, quite the production. There was the scheduling, the change control meetings, the coordinate and the sign offs -- oh the sign offs. Once all that was complete, there was the Saturday night (because maintenance windows only happen on Saturday nights, don't you know?) move that required everyone responsible (across all impacted teams) be present and ready to test. If you were lucky, there might be pizza. The reason these events were such a production was that they happened rarely. If you moved an application into production more than once a year, you were doing something wrong. Today, the thought is much the opposite. If you aren't moving applications into production frequently, you're stagnating and losing your competitive edge. The thing is, moving an application once a year (or less) into production means a lot of change to the environment and, possibly, to adjacent applications and infrastructure. Today's release cycles aren't so much disruptive as they are accretive, impacting only the application itself -- not adjacent services and infrastructure. It's this type of release cycle -- frequent incremental updates to the application but not the environment -- where DevOps really improves operations through automation. Assuming everything but the application itself is the same, the processes used to move it into production the first time should be the same processes needed to do it the next. That makes them a prime target for automation. The value isn't just in ensuring consistent, predictable and repeatable (CPR) deployments (though that's the primary objective). It's also the time freed up by eliminating the need to manually repeat tedious processes every few days (weeks or even months). Ashish Kuthiala, director of marketing at development services provider Electric Cloud, explained it this way:

"If we built cars today the way we build software, all the cars would be hand-built and each would be different. That's great if you're building a Rolls-Royce and can sell it for $300,000. However, this prevents you from building cars in volume that you can sell for $20,000 and work really well. Today, every car manufacturer has implemented automation for their repetitive manufacturing processes. Only the very critical processes that can only be done by humans are actually done by humans. The same level of automation is needed today for repetitive, non-value added processes in software development. This would allow engineers to focus on the work that they are qualified and hired to do. Imagine freeing up 25 percent of your engineering team's time from tasks that can be automated – that would be like adding 25 percent more engineers – in effect, a real force enhancer."

That same principle can -- and should -- be applied to deployment processes. That is, after all, the basic concept behind DevOps: the application of development methodologies to operations. The cloud lends itself naturally to DevOps in that it's heavily driven by APIs and frameworks that can easily be incorporated into automated, DevOps processes. In fact, one could argue (and I may have in the past) that without the automation, the cloud doesn't actually exist. It's the API-driven, self-service provisioning that makes the cloud the cloud, so DevOps is a natural fit where clouds (private or public) are involved. That means a good way to succeed or move into a position in the cloud is to polish your scripting and API-targeting skills. Being able to demonstrate experience with public cloud provider APIs or private cloud management frameworks will go a long way toward building a portfolio of cloud skills that will make you more attractive to prospective (and current) employers.