Monthly Archives: December 2011

Dec 29 2011
1 Comment
Commentary, News Video

Nodeable CEO talks cloud on Tv

Nodeable CEO Dave Rosenberg talks cloud on Tv

Tagged
Dec 20 2011
DevOps

The Stars Align for Cloud Intelligence

It’s not surprising that cloud computing is grabbing money out of budgets formerly allocated to hardware and virtualization. After all, at a certain point, it becomes more cost effective to let someone else build efficient data centers. Few can out-datacenter Amazon.

But what is perhaps surprising is where the cloud dollars will go in 2012: mobility and infrastructure support, according to a new survey of medium-size and large enterprise CIOs published by CIO Insight.

Not that hardware vendors are going out of business in 2012. Thanks to heavy spending by the cloud vendors, as detailed by Morgan Stanley Research (warning: PDF), server vendors will continue to make money, albeit on a much more modest growth curve. Red Hat, too, as the arms dealer to many of these cloud vendors, will also continue to thrive. At any rate, as with government expenditures, few ever really cut spending. They simply grow it more slowly, allocating budget savings in one area to another, increasing spending all the while, year-over-year.

Mobility is a no-brainer. App development is CIO Insight‘s fastest growing budget area, as enterprises seek to embrace the consumer smartphone trend to deliver functionality in app-like form.

IT infrastructure operations software, however, is perhaps less obvious, because it’s less visible. But in a world where enterprises risk losing control of their IT as it’s distributed across public and private clouds, as well as internal and external data centers, it’s perhaps even more critical to business success. The cloud, after all, is collecting data from, crunching data for, and serving data to mobile devices.

Which is why business intelligence remains a hugely important budget item, as the report points out:

{B]usiness intelligence…has become one of the most popular areas of IT investment. Nearly nine in 10 organizations are budgeting BI for 2012. The rise in investment should astound anyone: More organizations will spend on BI in 2012 than on any other kind of application. By comparison, 84 percent are budgeting for traditional desktop productivity applications, 83 percent for project management and an equal number for collaboration solutions, and 82 percent for human resources apps. Across all 75 budget areas, BI will be the seventh most common in 2012.

As the cloud becomes more important to delivering business value, I suspect we’ll see a similar rise in what we at Nodeable call “systems intelligence.” Think of it as business intelligence for your cloud systems, be they Amazon Web Services (AWS), GitHub, JIRA, or even Nagios, Puppet, or…you name it. If it has an API, it can be monitored and managed, and increasingly will, whether or not one would normally term it a “cloud” system.

And the reason for systems intelligence is roughly the same as business intelligence: BI exists to make sense of all the disparate business data that can help a CEO streamline her business.  Systems intelligence exists to make sense of all the disparate systems data that can help a CTO/CIO streamline her IT operations.

If the CIO’s paramount job responsibility in 2012 is delivering operational efficiency, then it follows we must become much more adept at tracking and influencing the systems that have the potential to deliver such efficiency. My app is down: is it AWS’ fault? Bad code committed to GitHub? Some combination of the two? Which of my developers is the most productive? Who on my DevOps team is closing the most JIRA tickets? Etc.

All of these questions are easily answered by our systems, if we know how to ask. And how they interact with each other is also easy to find out…if you’ve put a heck of a lot of effort into getting the right data from the APIs, as Nodeable does.

CIOs are investing heavily in the cloud to get to greater levels of operational efficiency, but they’ll never get there without also investing in systems intelligence tools that understand the cloud. Tools like Boundary, or Nodeable, or other new-school systems management tools.

Tagged , ,
Dec 16 2011
DevOps

A SETI for cloud systems data

Rackspace just put its Cloudkick investment to good use, announcing its cloud monitoring private beta.  We’re big fans of Rackspace, and have long liked the Cloudkick monitoring tools.  Heck, I’m even quoted on the Cloudkick webpage for saying it “democratizes the cloud.”  The problem, however, is that such tools don’t go nearly far enough.  In an API-driven world, monitoring silo’d systems is just a baseline.  It’s table stakes.

Systems increasingly talk to each other, or can.  But traditional monitoring tools, along with the broader category of systems management, have a hard time making sense of the intersection of systems through APIs, not to mention simply making intelligent inferences from single-system data.  Did my app break because of my GitHub commit or is something awry with Amazon?  Or perhaps both?

More pertinently to Rackspace’s new monitoring tools, from the documentation it seems the developer must still program the monitoring tool to get it to send you alerts. This places all the burden on the user to input all of the logic, rather than allowing the system to analyze the systems’ data streams and move beyond mere monitoring to systems intelligence (sort of like business intelligence, but for cloud infrastructure).

Monitoring and management is a big data problem to solve.  But as much as Hadoop and other big data tools are being put to use in other areas, no one seems to be using them within the systems management context.  This is a problem.

The DevOps professional shouldn’t have to spend time setting up their tools.  The tools should enable them to spend the vast majority of their time doing their real job: developing their applications.

None of which is intended to disparage Rackspace or the many systems management companies out there that can’t do this.  Even the most impressive of the new breed of management tools, like Splunk, leave users in silos and fail to connect the dots between the different servers or systems being managed.  Such systems leave the heavy lifting to the users, which is why entire teams of Operations professionals are required to make sense of logs and such.

But in a DevOps world fixated on getting things done — right now — this won’t do.  Better tooling is required.  This is why Nodeable was born, and why we’re upending the traditional systems management market.  If you’d like to get a taste for yourself, please sign up for our private beta.  We have some big names trying the system now.  We’d love to add you, too.

Tagged
Dec 09 2011
DevOps, Tech

Developers and the invisible cloud

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.

Tagged , ,
Dec 08 2011
Commentary, DevOps

Red Hat’s shopping list to include DevOps?

The 451 Group has a new report out, written by analyst Jay Lyman and entitled “Data, systems management or devops likely to drive Red Hat’s next deal“, which walks through potential acquisition targets for Red Hat.  The report rightly hones in on configuration management vendors like Puppet Labs and Opscode, but the broader theme is that Red Hat, along with every other enterprise software vendor, needs to figure out developers.

Lyman writes:

Given the prominence of Linux and open source software in cloud computing, systems management and ‘devops’ (where application development collides with application deployment via IT operations), Red Hat may add value or extend by scooping up one of many possible targets that fit with its existing technology and strategy. When considering devops providers – all of which are reinforcing our belief that devops practices that embody efficient use of cloud computing resources are moving to more mainstream, enterprise users – the server configuration and automation players sit at the crux of the trend.

All of which is true, but it’s really the trend itself that is interesting, and as critical for Red Hat to figure out as it is for Dell, IBM, SAP, etc.  That trend clearly points to the rise of developers as the cloud enables them to sidestep Operations, or at least minimize its control of IT.  It used to be that enterprise ISVs could ignore developers.  No more.

Developers are the new kingmakers.  Or usurpers.  Sometimes both.

In an IT world increasingly dictated by developers’ demands for greater efficiency, traditional enterprise ISVs can’t conduct themselves in traditional enterprise ways anymore.  Everyone needs to figure out how to engage developers, and that means connecting them where they are, which is the cloud.

Salesforce, which is an old-school, new-school SaaS vendor, clearly “gets” this, buying up developer-friendly Heroku, and VMware really gets it, buying up SpringSource and more.  The companies that “get it” are those that are building out or buying into the tools and services that drive greater DevOps efficiency.

So, The 451 Group is correct: DevOps is real, and it’s important to Red Hat…just like it should be to everyone else.

Tagged ,
Follow

Get every new post delivered to your Inbox.

Join 53 other followers

%d bloggers like this: