The Interface Between the Worlds of Cloud Computing and the Semantic Web

Paul Miller

Subscribe to Paul Miller: eMailAlertsEmail Alerts
Get Paul Miller via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Private clouds are real. It’s well past time to grow up and accept this.

Not every IT workload is most logically run in a cloud, now or in the future. But, for those workloads where cloud is advantageous, it seems likely that public cloud will eventually supplant both private cloud and hybrid cloud deployments. Public clouds are getting cheaper, they are addressing legacy regulatory hurdles, and they are increasingly meeting every valid concern that IT buyers and users might have about entrusting mission critical cloud workloads to them.

However, in 2014, there are still workloads or situations which are suited to a cloud-like treatment but more suited to a private or hybrid cloud deployment than to a public cloud. This may be because of the sometimes prohibitive cost of running steady workloads for long periods of time in a public cloud. It may be because of existing investment in hardware, data centres or people. It may be because of some as-yet unresolved legal, compliance or regulatory hurdle. It may simply be because of fear of change. Or there may be some other reason.

IT suppliers know this, and there’s an unhealthy flood of ‘private cloud’ solutions on the market, many (most?) of which are simply last year’s product with a new name and a cloudy logo. This behaviour is unfortunate, unhelpful, distorting, confusing, disingenuous, (occasionally) fraudulent, and (sadly) inevitable. But behind the snake oil, the FUD-fuelled pitches and the lies there are real private cloud solutions, delivering real value to real customers.

And we attack them. We attack them all. We say there’s no such thing as private cloud. We say private clouds are false clouds. We say you haven’t got a cloud if you bought the hardware. We say there’s no CapEx in cloud. And it all gets a bit silly.

Someone is always paying for the hardware in a cloud. There is always CapEx for someone. If you’re consuming elastic, on-demand, self-service, metered computing over the network from Amazon, we’re happy to agree that you’re using a (public) cloud. If you replace Amazon with Microsoft or Google or Rackspace, we’re still happy. It’s still a (public) cloud. Despite the huge capital expenditure outlay at every single one of these companies. Despite the fact that — at their scale — it’s not limitlessly elastic at all. They have physical constraints. Sometimes they hit them. You, the individual customer, rarely notices.

Now imagine you’re a research scientist at an international pharmaceutical company, or a developer at a global bank, or a product manager inside a large retailer. The organisation for which you work is large, it has scale, it has clout, and it has buying power and realises economies of scale when it spends its money. Someone, somewhere in that organisation, spends money to buy hardware and places that hardware in a pool that you and your thousands of colleagues can access. The hardware in that pool is designed and configured to be elastic, on-demand, self-service, metered, and accessible over the network. Devolved budgets, chargeback, and all the other financial shenanigans that big companies love mean that you’re billed by IT for the resources you consume. You never bought the server. You simply pay for what you use. It’s a (private) cloud.

Amazon’s cloud might be bigger (and therefore able to elastically scale further before it breaks), but the internal cloud you’re using scales a lot too. Amazon might have more buying power, and therefore see a bigger discount from suppliers than your organisation does, but Amazon has to factor in a profit margin for itself.

The bigger these clouds get (whether public or private), the more likely it is that additional resources will be there when an individual customer needs them. The bigger these clouds get (whether public or private), the greater the purchasing power and the more useful the economies of scale. Amazon’s data centres are probably bigger than those of most individual corporations, so Amazon has an advantage there. But that’s all it is – an advantage. Not a lock on the right to be called ‘cloud.’

For the end user, a private cloud can, should, will and does look exactly like a public cloud. It’s there when they need it. It grows if they ask it to. And they’re billed for what they use.

It’s a cloud.

And their IT department is a cloud provider.

For IT, of course, the picture is rather different. They are expending CapEx. They are having to buy hardware. They are having to hug tin. They are having to stay up all night, making sure everything keeps working. They need to monitor load and demand and all the rest of it, to make sure resources are always available when the customer tries to access them. They need to patch and secure and monitor and maintain and tweak and cajole and replace and fix… and occasionally kick. It’s still a cloud. AWS staff do all that stuff. They’re running a cloud. Azure staff do all that stuff. They’re running a cloud. Rackspace staff do all that stuff. They’re running a cloud. It might make sense for enterprise IT to also do that, today. It might be technically, financially, and commercially prudent, today. It’s far less likely to be so in a few years.

But for the end user? The customer? The research scientist, the developer or the product manager? They’re just using a cloud. If it does what they need it to do, at a price and with a reliability that meets their requirements, it really doesn’t matter whether the cloud they’re using is public or private.

It’s still a cloud.

Image shared on Flickr by Dawn Ellner.

Read the original blog entry...

More Stories By Paul Miller

Paul Miller works at the interface between the worlds of Cloud Computing and the Semantic Web, providing the insights that enable you to exploit the next wave as we approach the World Wide Database.

He blogs at www.cloudofdata.com.