In the coming months, Microsoft will turn its focus to DevOps, the coming-together of development and operations to facilitate rapid delivery of software. We recently interviewed S. “Soma” Somasegar, corporate vice president of the Developer Division at Microsoft, who provided some insight into the company’s strategy and progress to date.
SD Times: Developers have a lot to think about these days: multiple devices, multiple platforms, the cloud, even workflows are changing as evidenced by the DevOps movement. Are you finding that developers are thinking about and approaching software development differently?
S. Somasegar: Absolutely. Gone are the days when a developer or a development team takes six months to plan something, two years to build it, a year to test it and then someday it will see the light of day. By that time, the whole world is going to change and whatever you might have been building is going to be irrelevant, so you’re going to have to start again.
Today’s developers want a build-measure-learn loop. I as a developer want to think about continuous delivery, continuous deployment, and continuous feedback. I need to start thinking from ideation to design to development to test to deployment to monitoring to getting insight and then being able to do a fast iteration of what I’m building based on the feedback and the insight I’m getting from my customers. So we have this sort of terminology of DevOps.
DevOps means different things to different people. It is implemented differently from team to team and enterprise to enterprise.
That’s right. There are two ways to look at it: First, teams want to build new applications or software and want to use the lean method of build-measure-learn to develop things. The developer is at the center of the DevOps workflow starting from design to development to deployment to monitoring, and taking that insight and feeding it back into the development processes.
Because the developer is at the center of the workflow, they have to think about ALM in broader terms than ever before. You can argue that’s relevant in some organizations or teams, but teams in the traditional ways of developing things still have this notion of a development organization and an IT professional organization, and somehow we have to figure out how we can get better communication flow between those two groups of people to look at the life cycle in a single, cohesive way rather than throwing things over the fence and seeing what sticks.
Microsoft has put a lot of emphasis on ALM over the last few years. DevOps is a natural progression given the way things are going. What exactly are you doing?
Last September, we [had a message for] all those software teams that are excited about adopting modern life-cycle practices, starting from planning to design all the way to deployment and thinking about the whole workflow, including operations. Between Visual Studio 2012 and System Center, we have a fantastic set of solutions for those who want to adopt modern life-cycle practices.
Let’s break that down a bit. To what extent is Visual Studio 2012 addressing DevOps specifically at this point in time?
Integrating development and operations—functions of the application life cycle that have historically been somewhat discrete phases—offers tremendous value [in terms of] streamlining software development. From improving software quality through automated tests that persist in production, to accelerating and smoothing deployment through automation, reducing mean time to repairs and increasing the rate at which we can add new features, DevOps brings a lot to the table.
At a high level, simply having engineering and operations using a single, integrated solution increases efficiencies. For example, it removes the need for a separate ticketing system to exist between them and to manage workflows. Also, integrated systems tend to eliminate barriers to communication and improve collaboration between the groups.
Some think the distinction between the two groups is starting to blur as a result of DevOps. Do you agree with that?
The distinction between these groups is blurring. This may sound insignificant, but it can actually be one of the largest aspects of an organization’s DevOps challenge.