DevOps has been a hot topic for the last several years. I have always had a love/hate relationship with the term. Most argue it as all about team culture and collaboration. Vendors have done everything they can to latch their products onto the DevOps bandwagon. As you will read below, I have my own opinion about what is DevOps and what it should be.
DevOps first started as a movement around 2008. The goal of it was agile infrastructure. The movement has grown rapidly over the last several years. But how did we get here?
If you go back 10+ years, most enterprise applications were desktop applications. Shipping new software meant mailing CDs to your clients or downloading a new version. The transition from desktop to web (and mobile) applications in large enterprises have caused a massive growth of servers over the last 20 years. Now they have to provide the infrastructure to host these new web applications.
As part of this transition, businesses figured out that it was easy to ship new versions of code for web applications. This pressure created various agile development methodologies. It also created the necessity for tools like build servers and release automation. The entire way that most software is shipped has fundamentally changed in the last 20 years.
The rise of web applications and agile development are the real reason why DevOps became a movement. Let’s use this graph from TechBeacon as exhibit A for my argument. This chart shows agile picking up speed around 2008-2009. It became the virtual universal standard in 2014.
The massive growth of servers and the pressure of rapid change led to gridlock at many large IT enterprises. They simply could not keep up with the demand of the business and development teams. DevOps was an outcry that there had to be a better way.
IT simply could not do anything fast enough. Operations had to become more agile and enable development teams to ship code faster. Server environments had to be deployed faster. These were massive challenges in large organizations.
Smaller companies can also benefit from streamlining how they do software deployments, provision servers, etc. It helps everyone, not just large companies. I remember first using VMWare as a developer and thinking how amazing it was to quickly create a server. That was hugely helpful to me even working at a medium sized company.
Today, small companies and even teams within large companies are able to solve many of these problems by leveraging cloud computing. They can ship code whenever they want, spin up new servers on demand, and control their own destiny. They don’t have IT Operations in their way. To me, that is what DevOps is really all about: developers doing operations tasks for their own apps.
As a developer, nothing is more frustrating than working your tail off to then have to fight with IT operations to get a new server or deploy an application.
What every development team really wants is complete self-service. The goal is to remove every barrier possible to your development team. Give them the ability to ship code as fast as possible, while also giving them some guard rails to ensure they don’t do anything wrong.
Every development team needs 3 key abilities:
To me, the goal is really simple: self-service. I want my team to be able to do everything they need to do to write, ship and support their code.
I want my team to be able to deploy a build whenever they are confident that it is ready to ship.
I want them to monitor production to ensure everything goes smooth.
I want my team to be on the hook to find and fix production problems if there are any.
I want my team to get the 3 am text messages and phone calls when something goes wrong.
I want my development team to kick butt and take names. Or perhaps, write code and ship it fast.
I want my team to take ownership.
I want everyone else to get the hell out of the way.
If your company has a development team that creates software, I would argue that you should empower the team to take ownership. Give them all the access and tools that they need to have complete ownership of their success and failure of delivering a high-quality product. IT operations should help them achieve that goal.
Eliminating IT operations is not the goal. Every organization is different. I wrote an article a long time ago titled “Defining the Ops in DevOps.” It was about defining what I felt like operations teams should be doing versus development teams.
NoOps is not really a thing. We will always have IT operations. What we want is developers doing the operations tasks related to their own applications. We want them to take ownership. We want to remove any barriers that cause delays or excuses. DevOps is about improving velocity and quality.
I’m not advocating that your production data center should be the wild wild west. IT operations can still help enforce smart security policies. Tools, like Retrace, can help give developers the insights they need to troubleshoot application problems, without giving them administrator level access.
Software development is complex. Every organization has unique challenges that slow down the development process. The goal of DevOps is to improve that process and remove barriers.
At your company, culture or IT processes could be the biggest barrier. If you don’t let your developers deploy code to production and IT operations is a nightmare to deal with, then yes you have a culture and collaboration problem.
In other organizations, the barrier could be how long it takes to get new servers provisioned. The development team has decided that Redis can help improve their application. They got it all coded up and ready to go. If they can’t get the new servers for it deployed, that becomes a big barrier and holds up the release.
However, there are lots of potential barriers that can exist. I would argue that anything that prevents developers from writing, shipping and supporting their code is a barrier. You need to remove these barriers if you want your software development process to be more efficient.
I have talked to companies that don’t even allow their developers to access QA servers to look at log files or troubleshoot problems. This is clearly a barrier that slows down development.
The barriers are different in every company. It is not a universal problem.
With Visual Studio, I can right-click and deploy an app to Azure with a couple clicks. I can login to the Azure portal and my application monitoring tool to see how my app is performing. I have zero barriers preventing me from shipping and supporting my application. Does that make me a DevOps ninja? A junior developer can do this with no sysadmin knowledge. Cloud computing has eliminated a lot of barriers.
The development challenges that companies face are different. Facebook has tens of thousands of servers. The vast majority of business applications will never run on more than a few servers. They simply don’t have the scale of traffic. You need to figure out what barriers are slowing you down; they differ from Facebook’s.
Another good example could be QA. Perhaps your QA process slows down how fast you can do releases. That isn’t a typical DevOps sort of problem you hear about. No matter what is slowing you down, you need work on it.
If you want to ship code faster, you need to remove all the barriers from your development process that slows it down. Create a culture of self-service and let your development team own their apps.
I would argue that the goal of DevOps is NoOps. That doesn’t mean that nobody is doing operations stuff. It means that the development team is doing all of it for their apps. It means they are self-sufficient and take ownership. The developers are pushing code and are on call. Operations only assist if needed, instead of development only assisting if needed.
DevOps is a natural fit in the cloud. So many barriers that exist in normal data centers are gone. PaaS and application hosting features make it really simple to deploy your applications. It is the future and the way it should be. If you haven’t made it to the cloud yet, I would suggest trying to mimic the same sort of agility in your own data center.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to stackify@stackify.com
