Everything in the Cloud?

Cloud… I tend to dislike hype and I am honestly quite sick of all the talk about cloud computing and “anything as a service”. Still, it is an intriguing area. Last week, I attended Produktledardagen, a very inspiring product management and product leadership seminar, innovation lab, and social event for the profession of product management.  A significant part of the discussion was about the Cloud, and how to think about it from a product perspective.  Suddenly, with this perspective, it actually got quite interesting. In particular, trying to define to myself just what a cloud service is.

Pretty much everything today is being billed as “cloud” as soon as something is connected to the Internet. That does not seem right to me. We need a stricter definition that actually helps focus the mind and reduce the space to something essential. To me, cloud means: centralization, specialization, and data transfer.

Centralized. There has to be something running in a central location (and a set of data centers like what Facebook is using does count as central location, even if it is actually a whole host of different sites in practice). Cloud-based services is a total reversal of the trend towards pushing computing out into the end points and people’s own machines that was dominant until quite recently. Minicomputers, microprocessors, home computers, PCs, … all of the past trends in hardware have pushed computing out closer to people. Now, with the rise of cloud services, computing is being centralized again.

The most widespread and successful cloud services tend to have custom local clients on connected machines, but this does not mean that they are not centralized. In practice, a web page is not a sufficient interface for most interesting services, especially not on mobile devices.  In a way, cloud services are sufficiently complex that they make sense to embed in custom GUIs, and they benefit greatly from a deep integration with the local file system and data store. A web browser for all its power does not offer the same ability to access to the local machine and integrate into the functions of the OS as a real application.

The centralization aspect means that I would not count peer-to-peer file sharing services as cloud.

Specialized. From an economics perspective, it seems to me that many of the best cloud-based services are examples of classic Smithian specialization by division of labor. Using the Internet, it is possible to aggregate many but minor demands for a particular specialized service into a total demand that makes it possible to create a business focused on doing just one thing and doing it really well. The prior state was many players doing the same thing as part of a broader business, with less skills specialization. The companies providing the services become specialists in a particular function, and can thus do it more efficiently.

This is nothing new in itself, the only difference is the delivery mechanism.  For example, consider the traditional highly skilled consultant that do the same occasional but valuable work for several clients.  Another example is the creation of standard software that is used by many different customers (instead of each customer building their own). In the past, things like specialized operating-system vendors, commercial software vendors (and standard software packages), and open-source software have all been the result of the same kind of aggregation of demand and specialization of provisioning.  Indeed, many of the current business-process-as-a-service or software-as-a-service vendors could have been sellers of well-written standard software a decade ago.  The main difference is that with cloud services, the software runs on the vendor premises instead of on the customer premises.

Data-based. Cloud-based services have to move some kind of data to the servers for processing, and that data processing on the server has to achieve something that just cannot be achieved locally. For mobile applications in particular, this is becoming a very common design pattern (in part to achieve better security). Which really is back to terminals and mainframes, with a fancier terminal and a less imposing mainframe, but still the same idea. Proven in use for a very long time. If there is no data transfer off of the local device, it is not a cloud service.

An interesting modern spin on centralized data processing that is very common in cloud systems is that the services correlate and aggregate the data from many individual users and then feed the result of the aggregation back to the individuals. This creates a network effect where the service provides a collective value to its user base. Social networks definitely belong here, and even more services like Waze. The new thing here is really the individual getting direct personal benefit from the service, while traditional centralized data processing tended to be done for the benefit of the organizing organization. Giving back to the individual users is thus a crucial component to a successful cloud service.

Using the cloud as a mirror and replication service is a common variety of data processing. Cloud storage like Dropbox or the Google and Apple sync between mobile devices and computers are examples of this. Here, a server is used instead of more classic point-to-point peer-to-peer data movement, based on the fact that it is often easier to talk to an Internet server than to the computer next to you (even within a home network, dropbox usually synchs things more transparently than trying to make the devices copy data between them, in my experience).

Price is not an interesting factor to me. Often when people present cloud services, they often describe “low price” or “cheaper” as a key part of their value proposition. To take an utterly unoriginal example, Salesforce.com provides even the smallest firm with access to world-class IT support for their sales force, at a very low price. But that low price really results from the division or labor and specialization. The reason is that the provider here is more efficient than old providers, but not that they are on the Internet per se. The Internet is an important enabler, for sure, but not in itself a cause of low prices. I can certainly see room for cloud services that are very high priced, as long as they provide a corresponding value. Business as usual, from a product management perspective.

So, in summary, there is something really interesting with Cloud, and I want to pursue. But I find it more interesting to see how it can be used in high-value business-to-business transactions, rather than your typical consumer-oriented play. I just like hard problems, I guess.

update, after some  more reading and thinking

Standardization. One aspect that seems very common when people describe cloud plays is the idea that you sell a very standard product. Compared to the amount of customization and variation (in which hosts to run on, for example) seen in standard PC software, a centralized server park does allow a new level of standardization and simplification of the software. A note in the Bessemer Ventures rules for cloud businesses really brings home this point: only build a single variant of your software, as that lets you innovate faster. This makes sense, since the server end of a cloud system is theoretically at least totally under your control and can be made very homogeneous in terms of hardware, operating systems, and middleware. Thus, one possible additional criterion for a cloud play is that it is highly standardized and offering the same thing to many users and not making allowances for variations. This would seem to lead to higher efficiency in development and operations, and is an economical argument for specialization. Why would the user need to care about this, leave it up to the experts!

I am less sure about the Bessemer statement that you never should allow on-premise deployment for customers — there are cases where that makes eminent sense, in particular for very secure systems. Sure, banks have standards for their IT providers and similar, but there are cases where physical control is necessary and sane. Hopefully, you can then make the customer use your favorite software stack to run the on-premise version.