I recently wrote a couple of technical posts about the object model we have chosen for APM in OpsMgr 2012 and how to author granular alerting rules for APM in XML. That’s more the type of post that pertains on the momteam blog.
This one you are reading now, instead, is more “philosophical” than technical – I think that, going forward, I’ll keep more of this distinction by posting my rants here on my personal blog, as they are only partially related to the products and more about my point of view on things. The reasons explained below are just those that I perceive and what drives me – I don’t mean in any way to be speaking on behalf of my company, our strategists or product planners.
I have heard statements from customers such as “AVIcode is a developer tool” or “APM is for QA/Test environments – if you need it in production you have not done your QA work well”and similar statements. People asked why we did bring together the two, for example, on the TechNet forums. Sure, it can be useful to employ such a tool also in a development and QA/test environment… but why not in production? With frequent deployments that the agile business demands, change control alone can’t slow down the business and sometimes bad things happen anyway – so we need solid monitoring to keep an eye on the behavior and performance on the system, exposed in a way that can quickly pinpoint where issues might be – be them in the infrastructure or in the code – in a way that enables people to efficiently triage and resolve them. Sergey points out how APM in OpsMgr 2012 is much easier to setup, simpler to configure and cheaper to maintain than the standalone AVIcode product ever was, and hints at the fact that a comprehensive solution encompassing both “traditional” systems management approach as well as Application Performance Monitoring is a good one. It is a good one, in its simplest form, because we have a simplified, unified and more cost-effective infrastructure. It is a good one – I add – because we can extract a lot of useful information from within the applications, only when those are running; when they are down altogether, APM is not very useful on its own, when it is not complemented by “traditional” OS and platform checks: before I wonder if my application is slow, I’d better ask “is IIS actually up and running? is my application running at all?”. Operations Manager has been historically very good, with its management packs, in answering those questions. APM adds the deep application perspective to it, to provide rich data that Developers and Operations need to have an overall picture of what is going on in their systems and applications.
In my opinion, in this world of continuous services improvement and cloud services, IT management is tearing down the walls between what traditionally has been two separate worlds of “Operations” (Ops) teams and Development (Dev) teams. So, while people ask why we brought what was more of a Developer tool into a pure System Management tool, it is clear to me that those areas are converging, and even other vendors who start from the opposite approach (APM) eventually go “back to the basics” and begin implementing server-level systems management such as showing disk space and CPU utilization, meaning that, whatever your starting point was or has been, everybody wants and feels the need to bring those two worlds and disciplines together.
This line of thoughts has even been given a name: “DevOps”.
What is this DevOps things anyway is one famous post that can be found on the web, where Stephen Nelson-Smith writes:
[…] On most projects I’ve worked on, the project team is split into developers, testers, release managers and sysadmins working in separate silos. From a process perspective this is dreadfully wasteful. It can also lead to a ‘lob it over the wall’ philosophy – problems are passed between business analysts, developers, QA specialists and sysadmins […] The Devops movement is built around a group of people who believe that the application of a combination of appropriate technology and attitude can revolutionize the world of software development and delivery […] these people understand the key point – we’re all on the same side! All of us – developers, testers, managers, DBAs, network technicians, and sysadmins – are all trying to achieve the same thing: the delivery of great quality, reliable software that delivers business benefit to those who commissioned it. […]
DevOps – the war is over if you want it is a presentation by Patrick Debois which I also encourage you to check out, as it is also very evocative thru images:
DevOps – 6 steps for improved collaboration
[…] The DevOps movement is a modern push from the software industry to instill better interaction and productivity between development (Dev) and IT operations (Ops). Instead of throwing applications “over the fence” blindly to operations, a fluid and much more effective DevOps process inserts transparency, efficiency and ownership into the art of developing, releasing and the production use of critical applications. It also binds the two traditionally siloed teams together. […]
Last but not least, 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr (another presentation from a conference) is a real-world example of a large scale web site (Flickr) and how those practices are adopted.
When it comes to the DevOps ideas and concepts within Microsoft products, for what I can see, some customers really “get“ it, and would like to see more in this sense. For example I found this interesting blog post by James Dawson:
[…] The bulk of my work revolves around the Microsoft platform and to put it bluntly it is very much a second class citizen in terms of the available tooling.
Now I’ve fanned the flames, let me put some context around that. I don’t mean that as a criticism, in fact I view the status quo as an entirely natural result given where the movement grew out of and, to be frank, the mindset of the typical Microsoft IT shop. In a Microsoft environment there tends to be far greater reliance on big vendor products, whereas in the Linux/BSD world it is far more common to integrate a series of discrete tools into a complete tool chain that meets the needs for a given scenario. […]
I think James is right when saying this: he “gets” it, but we also have a vast user base of more “traditional” enterprise customers where the concepts have not been digested and understood yet. When it comes to traditional enterprises, what sometimes happens is well explained in this other article by Paul Krill:
[…] To protect the infrastructure, IT ops can put in place processes that seem almost draconian, causing developers to complain that these processes slow them down, says Glenn O’Donnell, an analyst at Forrester Research. Indeed, processes such as ITIL (IT Infrastructure Library) that provide a standardized way of doing things, such as handling change management, can become twisted into bureaucracy for its own sake. But sometimes, people "take a good idea too far, and that happens with ITIL, too." […]
And I think that is exactly one of the reasons why, even if many of our teams “get” it, we need to talk more of the DevOps culture in those places where it hasn’t arrived yet, so that these integrated products are more successful and can help them solve problems – because some of these customers haven’t yet realized that it takes a culture shift before these new tools can be adopted. DevOps does not have critical mass today, but could have it tomorrow. Even Gartner says:
[…] by 2015, DevOps will evolve from a niche strategy employed by large cloud providers into a mainstream strategy employed by 20% of the Global 2000 organizations”. […]
So, back to suggesting that Microsoft produces more of this “goodness”, James again writes:
[…] I want to see the values espoused by DevOps spread far and wide, including the quietest backwaters of corporate IT, where Windows, Office and IE 6 reign supreme. To that end, the Microsoft infrastructure community needs to take a similar approach as the .NET community did and start bringing some of the goodness that we see in the Linux world to the Microsoft platform in a way that facilitates adoption for all and actually takes advantage of the platform’s innate richness and strengths. […]
So do I. And, for what I can tell, we are actually trying to bridge gaps and push the culture shift – integrating APM in OpsMgr is definitely an effort in this direction. But it might take some time. Is it too an “utopian” a vision? I don’t think it is; I think we can get there. But it will take some time. As this other article was saying:
[…] The DevOps approach is so radical it will take some time to cross the chasm, and indeed it will be actively resisted by many organizations where it threatens traditional delivery models and organizational structures. […]
Let’s get Dev and Ops talking to each other, also in the Enteprise! I am all for it.
The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my own personal opinion. All code samples are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.
THIS WORK IS NOT ENDORSED AND NOT EVEN CHECKED, AUTHORIZED, SCRUTINIZED NOR APPROVED BY MY EMPLOYER, AND IT ONLY REPRESENT SOMETHING WHICH I’VE DONE IN MY FREE TIME. NO GUARANTEE WHATSOEVER IS GIVEN ON THIS. THE AUTHOR SHALL NOT BE MADE RESPONSIBLE FOR ANY DAMAGE YOU MIGHT INCUR WHEN USING THIS INFORMATION. If you want to see the official info from my employer about the topic above, go to http://www.microsoft.com/presspass/presskits/cloud/default.aspx