I have had 2 talks about DevOps@Runtime (here and here), I’ve also been talking to people about the topic and I’ve promised to write a blog post about it, which I’m doing now. But before I can start with the Runtime, I have to talk a bit about DevOps in general and what it is. Therefore, in the prologue I will explain DevOps in a NutShell 😉
DevOps, which is obviously a combination of the words Development and Operations, is a relatively new movement which was sparked by system administrators in Europe in last two-three years, but finally got acceptance and contributors all over the world.
Wikipedia says about DevOps: “DevOps is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims at helping an organization rapidly produce software products and services”
Most people who consider themselves DevOps would argue that DevOps is hardly a development method, just like agile is not a method, but a mindset, that produced a whole lot of methods like Scrum or Kanban.
So what is this all about? The main question that DevOps is trying to solve is how to overcome the Wall of Confusion. But what is the Wall of Confusion? Well, among other actors, like product owners, quality managers, stakeholders, a very strong role in the software development process belongs to developers, who develop the software, which means adding new features and changing the software, and operations, who care for 24/7 operation for the application. So developers are struggling for change and operations is striving for stability. These two opposing interests lead us to the Wall of Confusion:
The two guys you just met are my heroes who will help me to explain DevOps to you. You can easily recognize them as heroes by their ninja-turtle-style headbands. As for colors, the black one is for the ops guys, because nearly all ops guys I know are wearing black shirts and many even black boots. The blue color for the developer symbolises his naivety when it comes to deployment and maintenance of his code. At least from the ops perspective. This leads naturally to the first problematic point of contact, the rollout of new software. It’s often thrown over the wall like this:
Naturally, this behavior leads to a high level of frustration for the ops guy, who receives something he can’t really deal with, because it may not fit in the infrastructure, violate security or other policies, or is simply unmaintainable 24/7. Thus the ops guy thinks that all developers are bunch of apes hitting the keys in random order. On the other hand, the developer thinks that all ops guys are like Mordac, the Preventor of IT Services. The only thing both guys have in common is their level of frustration:
Needless to say, the real problem here is the lack of communication. Operations should understand that developers don’t do things out of pure fun (ok, from time to time they do), but mostly because they have to. And they have to, because product owner wants new features, customers want new services, CEO wants better earnings and all the company staff needs money to pay for the huge amount of beer they consume while arguing.
More important, developers should understand that they aren’t done as soon as the app compiles, or has passed the test, or has been packed into the release artifact. No, the developer is done when the feature is live, and not a minute earlier. The communication to overcome the wall of confusion could go like that:
By communicating their needs (and fears), development and operation can start to work on the root of the problem – how to inflict change and preserve stability at the same time. The answer to this is question is very simple: automate:
By automating the process of live deployment and making it stress-free to deploy (and also to rollback) the software, one of the two points of friction between development and operations is solved. The other one – application management – will be handled in the next post. Automating is really really really easy. Actually, the only tool you need to automate the rollout of your software is the one you are using right now – your brain. Of course, some other tools can be helpful too, but the only thing really required is your brain and your will. The will to overcome the wall of confusion will decide if you’ll overcome it or not.
People are talking about all different kinds of tools like puppet or chef, and private/public clouds, virtualization, VMs on demand and whatnot. Those are all great tools which can help you to achieve the automation, save time, provide better testing, and so on. But only your devotion to the goal of automation will decide if you succeed or not.
One of the simplest toolchains for achieving automated deployment is maven + jenkins + bash. Of course, you can replace maven with gradle or ant, or whatever your build tool is. I think it’s safe to say that Jenkins is de-facto standard for build servers in all environments by now. I personally know people who build Java, Ruby, .NET, iOS, Android, C… and probably other applications on it. And good old bash is capable of a hell of a lot of things, don’t underestimate it. But you are free to write much cooler puppet modules and chef recipes of course 😉
For those who never automated a release process before, here’s the most simple way to get it automated.
So, that’s the prologue. Go into the problem zone between development and operations, make them talk to each other, make them understand each others’ needs. If you are a developer or operator, listen to the other side. Understand them. If releasing software is problematic, do it often. Automate it.
One last word:
DevOps is to deployment what agile is to software development.
It’s actually not my quote, but I can’t find the source anymore. However, it is true. The agile software development had the goal to overcome the wall between people creating products (product managers, concepters, or whatever they were called) and the developers that had to implement the ideas. Agile methodologies did a lot to overcome this wall and to speed up the development process, but they had left operations completely out of scope. Almost no scrum team I’ve seen contains an ops guy. But what is the goal of having fast development process and being able to build a feature production ready in 3 weeks, when it takes a lot of time to actually bring it into production?
DevOps is there to overcome the gap, to pick up the speed of agile software development and to deliver the developed features at the same speed to production.
And at this, DevOps is succeeding.
