Evolution of IT Operations from Scripting to DevOps to DevOps-as-service
Tags: devops, infrastructureascode
Published: 2022-06-20 20:31:37

---
title: Evolution of IT Operations from Scripting to DevOps to DevOps-as-service
published: true
date: 2018-11-29 17:10:00 UTC
tags: DevOps,InfrastructureasCode
canonical_url: https://duplocloud.com/blog/evolution-of-it-operations-from-scripting-to-devops-to-devops-as-service/
---

In this post we outline the evolution of infrastructure management from the days of late mainframe computing, then enterprise computing to Cloud computing today. By citing the details in this historical trend we make a case that the best way to serve applications is to give direct access of infrastructure to the developers with an abstraction which auto generates configuration based on developer needs. IT must build (or hire) a robot that serves the users. DevOps should focus on specialized use cases that the bot cannot serve. If developers need operators ever so often; the robot does not work.

> _the best way to serve applications is to give direct access of infrastructure to the developers …. build (or hire) a robot. If developers need IT ever so often; the bot does not work._

At the surface it seems IT requirements are the catalyst in the evolution of infrastructure technologies but the fundamental shift has been bought in due to developer productivity needs. IT serves at the will of developer productivity. No matter what is the security argument if they build a walled garden around infrastructure, developers will leave.

## **Enterprise Computing: IT operations with Scripting & CLI**

Late 90’s and early 2000 saw the sun set on main frame computing. PCs were common and companies were deploying software on-premise. They left mainframes for “productivity”.

Microsoft and Sun made great strides in enabling developers with .NET and Java respectively. Applications were getting fancier. On the infrastructure side VMware disrupted the industry with virtualization, Cisco with their networking and EMC with their storage technologies respectively. Microsoft’s monopoly with Windows strengthen by Active Directory. Over the years these infrastructure technologies became so complex that it became a niche skill. Now we had within IT, server admin, network admin, storage admin, system admins and DBAs. At the surface it was not lost to people that the purpose of the infrastructure was to ship software faster which in turn meant developers needed to be more productive. Ideally developers should have been enabled direct infrastructure access through an abstraction layer that automated the low level details. But instead the IT tightened control. They did evolve to use more and more of scripting tools like bash, power shell. They achieved further agility via chef and puppet. Then came the SAAS model for delivery of software and IT could no more keep pace. Developers left on-premise in hoards for the cloud. Thus came the era of “Cloud Computing”. Again the same reason “productivity”. .

> _A core reason for the demise of IT operations was also that none of the infrastructure companies focused on making infrastructure accessible to developers._

A core reason for the demise of IT operations was also that none of the infrastructure companies focused on making infrastructure accessible to developers. Recent Openstack VMware, EMC Cisco solutions were all too little too late.

## **Cloud Computing: DevOps Engineering with Infrastructure-as-code**

Cloud eliminated all aspects of physical infrastructure. Delivered Infrastructure-as-a-service at an exponential speed with significantly less complex implementation. While AWS started with IAAS, Microsoft in-fact started with PAAS which though proved ahead of its time and they course corrected to focus on IAAS. Nevertheless the vision was clear.

Silo disciplines of server, network and storage admins were eliminated all together. Infrastructure provisioning through code is the de-facto model and significantly faster than it’s predecessor.

> _While the core disruption was realized by the fundamental architecture of the cloud itself, the improvement in the operations tools has not been disruptive…. Infrastructure is still not not directly accessible to devs._

While the core disruption was realized by the fundamental architecture of the cloud itself, the improvement in the operations tool has not been disruptive. Terraform, cloud formation, chef and puppet are marginally better in this context. IAAS Cloud orchestrators on the other hand are focused on hybrid cloud by normalizing all clouds down to IAAS thus leaving out-of-scope hundreds of native cloud services like DynamoDB, SQS, SNS, Kinesis etc. Fundamentally all these infrastructure tools are not meant for the consumption of developers. New environments take days as against weeks; continuous delivery is a norm but that is limited to a static infrastructure where only application code (build) changes. For even the most efficient companies the Opex to Capex ratio is still about 1:1 for example if they spend a million dollar on AWS they would have six to ten Devops engineers. IT remains a big cost center.

## **Devops-as-a-Service with Bots**

We believe the fundamental change in the approach to IT will not come from companies whose core audience have been operators. It will be from cloud vendors or developers who have experienced the pain first hand.

The world is being increasingly being served by bots. They drive our cars, police our malls and parking lots. Is the idea of a bot for DevOps that far-fetched? An interesting fact is that to build a Devops bot we don’t even AI, DevOps is a use case where there are a finite set of inputs with a finite set of output. Computer science tells us this can achieved by a rules engine. In fact my experience tells me that most good DevOps teams are trying to build their own bot. Are their needs that unique for it to be developed everywhere?

> _Is the idea a bot for DevOps be that far-fetched? ….. to build a DevOps bot we don’t even need AI.. with a finite set of inputs and a finite set of outputs, computer science tells us this can achieved by a rules engine._

There will a few DevOps bots which will rule the use case, one set by cloud vendors and other by cloud agnostic vendors, versions of which will work for each cloud. Human IT with infrastructure-as-code will scale down to specialized use cases and play supervisory function.

With DuploCloud we hope to be the multi-cloud DevOps Bot. We are engineers who have been both in the fore front of public cloud on day 0 as well as developers who experienced the pain points first hand.

The post [Evolution of IT Operations from Scripting to DevOps to DevOps-as-service](https://duplocloud.com/blog/evolution-of-it-operations-from-scripting-to-devops-to-devops-as-service/) appeared first on [DuploCloud](https://duplocloud.com).