jump to navigation

The next reincarnation of cloud computing July 19, 2010

Posted by Simeon Simeonov in Programming, SaaS, amazon web services, cloud computing.
Tags: , , , , , , , , ,
5 comments

Over Memorial Day weekend I wanted to play with CrunchBase data. I wrote a quick bash script that pulled data from CrunchBase and put it in MongoDB, one of the new databases from the NoSQL movement. In the process, I noticed I was programming file operations. It was a strange feeling. The last time I wrote code that manipulated files was a decade ago. For other projects, the data has been either in a database or a web service somewhere. Why would I put anything in a file? For that matter, why would I want to deal with hardware constructs such as network ports? For an application developer, as opposed to an infrastructure developer, all these vestiges of decades-old operating system architecture add little value. In fact, they cause deployment and operational headaches—lots of them. If I had taken almost any other approach to the problem using the tools I’m familiar with I would have performed HTTP operations against the REST-based web services interface for ChrunchBase and then used HTTP to send the data to MongoDB. My code would have never operated against a file or any other OS-level construct directly.

This experience got me thinking about the evolution of application development and that led to a guest post on Om Malik’s GigaOm on the migration of cloud computing from infrastructure-as-a-service (IaaS) to platform-as-a-service (PaaS).

Most assume that server virtualization as we know it today is a fundamental enabler of the cloud, but it is only a crutch we need until cloud-based application platforms mature to the point where applications are built and deployed without any reference to current notions of servers and operating systems.

As I mention in the post, I’m quite impressed with VMWare’s willingness to push forward in this direction. Listening to Paul Maritz, CEO of VMWare, speak at Structure, it’s clear he’s aiming very far and has the leadership potential to get there. More than a decade ago, I used to listen very carefully to what he said because he owned several large groups inside Microsoft, some of which loved my first startup (Allaire) because we pulled through many thousands of Windows & SQL servers and some of which hated us because we had the best Web development environment on Windows. He’s back on the list of execs I’ll follow carefully.

This is a big opportunity for Amazon to go up the stack at the right time. It’s good from an economics standpoint as it can increase margins in two ways: (a) improves efficiency and (b) switches pricing to more value-based application-related metrics. AWS has gone up the stack into data storage,  management and analytics. I doubt they’d miss the opportunity to become a meaningful PaaS provider at the right time. Breadth of platform support and platform expertise will be interesting challenges to resolve.

The other interesting trend to watch for here is that a reduction in the capabilities of the server virtualization tier increases the value of intelligent networks, one reason why Cisco smartly grabbed @lewtucker as CTO of their emerging cloud group and has security gurus like @Beaker on board.

The comments have raised several questions:

  • Is security harder with PaaS? In the short run, yes, but only because we have less experience with shared hosting on locked down PaaS platforms. Google App Engine, Heroku and others are leading the way here. Werner Vogels said that he trusts hypervisors to provide isolation. It will take a while for big cloud providers such as AWS to equally trust PaaS implementations. In fact, it’s likely they’ll build their own as Google has. Cisco badly wants to help, too.
  • How does IT rebill in enterprises? Having a simpler hypervisor or no hypervisor at all doesn’t mean you can’t collect HW usage metrics and decide how to apportion them to simultaneous users of the hardware. Even better, you can measure and rebill based on other, more business-value-oriented metrics which could give the IT organization some budgetary slack. It would certainly give them more deployment flexibility both inside and outside of their data centers.

Soon we will be able to throw away the server virtualization crutch and, like in that memorable moment from Forrest Gump, we will be able to run leaner and more scalable applications in the cloud on next-generation platforms-as-a-service. For the time being, my call to action is for application developers to stop writing code that directly touches any hardware or operating system objects and try the current generation of platforms-as-a-service.

Developers out there building applications, give me a shout about when was the last time you programmed against a file.

Let me know what you think in the comments or on Twitter @simeons.

Forced Upgrades June 6, 2008

Posted by Simeon Simeonov in SaaS, Web 2.0, cloud computing, startups.
Tags: , ,
3 comments

Rolling out a product upgrade used to be a big deal. Decades ago it was about replacing boards and ICs. Twenty years ago it was about shipping stacks of floppies and hoping they survive the UPS trip. A decade ago it was about getting a CD in the mail. Since then we’ve all gotten used to downloading software. With software-as-a-service (SaaS) and platform-as-a-service (PaaS) offerings, the upgrade is rolled out in some data-center 3,000 miles away.

My point is that the cost to vendors for upgrading products has gone down substantially. First, there were the truck rolls. Then it was about provisioning and shipping the right type of media to the right customer. Then it was about posting a nicely packaged updater online. And, if you are hosting, you don’t even have to package an update–just get it to your servers anyway you can.

As upgrade costs to vendors have gone down, it has become easier to push more and more smaller upgrades. There are other factors driving this trend also, including the spread of security vulnerability exploitation tools. The net effect on customers is not necessarily positive. Just find a CIO and ask him/her about the cost of planned and unplanned outages due to upgrades. For example, several of the Blackberry outages have been pinned on upgrades.

The worst type of upgrade in the shrinkwrap world was a “forced upgrade,” an upgrade that you had to install in order to maintain support coverage or deploy any additional upgrades. As I have been thinking more about building startups that leverage online platforms and cloud computing, I’m starting to realize that almost every SaaS and PaaS upgrade is a forced upgrade.

When Facebook changed the way in which so-called “forced friend invites” were handled last February, hundreds of Facebook application vendors using the F8 platform were affected overnight. They had no control over Facebook’s choice — it was a “forced upgrade.” The only options developers had were to roll with it or get off the platform. This is much different from building applications on top of infrastructure deployed on premises (for example, if you don’t like Vista, don’t upgrade).

Amazon Web Services Outage: Causes And Remedies February 16, 2008

Posted by Simeon Simeonov in SaaS, Web 2.0, amazon web services, startups.
Tags: , , , , , , ,
9 comments

If been a big fan of Amazon Web Services (AWS) because they lower the costs of startup experimentation. I’ve sponsored their events, judged their startup competition, etc. I have friends on the team. I’ve also had frank conversations with them about service level agreements and what it means to be an infrastructure provider in a mashup world. Mashups increase the need for high availability and uptime. If the user experience of a mashup application requires, say, five web services from three separate companies to be available the overall probability of failure goes up subtantially. it’s the weakest link in the chain argument.The Net learned this the hard way yesterday when multiple AWS services (S3, EC2, SQS, Simple DB, etc.) had a multi-hour outage. The problem was exacerbated by the fact that, internally, various AWS services depend on one another and especially the storage service, S3.It looks like the cause for the outage was a particular use pattern of S3:

What caused the problem however was a sudden unexpected surge in a particular type of usage (PUT’s and GET’s of private files which require cryptographic credentials, rather than GET’s of public files that require no credentials).  As I understand what Kathrin said, the surge was caused by at least one very large customer plus several other customers suddenly and unexpectedly increasing their usage. 

I would highly recommend for anyone who is building a developer community or providing SaaS infrastructure or relying on SaaS infrastructure to take the time and read the many posts on the AWS forums about the outage. You hear the real pain and frustration of people whose businesses depend on AWS. The key complaint was not that the service failed–failures do happen–but that Amazon was not prepared to engage with the developer community around the failure.

It’s AmazING the fact of having no info on what’s happening. Absolutely unacceptable. Come on, people on this forum are all tech guys, so we understand that bad things happen from time to time. However, you MUST be transparent with your customers and give them details on what’s going on (yes, we want to know exactly what’s happening and not a standard response like ‘The issue is resolved’). In fact, it is not. So please, scale these complaints to the right person and post the technical explanation of the issue as soon as possible.

Jesse Robbins over at O’Reilly has a good post comparing how Amazon dealt with the situation to how Salesforce responded to its infamous outage a couple of years ago. I’ve also blogged before about how SaaS brings increases responsiblities.All in all, Amazon worked very hard to get the issue resolved and the community was thankful for their efforts.

As I said before, you need to be transparent with your customers. No service can provide 100% uptime. It’s a fact. No matter if u have a redundant anycast network or supercalifragilisticexpialidocious elastic clouds. I just want to get notified and know what’s exactly happening. Nothing else. That said, the issue was resolved very fast, so you should be very proud. Hats off to Amazon’s IT staff.