In my opinion there is one main driver for this:
Bringing dev and ops (and – if possible – the business) together in a team helps the team to focus on their contribution to a specific business function in the company. There is no more need for specialization in the sense that the teams only do things based on specific technologies. Dev/Ops teams will now be able to really focus on business value. First this helps companies to become more agile and lean while constantly removing bottlenecks. Secondly Dev/Ops teams can make their part of the business work as smoothly as possible.
Having said so, how important is it that teams have the ability to support their part of the business chain? Should they all use the same kind of tools between different teams, just because there is some architect which tells them so? Or should they have their freedom in choosing the technologies/products their need to support their acquirements in the way they think is best?
I found some interesting talks on this topic:
Freedom of choice
First a post about "Freedom of choice - Three Ways Dev/Ops is Revolutionizing Enterprise Software". It discusses all kinds of tools, but I would like to focus on the monitoring part. At the end the following is stated: "it is more important to get what you need (custom, relevant metrics), rather than get it in a pretty package". The blogpost even goes further by asking why we need APM tools at all. In my opinion you might still need one or the other. But it is much more important that teams are able to make their own choices.
In a slidedeck "Dev/Ops ", Dev/Ops is called "a culture shift or movement that encourages great collaboration to build better quality software faster and more reliably". The most fundamental goal which it described is the removal of waste (Lean). With the freedom to choose the best tools a Dev/Ops team has the ability to remove waste the most efficient way. This is why the freedom of choice in devops tooling is so important.
Why use centralized tools?
If we look further and ask specificly why centralized tools (for monitoring) are chosen, we see that there are two main reasons:
There are just a few small number of teams, let’s say 2 to 3. In these cases, it makes good sense to concentrate knowledge on a smaller amount of tools.
Within bigger organizations there is a need for a single pane of glass to cover all business processes, applications and infrastructure.
In the past decades a lot of monitoring tools have been created, but none of these really gives you a single pane of glass. None of these is really able to give deep insights in all business processes, batch processes, application performance metrics, log entries and so on.
Choosing one single solution to solve a problem in some teams does not give the freedom of choice. I have seen a lot of teams which where forced to use specific tools just because they where good for some other teams. In those teams those tools where not the best solution so they created waste in stead of reducing waste by having the freedom to choose there own tools.
The need for unified tools
I just read another article about "Making Dev/Ops and continuous delivery a reality ". In the end ("the need for unified tools for unified work") it states the following: "The best tools mirror the ongoing and parallel development, test, and deployment activities at the core of continuous delivery. Look for something that integrates the information that comes from various functions, such as change management, version control, issue tracking, and monitoring, and that can be used by developers, operators, testers, and others,”.
Niek Bartholomeus, an independent software architect in Antwerp who recently helped a European bank to move towards more frequent delivery, says: “For me, that’s an ideal start for one team to get insight in the other team’s work and to help bridge the gap between them."
Why we are building StackState
This brings me to one of the main reasons why we are building StackState. It seems to be a necessity to being able to reuse all types of monitoring, IT management and incident management tools, especially for bigger companies. There are a lot of good tools, and ofcourse even more are available in the near future. But having a complete view on the whole stack is simply another, probably a higher level of importance. Einstein once said: "No problem can be solved from the same level of consciousness that created it." We therefore don't believe there will be one so-called meta-tool which can monitor everything. So we think this meta-tool concept should be replaced by that of an umbrella-tool. An 'application' which generates a unified view of all data of all the different tools that are in usage at different departments and Dev/Ops teams. Control within organizations tends to move in cycles: from centralized command/control mindsets to distributed autonomous teams and back again. "Dev/Ops back to the future " beautifully highlights this phenomena.
Within both models (centralized and decentralized) StackState adds value:
We believe both approaches add value, but need each other in order to really work. Some parts require centralization, while others do not.
StackState support a centralized approach by creating a unified overview over different types of tools, like APM, log analysis, batch process monitoring, IT management (provisioning, deployment) and incident management tools. It acts like a single pane of glass.
However the glass metaphor describes StackState best. Teams remain autonomous in chosing their own tooling. StackState just integrates them.
We really focus on creating a single pane of glass for your whole Stack, while allowing decentralized management by collaboration.
Some of our product design principles
Keep your existing tools, deeply integrate and leverage their strengths: this way we indeed give teams the aforementioned “freedom of choice” while creating a single pane of glass.
Enable collaboration: while avoiding central governance: really focus on collaboration between the (Dev/Ops) teams which most of the time really know their part of the Stack the best.
A view is worth a thousand words: Instead of bombarding users with long (paged) lists of tabular data we try to visualize as much as possible. It should also be as up-to-date (near real-time) as possible and update whenever changes occur.
Collaboration through a common understanding: be able to have a common view of the total Stack, so everybody has the same content.
