Druid Getafix’s magic potion transforms skinny Astrix into a superhuman within seconds. But is it enough to fight against powerful Romans? The simple answer is “No!”. Most importantly Astrix has a brilliant brain on top of his shoulders to come up with new ways of attacking and defending.
Same as in IT industry, throwing money into IT service delivery process was not able to solve the problems we had. In fact, it made some of the problems worse.
What are the common challenges in IT service delivery? Inability to produce high quality and timely software, nail biting production incidents, failures in meeting ever-changing customer requirements and unsuccessful releases are only a few of them.
Agile was the first step
Over time IT has evolved into a necessity from a luxury. So the need of demolishing these challenges has become number one priority.
Agile is a great answer for most of the IT service delivery challenges. Agile methodologies like rapid delivery of working software, co-location, simplicity, self organizing teams, Test driven development are used in almost all of the successful modern organizations. Yet we couldn’t achieve the quality which we were expecting. Some of the underlying core challenges were still existing and pulling the hair out of CIOs, CEOs. Business was not totally happy.
Why we couldn’t demolish some of the challenges with “Agile” itself? Which is something that needs to be carefully analyzed.
“IT service delivery” or more accurately “IT as a service” is comprised of four phases. Namely design, development, Release and operation/maintenance. Agile was an only solution for development and part of design and maintenance phases. But we didn’t have a solution for challenges in other phases. Although Related, But in a different context, Agile was a great solution for Dev and QA. But operations left out and they had their own problems and solutions.
Fear of change and responsibility dilemma
Operation people like App, Network, DBA engineers were not ready to continuously change the code in production environments or to introduce new features, Because they were feared of inevitable truth which they believed in. I.e. “All the releases will break the production”
On the other hand, with agile dev teams were kept creating small replaceable meaningful chunks of code and throwing them over the “ Berlin Wall of Dev and Ops”. But it was not a synchronized effort. Dev ownership was scoped and limited to creating code only. They were not responsible for neither how code is running and serving customers in production environment nor the production stability after they threw the code over the wall.
When there is a production incident, Dev was not keen on getting their hands dirty and jump in as it was someone else’s responsibility. They had lots of things in their backlog, which they tend to focus on.
On the other hand Operations teams were never engaged in the design and development phases of the products. Operations feedback was not sent to the design phase to improve the code and ops never involved in non functional requirement development. Agile teams were kept missing non functional requirements like instrumentation, monitoring, fault tolerance mechanisms, vendor interoperability, security… Etc.. As a result of that, technical debt increased over time. What happens when technical debt is increasing? It creates the vicious cycle of production instability.
Infrastructure Readiness
Meanwhile, infrastructure was not ready to support agile software development. Rigid infrastructure technologies and lack of human resources made this problem more and more challenging. For an example, let’s consider a new server provisioning request for a feature. When the requirement was picked up from the backlog scrum team starts working on building the new feature. But since there isn’t an Ops representation in the scrum team nobody is concerned about the time taken to provision servers,set up monitoring,setup network and other non functional requirements for the feature. When a scrum team is nearing the finish line they tend to worry about and start thinking about those NFRs. But rigid technologies and manual procedures don’t allow ops teams to create servers on the fly or setup network easily. Then the conflict begins. This is just a small example from practical world. Dev was ready to take the “IT as a service Challenges” with agile. But Ops was moving in a different way.
Emerging new culture
Because of such incidents, demand for collaborative culture between dev and ops was increasing and DevOps starting to create a paradigm shift in IT industry. DevOps is neither a tool nor a person. It is the modern IT culture and an outgrowth of agile which addresses the challenges in all phases of “IT as a service” when combined with agile/XP practices.
With DevOps and agile culture dev and Ops together responsible for the entire flow of IT service delivery. Transformation and adoption process of DevOps culture should be carefully planned and should happen gradually.
In the initial stages, it’s important to create the synchronization between dev and ops. Ops should start involving in early stages of product creation. Ops give their feedback in design stages and involve in non functional requirement development as well. Ideally Application engineers and DBAs should be part of the scrum team and their contribution should be calculated as part of the velocity of the team. Application engineer or site reliability engineer’s role is vital to DevOps culture. Some organizations tend to hire people for a role called DevOps engineer. My personal belief is DevOps is culture and not a role. Even Though they were specifically hired as DevOps engineers, DevOps is a culture which spans across all the employee’s in the organization.
Key Enablers of DevOps
Automation is a key driving factor in DevOps adoption. Automation enables rapid, seamless deployment of software. Modern “IT as service” providers are having multiple releases per day through appropriate automation. Some organizations release 30 to 50 times a day to the production environment. Automation leads us to continuous integration, continuous delivery and then to continuous deployment. The final goal of all automation is the continuous operation. In an ideal DevOps world, feature team should be able to automatically push the code upto production environment without any manual intervention and downtimes.
As mentioned earlier rigid infrastructure is the biggest bottleneck of the Continuous operation. As a solution to that, PaaS (Platform as a Service) and IaaS (Infrastructure as a Service) concepts gained the popularity and infrastructure provisioning has reached to a new dimension due to that. With the appropriate automation and cloud computing technologies, infrastructure provisioning has become seamless. Especially with the use of the A/B deployment mechanism, modern operation teams are equipped for DevOps transformation.
Sharing is very important in a true DevOps culture. Coding the software is merely a one activity in provisioning “IT as a service”. There is a lot more into it. Everyone understands the big picture is important in developing the DevOps culture. Also Everyone as a unit should be responsible for the entire flow of work while engaged in one or more actions to complete the flow. Developers getting alerts and reacting in the middle of the nights and operations involving in non functional development activities is a healthy example of sharing responsibilities. Most importantly What we need to understand is “DevOps is a culture which has its own set of values. If these values are not understood by everyone in the organization, DevOps can drive you to an endless maze.
DonColombo : Sanjeewa Alwis's blog 