In the rush to coin new terms and phrases, we have invented an only occasionally useful term, “DevOps”, that perhaps puts more emphasis on “Ops” than is deserved. It is, after all, half of the term, but should be much less in practice. At least, in terms of traditional Operations. As VMware has been highlighting, a developer deploying to the cloud should be primarily concerned with her app, not the cloud. The cloud is someone else’s problem, e.g., Amazon’s.
Steve Henning, VMware’s head of applications product marketing, nails it when he declares, “The cloud gives the opportunity to be able to empower applications owners to be able to manage applications at the business level, independently of the underlying infrastructure.” This, in turn, allows IT/development to become part of the business team, and not an order taker working in some remote server room.
It does not mean, however, that the application developer can completely neglect the infrastructure.
As my Nodeable colleague, Neil Levine, put it to me:
Developers think in terms of applications, not infrastructure. They don’t have time to become operations experts, but they still need to interact and respond to errors which originate with infrastructure. Hence, developers need tools that help them connect the application-related issue to the infrastructure in a way that is quick and intuitive. This requires the tool to do as much of the diagnostics for them as possible, to help them overcome their lack of operations experience.
In other words, good tooling needs to keep pace with the speed and agility the cloud promises developers. This is why we’re seeing tools like Boundary (network monitoring in the cloud), ScaleExtreme, and Nodeable rise up, not to mention VMware. Such tools keep application developers focused on their applications, not by ignoring the infrastructure but rather by calling out areas in which the infrastructure and the application are out of whack, and giving developers the necessary information to debug the problem, as Stephen Thair, web operations manager at Seriti Consulting, points out.
An example may help.
A developer writes code and look at trends/issues from the perspective of the application. She may code something such that when a button is pressed, a given action should happen. If the action doesn’t happen it could be because of 1,001 things, including bad code, bad deployment of the code, or the infrastructure. In the cloud world, the developer shouldn’t really have to know about how the infrastructure is setup and built, but only that if there is a problem which is causing the button to not work, that problem needs to be fixed.
In the pre-cloud days, the developer would have thrown the issue over the fence to the Ops person and told them to work out the cause. It’s not that they were incapable of figuring out the problem. After all, these same people are now called “DevOps” and are responsible for a large chunk of the Ops function. But we also can’t really expect developers to have 10 years of operations experience overnight.
Therefore, a new breed of management tools is needed that help the developer diagnose and remedy the problem, and not based on old log files. The cloud actually gives developers the ability to operate their applications and underlying infrastructure in real-time…provided the tools monitor system state changes in real time. Such new tools simplify the Ops experience to: “Button broken. Reason: Amazon. Suggestion: remove large log file to free up disk space?” The developer can then correlate the problem to fix it in one quick go.
However, sometimes it’s not a red/green light issue that plagues the developer’s application, but rather it’s a trend or pattern of things happening in the infrastructure. Modern tooling can explain how those trends relate to the function of the application for which the developer is responsible. Again, the developer needn’t become an expert in infrastructure: that’s the cloud systems management tool’s job. It helps keep the developer productive by simplifying her interaction with the application’s cloud infrastructure.
In short, great tooling should make the cloud largely invisible to the developer. Not because it removes all interaction with the infrastructure, but rather because it helps the developer keep her focus on the application by dramatically simplifying the view into the infrastructure, particularly when it is creating problems for the application.
Nodeable is one example of such tooling. Undoubtedly there will be other competitors. But I think we’ll see these come from cloud systems management companies born in the cloud, rather than by those that retrofit old-school server systems management solutions for the cloud.
Are your management tools slowing down the cloud?
The cloud isn’t about cost, though by shifting enterprise spending from CapEx-heavy server purchases to OpEx-friendly cloud subscriptions, the cloud not only has the potential to lower costs but also to shape how they affect budgeting in highly positive ways. No, cloud is about speed. Speed of development. Speed of change.
Speed of innovation.
This message is driven home in a 2011 InformationWeek report entitled “IT Is Too Darn Slow.” InformationWeek polled a large group of IT executives, who point to SaaS and cloud as primary drivers of increased speed of IT.
This makes intuitive sense, as it allows IT to spend less time managing hardware, installing software, and other mundane tasks, and gives it more time to focus on actually driving business value.
The problem, however, is that IT management tools haven’t kept pace. Even the best of such tools tend to be log-driven, which is by definition offers a historical view of what happened in one’s IT infrastructure, be it on-premise or cloud-based. But given the speed at which DevOps moves, IT really needs a real-time view of what’s happening.
This is, of course, something that Nodeable does well. Nodeable adds intelligence to systems data, making it easy to view, analyze, and manage cloud infrastructure and services…and Nodeable does this in real-time, unlike log-based systems or antiquated IT management tools. Rather than drown DevOps in a deluge of data/updates, however, Nodeable surfaces relevant, actionable system data in a modern interface that is as easy to use as Facebook or Twitter.
The data processing on the back-end is powerful, and so is the interface used to view this real-time system state.
All of which is only going to become more important over time. Over the next three years, Morgan Stanley Research shows (warning: PDF) a steady decline in server shipments (except to cloud providers), even as adoption of the cloud explodes.
Whether viewed in terms of migration of workloads to the cloud or enterprise adoption thereof (which the research pegs at a 50 percent penetration rate by 2014, growing at a 23 percent CAGR over the next three years), cloud adoption is real, it’s broad, and it necessitates a change in how we manage IT.
It’s not surprising to see industry dinosaurs relabeling their 20th Century solutions as “cloud management.” But labels can be deceiving.
Real cloud management is native to the cloud, and is designed from the ground up for multi-tenancy and other aspects of cloud deployments. It shouldn’t show isolated server logs, but rather give a holistic view into the interplay between disparate cloud systems and how such interactions are affecting performance (i.e., is AWS the problem or is it Github? Or a combination of both?).
Services like Nodeable and Boundary, which I covered for The Register, get this.
Even as IT hits warp speed, driven by SaaS and cloud, enterprises need to take care not to let their IT management tools get in the way. Cloud management tools run in the cloud, deliver real-time system data, and provide a contextual view of what’s happening in the system. In short, they make IT even faster.
Share this:
Like this: