From IT/Ops to DevOps
With the move away from having dedicated, in-house Information Technology and Operations (IT/Ops) processes in favor of cloud computing comes the rise of DevOps. You can think of DevOps as a mashup between engineering and IT/Ops. Despite its relatively new status in the tech world, there have been many changes in its landscape. This article will cover some of those changes and what they mean for those who produce apps and sites today.
As recently as ten years ago, IT/Ops owned and controlled nearly 100% of the infrastructure required for running an app or a website. They were essentially the gatekeepers to all things hardware, which ran the code produced by the engineering team. Everything was managed in-house, and third party functionality, features, and widgets were a rarity.
However, as the software development process sped up and engineers started shipping code early and often, traditional IT/Ops practices evolved alongside, becoming what is now known as DevOps. But, before we get ahead of ourselves, what were some of the milestones we saw in the process of growing from IT/Ops to DevOps?
Software used to be developed using what is now known as the waterfall development model. Generally, it is what you think of with regards to traditional software engineering. Every three to twelve months, companies would ship one monolithic release that had been in progress for some time. The process included several phases, each with a dedicated purpose. There would eventually be some iteration between phases, such as development and QA. However, this process was sequential and required waiting time as each phase completed its tasks. It was in this environment where traditional IT/Ops came about–like everything else, it was its own distinct team with specific responsibilities.
Over time, the software development process sped up, and Agile began to gain popularity. With the Agile methodology, teams began to break down an app into smaller features to shorten development time so that they could ship things faster and more often. Rather than shipping huge releases every three to twelve months, engineers now ship every two to four weeks. This is a direct result of cross-functional teams tackling smaller problems together.
In addition, dedicated teams began evolving into cross-functional teams, since the short turnaround times required the collaboration of multiple groups in order to meet deadlines. At this point, we begin to see a merging of teams and a blurring of the division of tasks/responsibilities.
Today, the typical developer has access to a host of options when it comes to choosing what tools he or she uses to support a site or app. With the rise in cloud infrastructure providers, developers can mix and match options, change vendors as needs change, and generally speaking, isn’t limited by hardware in terms of what can be done. While all of this sounds complicated, the process of making these changes (which can be completed with an API call or a command line program) is simple, reducing an engineer’s dependence on a traditional IT/Ops team. Essentially, infrastructure, including its acquisition and maintenance, belongs to a third party, instead of an in-house team, and the developer assumes the responsibilities once belonging to IT/Ops. This process has led to the rise of what’s now called DevOps.
What does this mean for today’s developer?
Rather than focusing exclusively on crafting quality code, today’s developer assumes responsibility for many more tasks, including those related to infrastructure. Though there are many DevOps tools aimed at simplifying this process, these changes means that developers have to worry about many things that were the responsibility of others. As such, it becomes very important that developers implement a plan for monitoring the components that make up his stack, both in terms of software and hardware.
For information on how Rigor can help you monitor your technology stacks,