I’m pretty sure that if Dante was in IT, there would be at least one stage of hell devoted to getting developers and operations to work together well. Horror stories abound. One of my favorite recent ones was about a company where the operations team wouldn’t let the developers surface any UI that they could access to manage their applications. The developers decided that they could get around this by building an API and then having a UI locally that they could use which was not in the realm of the operations team. Which, was a ridiculous waste of time and effort.
Granted not all companies are like this, but you can certainly understand why a division has arisen between the two groups. Developers are on the hook to deliver new functionality. Operations are on the hook to create a stable, secure, well run environment. Developers push change. Operations resist.
On top of this, you have completely different sets of skills and knowledge, creating a gap between the two roles. In his, “What is this Devops Thing Anyway?” post, Stephon Nelson-Smith characterizes it like this:
The problem is that it’s typically the sysadmins who are responsible for getting the software out live – but often they don’t know, trust, like, or even work in the same city as the developers. How on earth are we expected to deliver good software that way?
This sentiment has given risen to the devops movement. For those of you who are not familiar with the term devops, it’s a term that’s been created to refer to the overlapping area between developers and operations and the need to have improved collaboration and agility. There isn’t one set of skills that’s key to devops, devops people break down boundaries and focus on shipping great software – from the code to the operations. They can write code and they can understand how to manage systems.
When we look at the world of Tomcat, one can clearly see why we need both improved collaboration and agility.
On the collaboration side, often times, the operations team has complete control. Leaving everyone else with nothing. What if you’re on the dev team and you want read only access to some monitoring metrics in your production application? This causes problems for an ops person too. What if it’s the weekend and you want to give someone permission to bounce a server? Or what if you want to enable one person to do deployment management and another server management? Or what if you want to enable developers to use the same methods for deployment in QA as are used in Production? We need a way for developers and operations teams to work more effectively together.
There is also the need for increased agility. At a high level it is of course very important to be able to respond quickly to the needs of the business. But, I’m not talking about that. There is an equally important, more technical aspect to this. When changes come in big, infrequent releases, the risk of change and the fear of breakage are very big. When we reduce the scope and create frequent, continuous, automated releases, we greatly reduce the possibility of down time. This is why in the devops world, there is a big push toward continuous and automated deployments. Out of the box Tomcat has very few facilities to help in this area. You can not automate deployments, roll back when problems go wrong, deploy builds from your build server and easily transition between development, staging, and production environments. All of which are critical aspects to increasing agility and decreasing the risk of change.
I’ll talk more in depth about how Tcat addresses these two issues in my next two posts.
