Friday, October 31, 2008

Microsoft Azure May Be Too Good To Ignore

There is an interesting twist coming out of the events of last week that I think warrants explicit notice. By "connecting the dots" on a series of observations, one can come to the conclusion that Microsoft is now well in advance of any of the other major software systems vendors when it comes to establishing the platform of tomorrow. And, yes, though most of the Oslo/Azure world is not open source, it just may be better.

Start with the Azure and Oslo announcements, demonstrations and presentations from PDC 2008. As I noted earlier, Microsoft now has the most advanced PaaS offering on the market, much more enterprise friendly than Google AppEngine. (AppEngine wins out for extreme scale web applications, however--hands down.)

I watched the high level overview of Oslo given by Douglas Purdy, a product unit manager working on next generation tools at Microsoft. It was riveting. The thought and engineering that went into the models and tools demonstrated in that 70+ minutes were revolutionary to me. Meta-programming of generalized models with the capability to underwrite both domain-specific and generalized programming languages. If that sentence doesn't make sense, watch the video.

Here's the thing. Oslo goes beyond the Java/C# debates. It creates a platform in which complex systems can be described by a series of fairly simple models, assembled together as needed to meet the task at hand. Text tools for the low level stuff, visual tools for the high level assembly, etc. It really was an eye opening view of what Microsoft has been working on now for a few years.

Now take a look at Azure, and the "All-Enterprise" infrastructure that will be available there. Identity services (OpenID, no less), an Enterprise Service Bus, relational and unstructured database services--the list goes on. If you take the time to learn .NET, you can get an amazing experience where the development tools just flow into the deployment models, which just flow into the operational advantages, whether on-premises or in the cloud.

Yeah, Azure is PaaS and Microsoft-centric to start, but may just work as advertised. Note as well that all this functionality required little or no open source. As James Governor notes:
"...[C]ustomers always vote with their feet, and they tend vote for something somewhat proprietary - see Salesforce APEX and iPhone apps for example."
and Dion Almaer (who happens to be a Google developer) notes:
"We can’t just be Open, we have to be better!" [Emphasis his]
Let it be known that Microsoft may have actually thrown down the gauntlet, started growing their "Tribe", in which case the rest of the industry would need to decide quickly how to respond.

I still maintain that Azure is only interesting to the existing Microsoft development pool. However, it they have great success in creating and hosting enterprise applications, IBM and HP (and Amazon and Google) are going to have a tough time convincing others that their option is the better option. If Oslo provides a technology that revolutionizes development, it seals the fate of many if not all PaaS platforms (i.e. "adapt or die"). This would mean that any power law effects that may exist would go in Microsoft's favor. Azure FTW.

Postlude: All of this was triggered by a Nick Carr observation of a
Jack Schofield story. I recommend highly reading both, as well as Governor's and Almaer's posts.

Tuesday, October 28, 2008

Why I Think CohesiveFT's VPN-Cubed Matters

You may have seen some news about CohesiveFT's new product today--in large part thanks the the excellent online marketing push they made in the days preceding the announcement. (I had a great conversation with Patrick Kerpan, their CTO.) Normally, I would get a little suspicious about how big a deal such an announcement really is, but I have to say this one may be for real. And so do others, like Krishnan Subramanian of CloudAve.

CohesiveFT's VPN-Cubed is targeting what I call "the last great frontier of the cloud", networking. Specifically, it is focusing a key problem--data security and control--in a unique way. The idea is that VPN-Cubed gives you software that allows you to create a VPN of sorts that is under your personal control, regardless of where the endpoints reside, on or off the cloud. Think of it as creating a private cloud network, capable of tying systems together across a plethora of cloud providers, as well as your own network.

The use case architecture is really very simple.

Diagram courtesy of CohesiveFT

VPNCubed Manager VMs are run in the network infrastructure that you wish to add to your cloud VPN. The manager then acts as a VPN gateway for the other VMs in that network, who can then communicate to other systems on the VPN via virtual NICs assigned to the VPN. I'll stop there, because networking is not my thing, but I will say it is important to note that this is a portable VPN infrastructure, which you can run on any compatible cloud, and CohesiveFT's business is to create images that will run on as many clouds as possible.

Patrick made a point of using the word "control" a lot in our conversation. I think this is where VPN-Cubed is a game changer. It is one of the first products I've seen target isolating your stuff in someone else's cloud, protecting access and encryption in a way that leaves you in command--assuming it works as advertised...and I have no reason to suspect otherwise.

Now, will this work with PaaS? No. SaaS? No. But if you are managing your applications in the cloud, even a hybrid cloud, and are concerned about network security, VPN-Cubed is worth a look.

What are the negatives here? Well, first I think VPN is a feature of a larger cloud network story. This is the first and only of its kind in the market, but I have a feeling other network vendors looking at this problem will address it in a more comprehensive solution.

Still, CohesiveFT has something here: it's simple, it is entirely under your control, and it serves a big immediate need. I think we'll see a lot more about this product as word gets out.

Monday, October 27, 2008

Even Microsoft is Cautious About the Legal State of the Cloud, and More

Tucked in a backwater paragraph of this interesting interview with Microsoft corporate VP Amitabh Srivastava is an interesting note about the prioritization and pacing for rollout of Azure into the various data centers Microsoft owns worldwide:
"Also, for now, Azure services will be running in a single Microsoft data center (the Quincy, Wash. facility). Sometime next year, Microsoft will expand that to other U.S. data centers and eventually move overseas, though that brings with it its own set of geopolitical issues that Srivastava said that the company would just as soon wait to tackle."
No kidding. Let's not even get into the unique legal challenges that Microsoft faces in the EU (perhaps especially because they are proposing a Windows-only cloud offering?). Just figuring out how to lay out the technical and business policies around data storage and code execution will be a thrill for the be-all, end-all PaaS offering that is Azure.

(On a side note, perhaps it presents a unique opportunity for regulation-aware infrastructure?)

There was one positive note in this interview, however. Apparently Microsoft has non-.NET code running internally on Azure, and will offer those services sometime next year. Furthermore, services must meet a template today, but template-independent services are currently on the roadmap. Perhaps a move from PaaS to IaaS is also in store?

Microsoft chooses the Azure PaaS to the Clouds

The Microsoft PDC2008 keynote presentation just concluded, and the team in Redmond announced Azure, a very full featured cloud PaaS allowing for almost the entire .NET stack to run in Microsoft's data centers, or on-premises at your organization. (The keynote will be available on-demand on the Microsoft PDC site.)

I find myself impressed, underwhelmed and, in fact, a little disappointed. Here's how that breaks down:

  • This is clearly the most full featured PaaS out there. Service frameworks, a service bus, identity, database services (both relational and unstructured), a full featured IDE integration. No one else is doing this much--not even Google.

  • I love the focus on hybrid implementations (both on-premesis and "in the cloud"). Software plus Services can really pay off here, as you look at the demonstrations give in the keynote.

  • The identity stuff is a key differentiator. Not your Live account, but whatever federated identity you are using.

  • They used an opportunity to announce a revolutionary change to Microsoft's technology and business to demonstrate how all the things people have already been doing in .NET can be shoehorned into the cloud. Product recalls? Really?

  • It started to sound like they would dig deep into architecture and radical new opportunities, but in the end they just showed off an awful lot of "gluing" existing products together. *Yawn*

  • Its PaaS. There is no Amazon-killer, no opportunity for the masses to leverage Microsoft data centers, no ability to deploy "raw" Windows applications into the cloud. Just a tool to force adoption of full scale .NET development and Microsoft products. Good for Microsoft, but will it win any converts?

  • I wanted more from Ray. I wanted a peek into a future that I never considered; an understanding of where it was that Microsoft's DNA was going to advance the science of the cloud, rather than just provide Microsoft's spin on it. With the possible exception of identity, I'm not sure I saw any of that.

So, a good announcement overall, but pretty much well within the bounds of expectations, perhaps even falling short in a couple of places. I can't wait to see how the market reacts to all of this.

By the way, Azure is only open to PDC2008 participants at first. The floodgates will slowly be opened over the next several months--in fact, no upper bound was given.

Friday, October 24, 2008

Is Amazon in Danger of Becoming the Walmart of the Cloud?

Update: Serious misspelling of Walmart throughout the post initially. If you are going to lean an argument heavily on the controversial actions of any entity, spell their name right. Mea culpa. Thanks to Thorsten von Eicken for the heads up.

Also, check out Thorsten's comment below. Perhaps all is not as bleak as I paint it here for established partners...I'm not entirely convinced this is true for the smaller independent projects, however.

I grew up in the great state of Iowa. After attending college in St. Paul, Minnesota, I returned to my home state where I worked as a computer support technician for Cornell College, a small liberal arts college in Mount Vernon, Iowa. It was a great gig, with plenty of funny stories. Ask me over drinks sometime.

While in Mount Vernon, there was a great controversy brewing--well, nation wide, really--amongst the rural towns and farm villages struggling to survive. You see, the tradition of the family farm was being devastated, and local downtowns were disappearing. Amidst this traumatic upheaval appeared a great beast, threatening to suck what little life was left out of small town retail businesses.

The threat, in one word, was Walmart.

Walmart is, and was, a brilliant company, and their success in retail is astounding. In a Walmart, one can find almost any household item one needs under a single roof, including in many cases groceries and other basic staples. Their purchasing power drives prices so low, that there was almost no way they can get undercut. If you have a WalMart in your area, it might find it the most logical place to go for just about anything you needed for your home.

That, though, was the problem in rural America. If a Walmart showed up in your area, all the local household goods stores, clothing stores, electronics stores and so on were instantly the higher price, lower selection option. Mom and Pop just couldn't compete, and downtown businesses disappeared almost overnight. The great lifestyle that rural Americans led with such pride was an innocent bystander to the pursuit of volume discounts.

Many of the farm towns in Iowa were on the lookout then, circa 1990, for any sign that Walmart might be moving in. (They still are, I guess.) When a store was proposed just outside of Cedar Rapids, on the road to Mount Vernon, all heck broke loose. There was strong lobbying on both sides, and businesses went on a media campaign to paint Walmart as a community killer. The local business community remained in conflict and turmoil for years on end while the store's location and development were negotiated.

(The concern about Walmart stores in the countryside is controversial. I will concede that not everyone objects to their building stores in rural areas. However, all of the retailers I knew in Mount Vernon did.)

If I remember correctly, Walmart backed off, but its been a long time. (Even now, they haven't given up entirely.)

While I admire Amazon and the Amazon Web Services team immensely, I worry that their quest to be the ultimate cloud computing provider might force them into a similar role on the Internet that Walmart played in rural America. As they pursue the drive to bring more and better functionality to those that buy their capacity, the one-time book retailer is finding themselves adding more and more features, expanding their coverage farther and farther afield from just core storage, network and compute capacity--pushing into the market territory of entrepreneurs who seized the opportunity to earn an income off the AWS community.

This week, Amazon may have crossed an invisible line.

With the announcement that they are adding not just a monitoring API, not just a monitoring console, but actual interactive management user interface, with load balancing and automated scaling services, Amazon is for the first time creeping into the territory held firm by the partners that benefited and benefited from Amazon's amazing story. The Sun is expanding into the path of its satellites, so to speak.

The list of the endangered potentially include innovative little projects like ElasticFox, Ylastic and Firefox S3, as well as major cloud players such as RightScale, Hyperic and EUCALYPTUS. These guys cut their teeth on Amazon's platform, and have built decent businesses/projects serving the AWS community.

Not that they all go away, mind you. RightScale and Hyperic, for example, support multiple clouds, and can even provide their services across disparate clouds. EUCALYPTUS was designed with multiple cloud simulations in mind. Furthermore, exactly what Amazon will and won't do for these erstwhile partners remains unclear. Its possible that this may work out well for everyone involved. Not likely, in my opinion, but possible.

Sure, these small shops can stay in business, but they now have to watch Amazon with a weary eye (if they weren't already doing that). There is no doubt that their market has been penetrated, and they have to be concerned about Amazon doing to them what Microsoft did to Netscape.

Or Walmart did to rural America.

Thursday, October 23, 2008

Amazon Enhances "The Proto-Cloud"

Big news today, as you've probably already seen. Amazon has announced a series of steps to greatly enhance the "production" nature of its already leading edge cloud computing services, including (quoted directly from Jeff Barr's post on the AWS blog):
  • Linux on Amazon EC2 is now in full production. The beta label is gone.
  • There's now an SLA (Service Level Agreement) for EC2.
  • Microsoft Windows is now available in beta form on EC2.
  • Microsoft SQL Server is now available in beta form on EC2.
  • We plan to release an interactive AWS management console.
  • We plan to release new load balancing, automatic scaling, and cloud monitoring services.
There is some great coverage of the announcement already in the blog-o-sphere, so I won't repeat the basics here. Suffice to say:
  • Removing the beta label removes a barrier to S3/EC2 adoption for the most conservative of organizations.
  • The SLA is interestingly organized to both allow for pockets of outages while promoting global up-time. Make no mistake, though, some automation is required to make sure your systems find the working Amazon infrastructure when specific Availability Zones fail.
  • Oh, wait, they took care of that as well...along with automatic scaling and load balancing.
  • Microsoft is quickly becoming a first class player in AWS, which removes yet another barrier for M$FT happy organizations.
Instead, let me focus in this post on how all of this enhances Amazon's status as the "reference platform" for infrastructure as a service (IaaS). In another post, I want to express my concern that Amazon runs the danger of becoming the "WallMart" of cloud computing.

First, why is it that Amazon is leading the way so aggressively in terms of feature sets and service offerings for cloud computing? Why does it seem that every other cloud provider seems to be catching up to the services being offered by Amazon at any given time? For example:
The answer in all cases is because Amazon has become the default standard for IaaS feature definition--this despite having no user interface of their own (besides command line and REST), and using "special" Linux images (the core Amazon Machine Images) that don't provide root access, etc. The reason for the success in setting the standard here is simple: from the beginning, Amazon has focused on prioritizing feature delivery based on barriers to adoption of AWS, rather than on building the very best of any given feature.

Here's how I see it:
  • In the beginning, there was storage and network access. Enter S3.
  • Then there were virtual servers to do computational tasks. Enter EC2, but with only one server size.
  • Then there were significant complaints that the server size wasn't big enough to handle real world tasks. Enter additional server types (e.g. "Large") and associated pricing
  • Then there was the need for "queryable" data storage. Enter SimpleDB.
  • Somewhere in the preceding time frame, the need for messaging services was identified as a barrier. Enter Amazon Simple Queue Service.
  • Now people were beginning to do serious tasks with EC2/S3/etc., so the issues of geographic placement of data and workloads became more of a concern. (This placement was both for geographic fail over, and to address regulatory concerns.) Enter Availability Zones.
  • Soon after that, delivering content and data between the zones became a serious concern (especially with all of the web start ups leveraging EC2/S3/etc.) Enter the announced AWS Content Delivery Service
  • Throw in there various partnership announcements, including support for MySQL and Oracle.
By this point, hundreds of companies had "production" applications or jobs running on Amazon infrastructure, and it became time to decide how serious this was. In my not-so-humble opinion, the floundering economy, its effects on the Amazon retail business, and the predictions that cloud computing could benefit from a weakened economy fed into the decision that its time to remove the training wheels and leave "beta" status for good. Add an official SLA, remove the "beta" label, and "BAM!", you suddenly have a new "production" business to offset the retail side of the house.

Given that everyone else was playing catchup to these features as they came out (mostly because competitors didn't realize what they needed to do next, as they didn't have the customer base to draw from), it is not surprising that Amazon now looks like they are miles ahead of any competitor when it comes to number of customers and (for cloud computing services) probably revenue.

How do you keep the competitors playing catchup? Add more features. How do you select which features to address next? Check with the customer base to see what their biggest concerns are. This time, the low hanging fruit was the management interface, monitoring, and automation. Oh, and that little Windows platform-thingy.

Now, I find it curious that they've pre-announced the monitoring and management stuff today. Amazon isn't really in the habit of announcing a feature before they go private-beta. However, I think there is some concern that they were becoming the "command-line lover's cloud", and had to show some interest in competing with the likes of VirtualCenter in the mind's eye of system administrators. So, to undercut some perceived competitive advantages from folks like GoGrid and Slicehost, they tell their prospects and customers "just give us a second here and we will do you right".

I think the AWS team has been brilliant, both in terms of marketing and in terms of technology planning and development. They remain the dominant team, in my opinion, though there are certainly plenty of viable alternatives out there that you should not be shy of both in conjunction with and in place of Amazon. Jeff Barr, Werner Vogels and others have proven that a business model that so many other IT organizations failed at miserably could be done extremely well. I just hope they don't get too far ahead of I'll discuss separately.

Monday, October 20, 2008

Google AppEngine to Support Java and JavaScript--Soon?

Thanks to Luis Sala, I was alerted tonight to one of the really big rumors working its way through the "cloud-o-sphere". Apparently, it was officially stated that Google AppEngine will be supporting Java, and (via Rhino) JavaScript at a recent Google event in India, with an official launch coming as soon as this week (that last part is pure rumor, however). I haven't seen any hints of an announcement party as of yet, but it seems the Google staff are already talking about it, and feeding the rumor mill.

This is big for many, many reasons, not the least of which is the challenge that Google must face in supporting a language that is so challenged at running in a modular fashion. I will be extremely curious to see if the announcement includes OSGi (or, god help us, JSR-277) as a way to mitigate the difficulties in "mashing up" different applications, services and libraries in the same VM. Alternatively, like the Python implementation of AppEngine, it could just be that a restrictive set of Google libraries will be required, which in turn dictate which versions of core common libraries are used in any given application. The former would allow for a wider variety of applications, but the latter is far more likely, in my opinion.

Will any old Java-compatible library not considered "common" be importable, I wonder? How will they achieve the same balance of control and flexibility they achieved with Python? Somehow, I don't find myself concerned that the end product will have any serious bugs, just that there will be hidden restrictions that most Java developers will find annoying at first.

At the very least, I think we can anticipate that the Java architecture on AppEngine will closely align with the Python architecture, meaning all data access will be BigTable, etc. So the same pros and cons will apply to AppEngine whether you use Java, JavaScript or Python. Which still leaves an amazingly large market for Google to grab in the PaaS space.

Hey, Google, if you do have a launch party, I would certainly love an invitation...

Saturday, October 18, 2008

The Significance of the Cloud Proxy

There is a dirty little secret about the current spate of cloud computing storage offerings out there today. Yeah, they are a powerful alternative to buying your own disks and filers or SANs, but to use them--pretty much any of them--you need some development skillz. Not "deep and ugly" systems programming skills, mind you, but certainly these basics:
  • Ability to read a REST API specification
  • Ability to build a URL to meet said specification
  • In almost all cases, ability to write a script or program that hides building said URL from humans using the storage service
This is fine if you are hiding the use of a cloud storage service behind the facade of some application or other. However, what if you want to make "infinite" storage available to the masses? How do you let your everyday Windows or Mac user simply connect their system to a cloud storage drive?

The easiest way for desktop OS users to access traditional shared storage today is by mounting a shared network drive, through whatever mechanism is provided by the OSes basic file system interface. Once the drive is mounted, it behaves just like any other network or local drive, with the same commands to navigate, augment and utilize the file system as any other file system. Why couldn't getting access to storage in the cloud be just that easy?

Enter a new offering from Nirvanix, announced a couple of weeks ago. Nirvanix CloudNAS is basically a simple program that you install on the "pizza box" of your choice. However, what that software does is huge, in my opinion. Basically, it provides a simple proxy to the Nirvanix Storage Delivery Network, their brand name for their cloud computing storage service. This proxy offers three incredibly common and appropriate standard interfaces for desktop users to utilize: CIFS, NFS and FTP.

So now, with one of these pizza boxes installed inside your firewall, with the appropriate secure connections (I would hope) to the Nirvanix cloud through said firewall, any user can locate the "network drive", mount it in their local file system, and start using it from ANY application that already recognizes the OS file system--which is anything that reads and/or writes files--to utilize that drive. No programming, no "learn this new interface", just a shared drive mapped to your "N:" drive (or some such thing).

This is a concept near and dear to my heart, as a similar approach towards content repository access is offered from my employer, Alfresco. Say you have 1000 MS Office users out there, and you want to carefully track certain documents which they are maintaining:
  • You could give them some sort of plug-in to install into each and every application, but that would cost you--especially of you have dozens of different applicable applications.

  • You could give the users a new web application that they would use to "upload" documents to the repository outside of the existing application interfaces, but that would probably lead to much confusion and misuse.

  • You could use Alfresco's CIFS interface to mount a shared drive on each user's desktop, with an agreed upon folder structure for the documents being edited, and simple instructions to maintain the document on the "Alfresco" drive.

In other words, Alfresco and Nirvanix are using CIFS, NFS and FTP (as well as WebDAV in Alfresco's case) to "instantly" integrate any file system aware application with their respective offerings.

I loved this concept when Alfresco explained it to me, and I may love it even more in Nirvanix's case. With one simple announcement, they've completely differentiated themselves from Amazon S3, in that this is now a data center friendly (not just a developer friendly) cloud storage service. Almost any user in the enterprise can quickly and easily be connected to the cloud, and near infinite storage is at their fingertips. Best of all, the software download is free.

(Truth be told, the reality is probably less sexy than the vision. Latency will certainly be a concern, as will the availability of Nirvanix services over the Internet. While I am positive about the vision, I would sure as heck do my due diligence before implementing a project that relied on CloudNAS.)

There are a lot of smart people thinking about cloud computing these days. I expect to see this "proxy" concept copied by several other vendors. I could see a Google AppEngine "proxy" that hosts the development bits and automated "push" of final bits to the Google cloud. I could see a "hybrid" cloud management proxy, perhaps from someone like RightScale or Cassatt or one of the new Cloud OS offerings, that manages application and service provisioning both intra- and extra-enterprise.

These are the innovations that I think are most exciting these days. Not a new API, or a new "do it yourself" network service, but integrations into the "traditional" IT technologies in ways that are as transparent as possible to end users and system administrators alike. Good luck to Nirvanix. I think they have something here.

Update: InformationWeek has an excellent article covering five "good deals" for the use of cloud storage, and three "risky propositions". Cloud NAS is listed as one of the good deals.

Wednesday, October 15, 2008

Cloud Summit Executive: Making "Pay-As-You-Go" Customers Happy

I got to spend a few hours yesterday at the Cloud Summit Executive conference at the Computer History Museum in Mountain View, California, today. The Summit was unique, at least in the Bay Area, for its focus on the business side of cloud computing. The networking was quite good, with a variety of CxOs digging into what the opportunities and challenges are for both customers and providers. The feedback that I got from those that attended the entire day was that the summit opened eyes and expanded minds.

Ken Oestreich has great coverage of the full summit.

I attended the afternoon keynotes, which started with a presentation from SAP CTO Vishal Sikka which seemed at first like the usual fluff about how global enterprise markets will be addressed by SaaS (read "SAP is the answer"). However, Vishal managed to weave in an important message about how the cloud will initially make some things worse, namely integration and data integrity. Elasticity, he noted, is the key selling point of the cloud right now, and it will be required to meet the needs of a heterogeneous world. Software vendors, pay attention to that.

For me, the highlight of the conference was a panel led by David Berlind at TechWeb, consisting of Art Wittmann of Information Week, Carolyn Lawson, CIO of the California Public Utilities Commission, and Anthony Hill, CIO of Golden Gate University. Ken covers the basic discussion quite well, but I took something away from the comments that he missed: both CIOs seemed to be in agreement that the contractual agreement between cloud customer and cloud provider should be different than those normally seen in the managed hosting world. Instead of being service level agreement (SLA) driven, cloud agreements should base termination rights strictly on customer satisfaction.

This was eye opening for me, as I had always focused on service level automation as the way to manage up time and performance in the cloud. I just assumed that the business relationship between customer and provider would include distinct service level agreements. However, Hill was adamant that his best SaaS relationships were those that gave him both subscription (or pay-as-you-use) pricing and the right to terminate the agreement for any reason with 30 days notice.

Why would any vendor agree to this? As Hill points out, it's because it gives the feeling of control to the customer, without giving up any of the real barriers to termination that the customer has today; the most important of which is the cost of migrating off of the provider's service. Carolyn generalized the benefits of concepts like this beautifully when she said something to the effect of
"The cloud vendor community has to understand what [using an off premises cloud service] looks like to me -- it feels like a free fall. I can't touch things like I can in my own data center (e.g. AC, racks, power monitors, etc.), I can't yell at people who report to me. Give me a sense of control; give me options if something goes wrong."
In other words, base service success on customer satisfaction, and provide options if something goes wrong.

What a beautifully concise way to put a very heart felt need of most cloud consumers--control over their company's IT destiny. By providing different ways that a customer can handle unexpected situations, a cloud provider is signaling that they honor who the ultimate boss is in a cloud computing transaction--the customer.

Hill loved his 30 day notice for termination clause with one of his vendors, and I can see why. Not because he expects to use it, but because it let's him and the vendor know that Golden Gate University has decision making power, and the cloud vendor serves at the pleasure of Golden Gate University, not the other way around.

Saturday, October 11, 2008

The PaaS Spectrum: Choosing Your Coding Cloud

Platform as a Service is a fascinating space to me. As I noted in one of my reviews of Google AppEngine when it was released, there is a certain development experience that comes with a good distributed platform that understands both simple development-test cycles, yet also reduces the complexity of delivering highly scalable and reliable applications to a complex data center. With the right platform, and there are many, a development team can leapfrog the hours of pain and effort required to stitch together hardware, software, networking and storage to create a bulletproof web application.

At Cloud Camp Silicon Valley earlier this month, a group of us discussed this in some depth. A crowd of about thirty assorted representatives of cloud vendors and customers alike engaged in a lively discussion of what the elements of cloud oriented architectures are, and how one chooses the right architecture.

I spoke (perhaps too much) about software fluidity, and it was noted that many PaaS platforms limit that fluidity, rather than enable it. Think Google AppEngine or or Bungee Connect. Great products, but not exactly built to make your application portable and dynamic. (Google and others are open sourcing all or part of their platforms, but the ecosystem to port applications isn't there yet. See below.) So, the conclusion went, perhaps you choose some PaaS offerings when time-to-market was the central tenet of your project, not portability. Others (possibly including IaaS, if you want to be technical) make sense when portability is your primary concern, but you'll have to do more work to get your application out the door.

This creates a spectrum on which PaaS offerings would fall:

This makes perfect sense to me. Choose to use an "all-in-one" platform from a single software+service+infrastructure vendor, and they can hide much of the complexity of coding, deploying and operating your application from you. On the other hand, select an infrastructure-only vendor using "standard" OS images (typically based on one of the major linux distros) but little else, and you can port your applications to your hearts content, but you'll have to do all of the configuration of database connection, middleware memory parameters, etc. yourself. Many platforms will lie somewhere in the middle of this spectrum, but the differences between the edges is striking, and most platforms will fall towards one end or the other.

For an example of a relatively "extreme right" platform, take a look at, the application platform provided by, and tied closely to,, and its APEX language. How much do they provide in the way of productivity? Well, Rich Unger, an engineer at (and one of the participants in the CloudCamp SV discussion), has an excellent blog that covers APEX. Here's one example that he gives:
"Database operations don't have to establish a connection (much less manage a connection pool) [in APEX]. Also, the object-relational mapping is built into the language. It's even statically typed. Let's say you want the first and last names of all your contacts. In Java, there are many ways to set this up, depending on whether you're using JPA, straight JDBC, entity beans, etc. In general, you must to at least these four things:

  1. Write an entity class, and annotate it or map it to a DB table in an xml file
  2. Configure the DB and connection pool
  3. acquire a connection in the client code
  4. Perform the query

In Apex, you'd do just do #4:

Contact[] mycontacts = [select firstname, lastname from Contact];
for (Contact c : mycontacts) {
System.debug(c.firstname + ' ' + c.lastname);

That's it. You could even shorten this by putting the query right into the for loop. The language knows how to connect to the DB. There's no configuration involved. I'm not hiding any XML files. Contact is a standard data type. If you wanted a custom data type, you'd configure that through the UI (no coding). Adding the new type to the DB automatically configures the O-R mapping. Furthermore, if you tried:

Account[] myaccounts = [select firstname, lastname from Contact]; wouldn't even compile. Static typing right on down to the query. Try that by passing strings into Jdbc!"

Freakin' brilliant! That is, as long as you wanted to write an application that used the databases and ran on the infrastructure. Not code that you can run on AppEngine or EC2.

On the other hand, I've been working with GoGrid for a little while getting Alfresco to run in a clustered configuration on their standard images. It has been amazing, and helped along both by the fact that GoGrid gives you root access to the virtual server (very cool!), and that the standard Alfresco Enterprise download (trial version available for free) contains a Tomcat instance, and installs with a tar command, a single properties file change and a database script. So, combine a CentOS 64-bit image with Alfresco 2.2 Enterprise, make sure iptables has port 8080 open, and away you go. The best thing is that--in theory--I should be able to grab the relevant files from that CentOS image, copy them to a similar image on, say, Flexiscale, and be up and running in minutes. However, I did have to manage some very techie things; I had to edit iptables, for instance, and know how to confirm that I had the right Java version for Tomcat.

By the way, long term operational issues are similarly affected by your choice of PaaS provider. If you have root access to the server, you must handle a measurable percentage of issues that are driven by configuration changes over time in your system. On the other hand, if your code is running on a complete stack that the vendor maintains for backward compatibility, and that hides configuration issues from you at the get-go, you may not have to do much of anything to keep your system running at reasonable service levels.

Today, the choice is up to you.

I wonder, though, if this spectrum has to be so spread out. For example, as I wrote recently, I see a huge opportunity for application middleware vendors, such as GigaSpaces, BEA and JBOSS, to provide a "portability layer" that would allow both reduced configuration on prebuilt app server/OS images, but at the same time allow the application on top of the app server to be portable to just about any instance of that server in the cloud. (There would likely be more configuration required on the middleware option than the APEX example earlier. For instance, the application server and/or application itself would have to be "pointed" to the database server.)

Google AppEngine should, in theory, be on this list. However, while they open sourced the API and development "simulator", they have not provided source to the true middleware itself--the so-called Google "magic dust". Implementing a truly scalable alternative AppEngine platform is an exercise left up to the reader. Has anyone built a true alternative AppEngine-compatible infrastructure yet? I hear rumors of what's to come, but as far as I know, nothing exists today. So, AppEngine is not yet portable. To be fair, there is no JBOSS "cloud edition" yet, either. GigaSpaces is the only vendor I've seen actively pursue this route.

While we are waiting for more flexible options, you are left with a choice to make. Do you need it now at all costs? Do you need it portable at all costs? Or do you need something in between? Where you fall in the PaaS spectrum is entirely up to you.

Wednesday, October 08, 2008

Two More Sources of Cloud Computing News You May Not Have Heard About

I recently posted on "9 Sources of Cloud Computing News You May Not Know About", providing you with a list of my favorite "short cuts" to keeping up on the cloud computing marketplace. I'd like to quickly add two more to the list:
  • CloudAve CloudNews posts: I'm still getting a feel for the long term direction that the folks at CloudAve are taking, but this category of posts provides a steady stream of industry news, mostly focused on vendor activities. There is a good mix of cloud infrastructure, SaaS and others markets covered here, and the commentary added to each link is an added feature for quick browsing.

  • Twitter Search: I leave a tab open in my browser now with the single word, "cloud", active in Twitter Search. This page has a nice feature in which it indicates how many more recent tweets there are available since the last time you reloaded. What's great about this is that you get a feel for the pace of traffic, which can help you identify a big story breaking. I also like the fact that little known bloggers and authors can make their content known to me this way. This is quickly becoming my favorite way to find unusual opinions on--and visions for--the cloud.

Tuesday, October 07, 2008

VMWare's Most Important Cloud Research? It Might Not Be Technology

I was kind of aimlessly wandering around my Google Reader feeds the other day when I came across an interview with Carl Eschenbach, VMWare's executive vice president of worldwide field operations, titled "Q&A: VMware's Eschenbach Outlines Channel Opportunities In The Virtual Cloud". (Thanks to Rich Miller of Telematique for the link.) I started reading the article thinking it was going to be all about how to sell vCloud, but throughout the article, it was painfully clear that a hybrid cloud concept will cause some real disruption in the VMWare channel.

The core problem is this:
  1. Today, VMWare solution providers enjoy tremendous margins selling not only VMWare products, but associated services (often 5 to 7 times the revenue in services than software), and server, storage and networking hardware required to support a virtualized data center.

  2. However, vCloud introduces the concept of offloading some of that computing to a capacity service provider, in a relationship where the solution provider acts merely as a middleman for the initial transaction.

  3. Ostensibly, the solution provider then gets a one time fee, but is squeezed out of recurring revenue for the service.

In other words, VMWare's channel is not necessarily pumped about the advent of cloud computing.

To Eschenbach's credit, he acknowledges that this could be the case:
"We think there's a potential. And we're doing some studies right now with some of our larger solution providers, looking at whether there's a possibility that they not only sell VMware SKUs into the enterprise, but if that enterprise customer wants to take advantage of cloud computing from a service provider that our VARs, our resellers, actually sell the service providers' SKUs. So, not only are they selling into the enterprise data center, but now if that customer wants to take advantage of additional capacity that exists outside the four walls of the data center, why couldn't our solution providers, our VIP resellers, resell a SKU that Verizon (NYSE:VZ) or Savvis or SunGard or BT is offering into that customer. So they can have the capability of selling into the enterprise cloud and the service provider cloud on two different SKUs and still maintain the relationship with the customer. "
In a follow up question, Eschenbach declares:
"[I]t's not a lot different from a solution provider today selling into an account a VMware license that's perpetual. Now, if you're selling a perpetual license and you're moving away from that and [your customer is] buying capacity on demand from the cloud, every time they need to do that, if they have an arrangement through a VAR or a solution provider to get access to that capacity, and they're buying the SKU from them, they're still engaged. "
Does anyone else get the feeling that Eschenbach is talking about turning solution providers into cloud capacity brokerages? Furthermore, that such a solution provider now acts as a very inefficient capacity brokerage? Specifically, choosing the service that provides them with the best margins and locking customers into those providers, instead of the service that gives the customer the most bang for the buck on any given day? Doesn't this create an even better opportunity for the more pure, independent cloud brokerages to sell terms and pricing that favor the customer?

I think VMWare may have a real issue on their hands, in which maintaining their amazing ecosystem of implementation partners may give way to more direct partnerships with specific cloud brokerages (for capacity) and system integrators (for consultative advice on optimizing between private and commercial capacity). The traditional infrastructure VAR gets left in the dust.

Part of the problem is that traditional IT service needs are often "apples and oranges" to online-based cloud computing needs. Serving traditional IT allows for specialization based on region and industry. In both cases, the business opportunity is on site implementation of a particular service or application system. Everyone has to do it that way, so every business that goes digital (and eventually they all have) needs these services in full.

The cloud now dilutes that opportunity. If the hardware doesn't run on site, there is no opportunity to sell installation services. If the software is purchased as SaaS, there is no opportunity to sell instances of turnkey systems and the services to install and configure that software. If the operations are handled largely by a faceless organization in a cloud capacity provider, there is no opportunity to sell system administration or runbook services for that capacity. If revenue is largely recurring, there is no significant one-time "payday" for selling someone else's capacity.

So the big money opportunity for service providers in the cloud is strategic, with just a small amount of tactical work to go around.

One possible exception, however, is system management software and hardware. In this case, I believe that customers need to consider owning their own service level automation systems and to monitor the conditions of all software they have running anywhere, either behind or outside of their own firewalls. There is a turnkey opportunity here, and I know many of the cloud infrastructure providers are talking appliance these days for that purpose. Installing and configuring these appliances is going to take specific expertise that should grow in demand over the next decade.

Unless innovative vendors such as RightScale and CohesiveFT kill that opportunity, too.

I know I've seen references by others to this channel problem. (In fact, Eschenbach's interview also raised red flags for Alessandro Perilli of On the other hand, others are optimistic it creates opportunity. So maybe I'm just being paranoid. However, if I was a solution provider with my wagon hitched to VMWare's star, I'd be thinking really hard about what my company will look like five years from now. And if I'm a customer, I'd be looking closely at how I will be acquiring compute capacity in the same time frame.

Saturday, October 04, 2008

GigaSpaces introduces portable PaaS

Update: Geva Perry clarified what exactly Gigaspaces "cloud framework" is all about on his blog.

I find GigaSpaces one of the more interesting middleware plays out there, with a unique "in memory" scaling model, and support for a wide variety of standard Java implementations. Today (on a Saturday?...really?...) GigaSpaces announces availability of their core product, Gigaspaces Application Server, on EC2.

Why is this interesting? Because you can also get Gigaspaces for your own data center--private cloud or not. And, according to Dekel's post linked above, they are actively pursuing similar stories for a variety of other vendors:
"This framework is designed specifically for cloud portability. EC2 is only the exciting beginning and expect CohesiveFT, Flexiscale, GoGrid, Joyent, RightScale and more to follow soon."
So, while there is (I would assume) some risk of coupling yourself to Gigaspaces when you write and deploy an application on the platform, in terms of infrastructure, on the other hand you can (or soon can) port away.

I haven't used GigaSpaces yet, but I would love to see many more application servers take this route, as well as introduce related development tool images that can be easily replicated to private servers. This makes the Google AppEngine story a little less unique, as anyone can get a development platform that scales (if it done right), without betting the farm on one company's compute capacity. I would especially like to see the open source vendors (ahem) concentrate on this for the coming year.

I'd love to hear from any of the private beta folks that have something interesting to say. Are you porting an existing GigaSpaces app to EC2? Are you porting an existing Java application to GigaSpaces and EC2? What are the perceived benefits of using EC2 instead of your own infrastructure at this point? How are you managing the deployment and monitoring of your applications in EC2?

I wish all the best to Geva Perry, Dekel and the rest of the GigaSpaces team.

Thursday, October 02, 2008

Cracks in the Clouds, but the Sky Ain't Fallin'

Update: I accidentally left off the reference links in the first paragraph. This is corrected now. My apologies to all that were inconvenienced.

This last couple of weeks have been filled with challenges to those preaching the gospel of cloud computing. First it was a paper delivered by three Microsoft researchers describing in detail the advantages of small, geo-diverse, distributed data center designs over "mega-datacenters", a true blow to the strategy of many a cloud provider and--frankly--large enterprise. Second, the Wall Street Journal published a direct indictment of the term, cloud computing, in which Ben Worthen carefully explains how the term ended up well beyond the boundaries of meaning. Added to the dog pile was Larry Elison's apparently delightful rant about the meaninglessness of the term, and an apparent quote where he doubts the business model of providing capacity at scale for less than a customer could do it on their own.

Frankly, I think there's some truth to the notion that cloud computing and many of the notions that people have about it are beginning to lose their luster. We seem to have passed through a tollgate of late, from the honeymoon era of "cloud computing will save the world" to the evolutionary phase of "oh, crud, we now have to make this stuff work". While the marketing continues unabated, there are some stories creeping out of "cloud-o-sphere" of realizations about the economics and technical realities of dynamically offloading compute capacity. Solutions are being explored to "the little things" that support the big picture: monitoring, management (both system and people) and provisioning. Gaps are being identified, and business models are being criticized. We are all coming to the conclusion that there is a heck of a lot of work left to be done here.

Doubt me? Take a look at the following examples of "oh, crud" moments of the past few months:
  • I can't for the life of me find the link, but about three months ago I read a quote from one of the recent successful Amazon EC2-based start ups noting that as their traffic and user base grows, they believe the economics of using the cloud will change, and moving some core capacity to a private cloud might make more sense.

    Update: John M Willis pointed me to the reference; a quote from item 8 of his "10 Reasons for NOT Using a Cloud" post, which in turn references a Cloud Cafe podcast in which "Brad Jefferson the CEO of Animoto suggested at some point he might actually flip the cloud." Read the post and listen to the podcast for more. Thanks, John.

  • Mediafed's Alan Williamson presents a keynote at CloudCamp London in July in which he notes that "[w]e’ve come to realize we cannot rely on putting all our eggs in one basket”, and shows off their dual-provider architecture utilizing Amazon EC2 and Flexiscale.

  • A court case in the United States demonstrates the legal perils that still have to be navigated in terms of constitutional protections and legal rights for those that place data in the cloud. This case goes to prove that too much depends on the Terms of Service of the providers today to provide a consistent basis for placing sensitive data in the cloud. Even mighty Amazon cannot be trusted to run a business infrastructure alone.

Some are even hinting that cloud computing is stupid, and that it will fail to be the disruptive technology it is touted as being.

That last statement is where I part ways with the critics. Cloud computing--all of it, public and private--will be disruptive to the way IT departments acquire and allocate compute functionality and capacity. To me, this statement is true whether or not it turns out that it would be better to build 500 small, manageable, container based data centers than 5 megaliths. It will be true even if the term gets used to describe anti-virus software. There is great momentum pushing us towards huge gains in IT efficiency, and it makes little economic sense not to follow through on that. Like any complex system, there will be winners and losers, but the winners will strengthen the system overall.

Here's where I see winning technologies developing in the cloud:
  • "Cloudbursting" - This is the most logical initial use of the cloud by most enterprises; grabbing spare capacity on a short term basis when owned capacity is maxed out. It virtually eliminates the pressure to predict peak load accurately, and gives enterprises a "buffer zone" should they need to scale up resources for an application.

  • Cloud OS - The data center is becoming a unit of computing in and of itself, and as such, it needs an OS. However, the ultimate vision for such an OS is to grow beyond the borders of a single data center, or even a single organization, and allow automated, dynamic resource location and allocation across the globe from an open market system. That's the goal, anyway...

  • SaaS/PaaS - Most of my readers will know the SaaS debate inside and out: is it better to take advantage of the agile and economic nature of online applications, or is it both safer and, perhaps, cheaper in the long term to keep things in house? I think SaaS is winning converts every day and will likely win nearly everyone for some applications. PaaS gives you the same quick/cheap start up economics as SaaS, but for software development and deployment infrastructure. I'll post more on PaaS soon.

  • Mashups/WOA - Much has been said of late about the successes of loosely coupled REST-style Internet integrations using published URL-based APIs over the traditional "contract heavy" SOAP/WS-* world. It makes sense. Most applications don't need RMI contracts if all they are trying to do is retrieve data to recombine with other into new forms. If it remains as easy as it has been for the last five years or so, mashups will be an expected component of most web apps, not an exceptional one.

  • "Quick start" data centers and data center modules - Between private clouds made of fail-in-place data centers in shipping containers, and powerful Infrastructure as a Service offerings from the likes of GoGrid, Flexiscale, Amazon and others, both startups and large enterprises have new ways to quickly acquire, scale up and optimize IT capacity. Acquiring that capacity by traditional ways is starting to look inefficient (even though I have seen no proof that this is so, as of yet).

Even if it never makes sense for a single Fortune 500 company to shut down all of their data centers, there will be a permanent change to the way IT operations are run--a change focused at optimizing the use of hardware to meet increasing service demands. Accounting for IT will change forever, as OpEx becomes dominant over CapEx, and flexibility is the name of the game. Capacity planning is changed forever, as developers can grab capacity from the corporate pool, watch the system utilization as demand grows, tuning the application as needed, adding hardware only when justified by trend analysis. Start up economics are changed forever, as building new applications that require large amounts of infrastructure no longer requires infrastructure investment.

CloudCamp SV demonstrated to me that the intellectual investment in cloud computing far surpasses mere marketing, and includes real technologies, architectures and business models that will keep up on our toes for the next few years.

Wednesday, October 01, 2008

Amazon Adds Windows Server to EC2

Hours after CloudCamp SV ended, Amazon's Werner Vogel blogged and tweeted some huge news: Amazon just went to private beta with Windows Server instances for EC2, including the ability to run several Windows Media codexes for hosting video and audio. Apparently the entertainment industry was waiting for this with baited breath. However,there is clearly a huge ASP.NET audience to be won here, as well.

Congratulations to the Amazon team, and I'll have more to say about this in the coming days.