If your business is producing Web sites, then it’s all too easy to assume that the way you innovate is by producing bigger, broader, more content. When you consider the platform as something that exists only on the client side – where the customer determines the scheme and not you – any functionality you create becomes a slave to the browser, the runtime and the operating system. And your business model maintains its 1995 profile. Standards attempt to ameliorate this dilemma, but as the HTML5 process demonstrates, such attempts may last decades.
If you’re an applications developer, then your business is to deliver service. In that case, you have a life-altering choice to make: Do you deliver all your functionality to your client and count on it to be executed there in its entirety, or do you let some or all of it be executed on a server in what your customers are calling the “cloud”?
What the Cloud Is, For Real
The reasons why the tablet form factor has taken the world by storm now, when it failed to do so in 2007, 2002, 1997 and 1992, are both obvious and harder to explain. The obvious reason is Apple’s runaway success in design, distribution and marketing. But a less obvious but no less important reason is that the cost of bandwidth has dropped and the availability of it has risen, making it possible to deliver a greater level of functionality than can be provided by the device’s processor alone.
That has fundamentally changed computing’s value proposition. Just a few days ago, I visited a Staples outlet where, inside the big bargain can in the center of the store, I found a multi-disk 2000s-era U.S/Canada street mapping program that once sold in the triple digits. It was selling for five bucks. To make it even more poignant, I had seen the exact same box, with the very same Post-It note listing the same discount price, in the same bargain can three years ago. Imagine how many hundreds of customers rejected this poor box as a relic from another era (like a rainbow leg-warmer or a moderate Republican).
The way we use functionality has changed so fundamentally, so swiftly and cleanly, that it takes a $5 box of outmoded DVDs that are three years old to drive the point home: The Internet is becoming a network of terminals, just as engineers dreamed in the mid-1960s. Web technology is making those terminals portable and transferrable between devices. So your entitlement to functionality or apps may no longer depend upon your browser, runtime or operating system. The statements consumers make today about the diminishing differences between a Mac and a PC will soon be made about the differences between Android, iOS and Windows Phones. The apps will become portable and adaptable between them. When that happens, much of the subject matter that constitutes today’s “tech news” will cease to be relevant.
What will remain relevant is how you get your functionality. People still tend to think of applications, or apps, in the context of their client-side profile. For example, you’ve probably seen the debates over so-called “native apps” versus “Web apps,” which are centered around the differences between designing a program specifically for one class of device (e.g., iOS apps purchased through iTunes or Android apps acquired via Google Play) versus designing it using HTML5 to be more device-agnostic. While the latter is often associated with a more open-minded, politically correct stance, as more applications are delivered as cloud-based services, the distinctions become less relevant. If a Windows 8 user in 2013 installs an app on her Start screen and the same app on her Android phone, as long as that app does its job, the identity or ownership of the language it’s written in may not matter a hill of beans to the consumer.
However, if that app fails to do its job on all devices, the consumer may blame the cloud platform that delivers it instead of her phone. This is why we need to take stock of the emerging landscape of server-driven computing, which is transcending and sublimating the Web.
Can’t tell the players without a scorecard
Again, what qualifies an app as a “cloud app” is the fact that it performs its job on the server and delivers results to the client – as opposed to producing a program for the key functionality that the client then executes. Apple’s Siri is a prime example of a cloud app – your iPhone doesn’t process your verbal commands, Apple’s servers do. Apple doesn’t sell Siri as a “SaaS application” or a “cloud service platform,” because it doesn’t need to. It’s a feature of iPhones, and that’s good enough.
A “cloud platform” is a broader concept. Just as the inventors of the BASIC programming language conceived a half-century ago, cloud platforms (sometimes called “PaaS, or Platform as a Service,” because developers simply cannot become cool to save their lives) process language code on behalf of clients and deliver results to them through the network. Because this business is so new and evolving so quickly, it’s impossible to use conventional metrics to say who’s the leader in this field just yet. But there are many prominent players, some of whom you’ve heard of, some of whom you haven’t.
The reason cloud platforms are growing in importance is because they are highly fertile ecosystems for creating, distributing and selling functionality – apps that customers install and that have explicit functions. Each platform has the potential for skyrocketing performance – for joining iTunes in the stratosphere.
Among the central players of all sizes making sizable waves in this new and critical market are these (in order of alphabet, not importance):
- CloudBees is a deployment platform specifically for Java apps, whose principal value proposition comes from the inclusion of management services. For example, CloudBees has tools for large development groups to manage the creation process; then post-deployment, the company offers Jenkins-branded maintenance services, such as helpdesks for customers.
- Cloud Foundry is an innovative, multi-language platform that is officially open source, but whose caretaker is virtualization leader VMware. Development takes place in Java (with Spring and Grails frameworks), Ruby (with the Rails framework), Node.js, or Scala (a highly scalable, statically typed derivative of Java), all on a VMware “micro” virtual machine hosted locally. Deployment becomes an automated matter of moving the apps from the local VM to a cloud-based VM. One of Cloud Foundry’s key value points is that the form of the application is not tied to the platform, so developers have the freedom of moving it to other platforms, including those they may host themselves.
- DotCloud is an independent, multi-language platform that boasts simple, command-line-based deployment of apps and databases using Amazon’s AWS cloud. Its value proposition includes flat monthly fees instead of consumption-based metering.
- Elastic Beanstalk is operated by AmazonWeb Services, the undisputed cloud infrastructure leader. It’s essentially an automated deployment system for .NET, Java and PHP apps to be deployed on Amazon’s EC2 cloud servers.
- Engine Yard offers managed deployments of apps using Ruby on Rails and PHP (through its subdivision brand Orchestra) on Amazon’s AWS infrastructure. Its value-add includes self-service configuration and capacity management tools.
- Force.comis the proprietary cloud platform from Salesforce.com. It uses its own language and constructs and is geared primarily for the exchange of data and services between customer-centric applications. Salesforce is now deploying Force.com on separate platforms, including one exclusively built for public-sector customers, including governments.
- Google App Engine is a simplified, but also inexpensive, deployment platform for applications in Java, Python or the open-source language Go. The benefit here is that Google offers some open APIs that present handles to Google services, one of the most important being user authentication through Google Accounts.
- Heroku is Salesforce‘s platform for non-proprietary technologies. Its value proposition (aside from what many perceive to be its relatively high performance) is its deployment of a wide variety of languages – typically those preferred by the open-source community, such as Clojure and Node.js, but also including experimental concepts like Scala.
- Longjump is one of the first cloud platforms in the field (as early as 2008!) and includes a model/view/controller (MVC) implementation of Java designed to let developers build componentized apps around their existing data. Since its inception, Longjump has been building out pre-configured, adaptable business services more along the lines of Force.com, such as enterprise collaboration.
- OpenShiftis now operated by Red Hat and supports the Web’s principal server-side languages: PHP, Perl, Ruby (with the Rails framework), Node.js (server-side JavaScript) and Python. Borrowing one approach from Cloud Foundry, its open-source release enables Red Hat Enterprise Linux customers to host their own OpenShift platforms on their servers, as an alternative to being hosted on Red Hat’s servers.
- SmartCloud is a relatively recent entry from IBM, enabling Java, Ruby, PHP and .NET-based languages along with hosted applications such as SAP and Siebel. In recent months, IBM has been adding business services to its value proposition.
- Windows Azure (or as folks refer to it nowadays, “Azure”) was orignally created by Microsoft in 2008 as the “.NET Framework in the cloud.” Since then, Microsoft has seen the light and has broadened Azure’s repertoire, to include Java and other non-Microsoft technologies like Node.js.
The wealth of options and the wide (and growing) variety of players suggest a market-driven evolutionary path for cloud platforms. With the Web, standards organizations sought to settle upon a single method for accomplishing fundamental tasks, and when private interests sought their own workarounds, it was usually with the aim of cornering the market. But in the competitive and healthy cloud platform market, players innovate by offering options. Those options lead to architectural alternatives and new pathways that could never have been enabled by standards alone.
Stock images by Shutterstock