In order to start with this article, I first had to define what the DevOps is. According to the Wikipedia:
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.
The truth is, nobody probably has the same definition of this term, and by extension, it is hard to understand something that doesn’t have common definition.
What the term DevOps means to me?
I would broadly define it as a process and set of practices used within software development industry in order to streamline the software delivery.
As Wikipedia later on notes, it is also often mentioned in the same paragraph, if not sentence, with Agile methodologies. Going into that is way beyond the scope of what I want to say in this article though. So, perhaps, next time.
Right, DevOps. Let’s see how software gets envisioned, built and delivered.
Story time
In the beginning there was the Word… there was the need to solve some issue, to bring some added value to the business, or to scratch the itch if you wish. Thus, the business side of things decided it was time to develop some piece of software in order to solve the real-world problem they were having.
Business has some broad idea what the piece of software should do, and what issues it is attempting to solve but what it doesn’t have is the knowledge on how to implement the solution. So this is the step where company either already has some in-house development team, or hires someone to implement the thing for them.
Development of the software starts, gets demoed and the crowd goes wiiiiiiild. Everybody likes it cause the software engineering team did the magnificent job and the software is accepted.
Now, this particular piece of software is some kind of the web application, has multiple components, from workers performing asynchronous tasks, web UI used by the business, and it even sends out periodic emails.
On the other hand, application is written in the supreme monolithic way, all components are crammed together in single piece of deliverable because “that’s how we have always done it”. Naturally, best available components are also chosen during the development process, like COBOL, every obscure NPM package one can find on the internet. Build process is also a breeze where each build takes only 4 hours to complete, and deployment is not the dev problem anyways. To run this thing, it only costs one kidney a month and perhaps some mediocre Porsche or S Class Mercedes-Benz. :-)
Obviously this can’t be just used on a laptop where it was developed and demoed on, so it has to be deployed to some place where everybody from the business side of things can access it and use it.
Now this is traditionally part where sysadmin team would get involved, and the code is by the old standards “thrown over the wall” from the development team to the operations team.
From this point on, sysadmins require many things, like some basic documentation, requirements for the application, some servers where they can deploy the thing, domain name, SSL certificate, some email service or configure servers themselves, and perhaps many more things. They also have to magically lower the cost of the infrastructure and make the darn thing scale as needed.
They solve those things like magic, with a snap of the finger, or push of the big red button with the label “do the needful” they usually have laying somewhere on their desk.
So the app is now deployed, working reliably, and hosting costs are a fraction of a penny. But then, one day, business decides that it might be useful to add one small thing to the app, and perhaps change a thing or two here and there, and we repeat this exercise once again.
Back to the point
Obviously, this story above is quite nasty one and it involves much pain and suffering, which unsuspecting reader might not notice, but trust me, there’s plenty of that.
So how to solve this problem? Well, with “DevOps” obviously.
In order to provide optimal solution to the business, both Development team and Operations team have to cooperate together on many fronts. They have many areas in which they overlap and should iterate on finding perfect solution together. For example:
- Brainstorm on how to architect the application, to split it into smaller independent components (also known as micro-services) in order to provide better scaling capabilities and easier deployment and distribution
- They also have to together figure out how to exactly scale the application, which parameters to use for scaling (request rate, memory, cpu…) and preferably also throw load test to test their scaling and see the bottlenecks, at minimum before pushing to production
- Choose best readily-available components. For example, for mailing service one might not opt-in to configure their own email service which also requires some servers, costs in both money and time from the operations team, when they could easily use very reliable SaaS like SendGrid, Mailgun, etc.
- They also have to keep in mind how the solution they choose relate to the TCO at the end. Cut cost where possible WITHOUT CHOOSING POOR SOLUTIONS.
- Automating process of the application build, lower the time required to perform the build and also automate the deployment process.
- And the work doesn’t stop there, they always need to work on providing better business value.
You cleverly noticed that work “together”. Yes, developers and operations have to work together to provide the business value. At the end of the day, business is the one providing their salaries, as we don’t all work for rainbows and ponies.
In the DevOps world there should be no place for “that’s not my problem”, instead, we should approach every problem with something like “what can I do to enable you, and to help you resolve this thing you’re stuck on”.
At the end of the day, sysadmins will still do the sysadmin/infrastructure part while developers will code, cause that’s what they both do the best. On the topic of architecture and all those points listed above, they all have something to say.
Side-notes:
- I’m aware that not all software gets created to scratch the itch, sometimes it gets created before we even know the itch exists
- Saying “real-world problem” in this day and age is a bit stupid
- Developing piece of software is not trivial thing to do but going in-depth about the process is beyond the scope of this article
- DevOps process is applicable to more things, outside of realm of software development (Beyond Dev and Ops)