DevOps. It’s meant to be a marriage between Agile software development and enterprise systems management comprised of Development QA, and Technology Operations. Often we hear about DevOps more as a sort of dysfunctional family, complete with bickering and miscommunication between the developers and those in operations.

Exclusive data for I Programmer from the Pearson Frank salary survey reveals that 38% of Java, PHP, web and mobile developer respondents identified DevOps related issues as the biggest challenge they face in their current role. This included poor company culture to collaboration, inheriting legacy systems, app complexity and budget constraints.

But what if there was a way for devs to work more with ops in order to make their lives easier, increase deployment frequency and reduce the lead time between fixes?

Everybody wants a smooth flow of work with short lead times and fast feedback, but, at the same time, it’s important to make sure that the quality isn’t sacrificed as a result of this.

Two models of DevOps

There are generally two prevailing models of operations support: the classic “you build it, they run it” and the newer model of “you build it, you run it”.

With the classic model, the view is that developers are these expensive and specialized commodities; they’re like fighter pilots who have to be moved onto the next project as quickly as possible. In this framework, the developers hand off the work to the operations team who are great at running things so they take the product and deliver it.

This newer model is very DevOps driven. With “you build it, you run it” there is an integrated team incorporating developers and operations. Anyone that is needed throughout the full lifecycle of the application is brought together with the understanding that they will work together to create, manage and maintain the product. Amazon CEO Jeff Bezos calls these types of teams “two pizza teams” as he believes that a team should not be so big that two pizzas can’t feed them.

But what are the problems with these models? Using the classic model of “you build it, they run it”, there’s the distinct possibility of the following scenario:

The developer is in bed, it’s 3am and something has happened with the application. The phone goes off waking the dev from their slumber, a bunch of people from operations are looking into the issue trying to prove it’s not their fault. Suddenly, this problem sounds kind of familiar to the developer and they talk through the procedures and diagnostics tools, they talk through the log files and eventually the problem is fixed and the developer can go back to sleep. But this problem has happened time and time again and the developer has had similar calls from different development teams, QA, and from other operations groups over the last three months.

Or how about this scenario?

Development has finished on an application and it has been handed over to operations to manage. There is a new deadline of 3pm and the developers are working feverishly to make sure they hit that goal. Suddenly there’s another call from operations – a different team this time – and they have a query about making changes and whether there will be a knock-on effect resulting in performance problems. The developers are constantly getting interrupted with (legitimate) questions and it’s having an impact on their ability to work on new projects. And this is a problem that occurs with the typical DevOps hand off which is more akin to throwing a bunch of documents blindly over a wall than resembling a proper handover.

So then there’s the newer model: the two pizza model. This type of integrated model works great at smaller companies or if the whole company ethos has been created around this way of working, but for enterprises where there are different projects running consecutively with different services being pulled in different directions and different funding streams determining deadlines it’s almost unfeasible that such a model could work at this level.

It works for Amazon and it works for Netflix, but that’s because the decision was made early on and came directly from the CEOs as a mandate declaring ‘this is how we’re going to work’ and it’s an ideology applied across the entire company, not just IT. The truth is that most people’s experience of DevOps will lie somewhere in the middle of these two models.

Making DevOps better

So how can we make DevOps work better?

What if we could:

1. Have the labor scaling benefits of the ‘you build it, they run it” model with the ability to offload some of that operational work or move it to places where it is better suited BUT being able to do so without the frequent escalations and without blindly throwing the documents over the wall, as it were.
   
   
2. Have the responsiveness and control of the two pizza teams but do so without the scaling limitations and being able to offload some of that work.

And those are the principles behind self-service operations. How can we get the benefits of offloading work without worrying about those bad context breaks and switches? To do this, developers need to get themselves into the operations mindset, they need to understand the problems that operations are dealing with.

There’s a lot of pressure in operations. At the same time that enterprises are instructing teams to “deploy, deploy, deploy, go faster and faster” they are also saying “whoa, whoa, whoa” and encouraging a focus on security and stability. Nobody wants to be the next hack or the next breach. Two very polarizing points of view and ops is caught in the middle. It’s got to be safer and more secure but also done quicker than ever before too in order to stay ahead of the competition.

Enterprises themselves have vast organizational complexity as well as the technological complexity to deal with. There are networking teams, systems teams, cloud teams, storage teams, security teams and there will be a bunch of tickets that serves as communication between these different departments basically saying that something needs to be done or something needs fixing. These tickets stack up and suddenly cracks start to appear and progress is halted.

How can developers make ops work for them?

There’s a phrase used in the gym world: “Great abs start in the kitchen”. The same kind of thing applies to operations. Great operations begin in development, and it’s down to developers to instigate this change. So the trick is learning how to develop with an operations mindset. The first realization is that operations is the business. Writing the software in the first place is the start, but most businesses are paid to ensure that software runs continuously and smoothly so operations is a huge part of the success of the business. With that in mind, making sure that is at the forefront of the developer’s minds from the beginning is paramount. The responsibility of deployability, configurability, and monitoring falls on the developers’ toes and are just as important as business features themselves. If this product doesn’t run or it doesn’t scale then it can’t be controlled, no matter what the features are. So, from the developer’s perspective, how much are operations being exposed to things that should be features in the application?

Developing with an operations mindset

A lot of organizations are now operating without making config files and are instead taking on the responsibility for configuration themselves. If it’s their application, their service, why should they externalize it to a whole series of files that operations has to deal with? Instead, why not internalize those things and try and run it as a SaaS model where configuration and the controls for what is being built and the monitoring and telemetry are all part of the application?

You have to demand prod-like environments everywhere: You can’t have one environment on a laptop, a multi-node environment in QA and some totally different setup in staging and production as this is just going to cause problems. As developers, you have to demand the same environments across the board from the start. If we’re not testing for operational conditions as early as possible, we’re just delivering software and we’re not doing what we’re being paid to do which is to deliver a running service.

Another thing to consider is making sure that the handoff between teams is verification driven. Instead of just handing over a ReadMe file you should explain how to look in the log file, hand off actual code (shell scripts are great – everyone can read them) and explain that running this shell script will let Ops know if everything is running smoothly. If it doesn’t work, those scripts and diagnostics can be sent back to the Devs but they will be getting back code instead of just words which can be deployed, configured and tested in different environments. 

Next to consider, and this probably makes a lot of sense to people reading this, but be sure to create immutable versioned artifacts and don’t allow builds to happen later on in the life-cycle. Use standard packaging, get together with your operations team and figure out what is the standard packaging format that you want to use. The core idea is that you build it once and you want to be running and testing those same things in every environment. 

The last tip is to consider prioritizing integration tests over unit tests. Lots of organizations allow their unit tests to run deep but the integration tests – the outside and the black-ops tests – tend to be a bit thin on the ground. The reality is, outside of development, the rest of the business really cares about these integration tests. Unit tests allow developers to move faster and do their job better but from an outside perspective what matters is people being able to tell whether or not to product and business are in a healthy state – and this is where integration tests are more beneficial. 

So that’s a whistle-stop tour through the operations mindset from a developer’s POV. The next step is to think about how to shift these concepts left, as traditionally these are all things that are thought of towards the end of the waterfall life-cycle, but that's for another article. 

• Jamie Mercer is a technology writer covering all things web and software development. His key interests encompass technology management, DevOps and recruitment.

Related Articles 

Restlet Streamlines DevOps Workflows 

Microsoft Launches Azure App Service

New API Commons Platform For Sharing APIs

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info