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.
Let’s talk more specifically about Visual Studio, Team Foundation Server, System Center, and how all of that is working together.
Microsoft Visual Studio 2012, integrated with TFS and System Center, provides teams valuable DevOps capabilities today that will be built upon in upcoming releases. System Center, for instance, has the ability to create IntelliTrace logs containing detailed information about faults discovered in production, and it links that information to TFS work items it creates. This information is then carried through to Visual Studio, informing the debugger and enabling the developer who’s addressing the issue to work almost as if they were debugging a live process. This largely eliminates the common challenge developers face in reproducing a bug to diagnose the issue.
Another example is the continuous deployment features available from TFS for applications running on Windows Azure, enabling developers to deploy fixes and new features into production automatically (once those add-ins or changes pass predefined tests). This reduces the deployment demands placed on Ops, decreases the mean time to resolution of faults, and accelerates the release of features that increase an application’s value, allowing teams to deliver continuous value on the schedule that their users and business organizations demand.
Can you give us a DevOps example from a customer?
One example of DevOps value I can cite comes from the Xerox India Development Center (IDC), which supports software development for its global customers. IDC was looking for a more reliable method of quickly testing and fixing applications for its customers, partially through better collaboration. Using Microsoft System Center integrated with Team Foundation Server (TFS) and a Microsoft private cloud solution, IDC has implemented a method of dynamically replicating customer data center environments, enabling the operations team to efficiently provide developers real-time troubleshooting and application optimization insights. IDC estimates the system has improved developer productivity by nearly 40%, and has cut costs about 30%.
What makes the combination of Visual Studio 2012 and System Center so powerful as it relates to DevOps?
System Center’s Global Service Monitor (GSM), integrated with Visual Studio and TFS, is a great example of DevOps leveraging resources and connecting dots to discover and resolve faults. The very same test a developer wrote early in a build, against which the application was constantly tested during development, can be utilized after the application is placed into production—running on multiple servers globally—to monitor its worldwide performance.
No new test needs to be written by Ops. Instead, GSM continues to run the original test in the cloud, testing the application’s performance against the scenario it was originally written to check. In the event a fault is discovered, both Dev and Ops are alerted by the same dashboard, and all the conditions present when the fault occurred are captured in the trace and routed, through TFS, back to the developer.
In addition to the benefits of transparency and efficiency this brings, that testing in production is a much deeper level of performance measurement than monitoring. Performance monitoring typically alerts users if a server goes down or fails to meet a certain performance metric. Testing in production, on the other hand, checks an entire, detailed performance spec of an application, raising alerts if any step along the way drops below a defined threshold.
Another feature we’ve recently introduced is a new work item type, called “Operation Issue,” released in System Center 2012 Operations Manager. This new work item enables Ops to assign System Center alerts directly to the engineering team by creating a new engineering work item in TFS. All changes to that TFS work item are synchronized with the associated alert in Operations Manager, giving Ops great visibility into progress being made by engineering against the issue.
Again we see one of the great benefits of DevOps that’s easy to underestimate: the efficiencies that come from simply integrating tools that teams are already familiar with and accustomed to using on a day-to-day basis. No retraining or deployment of new tools required.
Obviously you’re beefing up ALM capabilities to include more DevOps capabilities. Can you comment on them?
Microsoft’s ultimate intent is to provide development organizations of any size an enterprise-grade ALM solution in the cloud. In recent months, we’ve added features to Team Foundation Service that support each stage of the software cycle, from rich collaboration and enterprise agile planning (without prescribing a specific agile methodology) in the early stages, through build, test, backlog management, issue tracking and code repository in the cloud, to facilitating continuous deployment to Windows Azure—automatically, if a team chooses. User feedback and feature requests can also be integrated and fully tracked. Taken together, these features add up to Team Foundation Service being a great start toward our vision, but we know there’s more work to be done.
For instance, some of the System Center-integrated features I mentioned earlier are currently available only with on-premise Team Foundation Server. So we’ve moved to a cadence of releasing new features on the service every few weeks, and are listening closely to feedback from our users to determine what features are most requested and offer teams the greatest value.
As much as we advocate and support development organizations continuously increasing the value their software provides their customers, we’re doing the same for ours. DevOps will come sharply into focus as Team Foundation Service evolves, as we support the trend of decreasing distinction between Dev and Ops, and as the benefits of all functions on the team having greater visibility into shared workflows, and the value that comes from streamlined collaboration across the team.
How about partnerships? Some of your partners are delivering DevOps functionality or solutions now.
We feel really good about the breadth and the depth of our partner ecosystem. If you think about DevOps, people used to think in terms of an ideation phase, a development phase, a testing phase… You have a whole lot of bridge partners in all those areas. Three to five years ago, we had partners in the first two phases, but now I feel good about the depth and breadth of partners at each stage of the development cycle.
Between what we deliver and what our partners are doing in adding value at each and every phase of the development life cycle, we’ve got the broadest and richest tools on the planet, period. We believe in building great tools, providing a great set of tools, and then working with the partner ecosystem to fill in the holes so we have a broad and rich offering for our customers. That’s by strategy and by design as opposed to by accident.
Earlier, you drew a distinction between teams doing modern development and teams doing traditional development as it relates to DevOps. How is that going to play out in terms of products?
There’s the emerging world and the traditional world. The emerging world wants to build modern applications. They want to do build-measure-learn, an agile way of doing things. They usually think about DevOps and have a Team Foundation Service team. They don’t have a development team and an operations team. They have a Team Foundation Service team that does development and operations.
You see DevOps coming together. And then you’ve got the traditional IT organization and development organization. We at Microsoft need to think about DevOps in the broadest context. Some teams think of DevOps as one continuous workflow. Others have a development organization and an IT organization that needs to work better together. The work we are doing in Visual Studio, Azure and cloud services will benefit both. We want to make sure that we provide a fantastic integrated workflow for the developer irrespective of whether they’re in the DevOps world or the traditional world. That’s what you’re going to see. It’s about giving developers what they need. We want to make sure they have a great workflow and technologies.
Well, Team Foundation Service is a start.
There’s a lot more we can and should be doing, particularly if you think about DevOps and the set of services we want to deliver from the cloud. We want to marry Web and client tools and services from the cloud, and the three of those together will give you the best developer experience.