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.