X

Big IT vendors missing the boat with cloud developers

As cloud adoption continues at an alarming rate, big IT vendors aren't sending the right messages to developers.

Dave Rosenberg Co-founder, MuleSource
Dave Rosenberg has more than 15 years of technology and marketing experience that spans from Bell Labs to startup IPOs to open-source and cloud software companies. He is CEO and founder of Nodeable, co-founder of MuleSoft, and managing director for Hardy Way. He is an adviser to DataStax, IT Database, and Puppet Labs.
Dave Rosenberg
4 min read
cloud

The big IT vendors continue to miss the key factor to the adoption of their cloud products: developers.

This past week Oracle announced that it would soon release a new "cloud" product--WebLogic Server 12c (the "c" is for cloud, get it?). The release is geared toward deploying Java EE 6 applications via servers that can be virtualized in a private cloud environment.

Essentially this new offering lets users deploy apps that they would have previously deployed on a physical server into a virtualized environment. And yes, this is something they can pretty much do already, but it will likely appeal to WebLogic users who want to scale their deployments in a different manner.

But more interesting than the Oracle news are comments from VMware that Scott Fulton wrote about on ReadWriteWeb. VMware's marketing managers allude to the fact that Oracle is taking a virtualization-oriented approach, whereas VMware, already the virtualization leader, is taking an application oriented approach--one that suggests that there are no "layers," rather a single amalgam of compute assets available as a cloud.

How does the owner of the application know for certain that the service level reported by his IaaS provider is accurate, and not just some Perl script with a green light on it? VMware's Henning tells us that the app owner's vFabric tools will be able to spot performance problems wherever they are, and identify independently (not just through some certificate from the service provider) whether the problem is addressable on his end. "If it's not, but these guys are tellin' me I've got a green light, I'm gonna go move somewhere else. I'm not going to deploy agents with my application that are going to measure the performance of the infrastructure. If you tell me it's green, and it's really red based on everything I can see in my application performance management suite, that's looking at it at the business level, I'll go somewhere else."

And while I largely agree with the quote above, the missing link is the ability to transfer applications across cloud providers (I'm guessing the comment above assumes that you can transition between VMware-based clouds), and whether that's actually the right answer. Or perhaps, is that really the problem.

Over the last year as I've been heads down into cloud management with an initial focus on managing Amazon Web Services (AWS) EC2 I've come to realize that it's not so much the infrastructure layer that's the issue, but that applications are often written in a way that have cause-and-effect scenarios related to an instance on AWS.

Take for example an updated application code push that goes from Github to an Amazon Machine Image (AMI). The AMI is just a target for deployment, and if, for example, the developer changes some code that uses up too much memory, the AMI could fall over and die. This is not necessarily a fault of the AMI, but of the application itself, one that could maybe be avoided by using a larger AMI (more RAM for instance) or a staging environment that replicates the production environment.

As such, the cloud management challenge isn't so much that of virtualization, services, or applications, but a combined visibility and understanding of the dependencies that cross the boundaries in the infrastructure and the application life cycle.

Practically speaking, this has started to reshape the discussion of DevOps, originally defined as a cultural movement but now starting to morph into a more sophisticated approach to infrastructure management by both people and machines--less about automation and more about visibility, and a great deal more about aligning multiple teams around end-to-end success.

Going back to VMware and Oracle, the thing I think both companies are missing (at least in their marketing) is the importance of the development-to-deployment-to-operations cycle, and specifically, how crucial it is to get developers on board the new world.

The odd part is that VMware's SpringSource acquisition had a lot to do with corralling the vast Spring developer pool, and Oracle has always run very successful developer programs for its own products. But it doesn't seem that the developer-oriented DNA has trickled down to the cloud products just yet.

Analyst firm RedMonk has a guiding principle that states that "developers are the new kingmakers." This has stood true over the last five years in a number of technology scenarios, and considering how quickly AWS has grown thanks to developer adoption, we can clearly see the principle in action.

Until the large IT vendor ranks figure out how to best appeal to developers, they won't get the cloud right. This is bad news for their customers who are buying into initial oddball approaches, but good news for the startups who can get developers on board and build billion-dollar cloud businesses just like Amazon did.