How DevOps concepts eluted from cloud computing and service platforms
The popularity of DevOps can be traced back to the emergence of cloud computing. As programmers began scripting their environments, the line between dev and ops began to blur.
This is part one in a three-part series on the evolution and history of DevOps.
DevOps did not arise from the visions of a prophet. Conversely, the emergence of the DevOps movement was an inevitable result of technological advancements from a variety of different sectors in the software development industry that all came together at approximately the same time. For the uninitiated, many DevOps concepts seem new, but the historic forces that have made DevOps processes a modern-day reality are familiar to all IT professionals.
DevOps would have never happened if it wasn't for the cloud. If cloud computing and service-based platforms never took hold, the relationship between developers and the operations team would look the exactly as it did 20 years ago. One of the most important DevOps concepts is the ability to automate processes and script away manual interactions with various operations tasks. That idea is baked right in to the name itself, as a key DevOps concept is that ops should be controlled as often as possible through development-based processes, such as writing a script or coding a cron job.
Cloud computing allows for DevOps concepts
The thing that made cloud computing platforms, such as AWS or Microsoft Azure, so ripe for exploitation by the DevOps world was that all interactions could now be accomplished programmatically. If you wanted to allocate more processing power to an application running in the cloud, you didn't have to call up a help desk and make your request through a call center employee. All operational tasks can be managed with either online administration tools or relatively easy-to-write scripts. This delighted developers, as the ability to programmatically interact with servers and processors brought the domain of the operations team into their world.
With a highly scriptable, cloud-based platform, a software developer who needs to test an application -- one that needs a new Java Platform, Enterprise Edition (Java EE) application server provisioned and configured -- can easily write a program to connect to AWS and spin up a new Elastic Compute Cloud (EC2) instance. That programmatically allocated resource can test the application and then spin down when the test is complete.
With traditional data centers being run by an in-house operations team, just getting a Java EE server allocated and configured might take days. The developer and the ops team would have to coordinate and get management sign-offs, and a flurry of emails would likely fly back and forth between the dev and ops teams about how the server should be configured. Even the most committed operations and development teams can cross wires and build a misconfigured server. With the cloud and the ability for developers to programmatically interact with what was historically the realm of operations, the process becomes incredibly streamlined.
Dev and ops clash: It's a script-off
None of this seems particularly earth-shattering in 2018, but imagine going back to 2008 when technologies like Amazon Simple Database Service or EC2 were first released. Ops teams were supposed to spin up servers, schedule load tests and allocate resources. But with cloud computing technologies, a software developer with a basic knowledge of scripting and access to the AWS account could do all of it alone. As the cloud took hold, software developers began to elbow their way into the domain of operations, and before the term was even coined, DevOps concepts began to take hold.
Of course, with a long history of owning the keys to all computational resources, the operations team didn't always look kindly at the development team's enthusiasm for allocating its own resources. There were, no doubt, a few wrists slapped as developers moved in on tasks that were historically the domain of operations. Meanwhile, members of the operations team discovered on their own how they could automate an otherwise manual task using the cloud. That way, when a developer sent an email asking for a new server instance, all the operations team would have to do is run a simple script.
While developers wrote code to automate the allocation of runtime resources, the operations team started to use development tools. Operations teams installed Eclipse or NetBeans on workstations to write scripts, and they set up source code repositories in Git in order to store and version their Groovy code. The line between the operations team and the development team blurred, and cloud computing was a big reason for it.
