Cloudspeed

So cheap and so powerful

Ten years ago I had fun in the dotcom bubble.  My employer at the time was pitching the idea of dotcom to some rather old-school business types, telling them (correctly as it turned out) that merely telling the City that you were considering doing something in the new-fangled online world was enough to add millions to your share price.

As a result, we worked with Securicor to create www.safedoor.co.uk (now long dead and currently only an advertising hoarding) which aimed to help reluctant online shoppers navigate the then-terrifying jungles of e-commerce by offering to shield credit card details from nefarious types such as Jeff Bezos.  It failed (obviously, or I’d be writing this on my yacht) but nowadays Google Checkout offers a similar function.  Actually, the coolest thing it offered was anonymous delivery.  You could order something from an online shop, and all the retailer would know was that it was being despatched to some Securicor Omega Express depot, where it would be relabelled and redelivered.  Ideal for keeping your details from various porny retailers if that was your bent.

Anyway I digress.  We did good work and built something pretty damn fast and good.  But the single longest and most expensive item in the delivery schedule was the production infrastructure.  It cost £1M and took six months to design and build.  It was (over-)engineered in traditional fashion with load balancers and twin hardware all the way through the three-layer stack.  

And I would be surprised if the load on SafeDoor ever stressed it beyond about 10% CPU, with the possible exception of the massive and inefficient query I wrote to calculate VAT payments.  On the flipside, if it had ever taken off in a massive way, perhaps through an endorsement by consumer goddesses Esther Rantzen and Anne Robinson or similar, it would almost certainly have failed under the load.

Ignore for a moment the obvious lessons to be learnt about what happens when you pay salaried consultants to build dotcom stuff for a fat and lazy corporate venture - that’s the primary message of the entire dotcom bubble and look again at that delivery schedule.  £1M and six months.  And who’s to say whether that money was well spent as an insurance against future success, or a total waste given that my laptop could probably have run the actual load?

And that’s what gets me so excited about cloud stuff.  I am in love with the idea that I could get a similarly capable infrastructure up and running in Amazon in about a day.  And even more in love with the idea that I wouldn’t need to bother, I could provision a couple of small instances at a few hundred quid a year and know I could scale them if needed.  And, and, and, more than that:  I could get a managed instance of Oracle up on AWS and do away with the need to hire an operational DBA (at least a little bit).

Not only is that deeply cool in its own right, it’s also incredibly enabling.  The next dotcom boom (heaven help us all) doesn’t need to waste millions per project on simultaneously overpowered and potentially underpowered kit and doesn’t need to wait six months for it to be racked.  It’s there already.

SLAs, they’re just insurance aren’t they?

In my previous post I was saying that I’d address the topic of commercial recompense for failure, and how this aspect of cloud services was (so I’m told, I’ve never heard it first hand) contributing to laggardly adoption of the Great Good that is the public cloud.

If you’re running an enterprise, then people pay you for some kind of core business - exploring and extracting oil, designing pushchairs, whatever - and all the stuff that gets done in the rest of the organisation - toilet cleaning, accounting, IT server hosting - is merely support for that core purpose.  Failure of these supporting elements will (or should) ultimately lead to failure of the business, but ability to do these supporting things well or badly is not directly tied to the success of the core business.  When someone buys pushchair designs from you, they don’t care how good you are at keeping toilets clean, and your worry is keeping the toilets clean enough so your staff don’t leave and you can continue to crank out cheap Bug-a-boo clones.

IT is, obviously, unless your Rackspace or similar, one such supporting service.  And the idea behind agreeing service levels between the core business and IT is to make explicit the link between some of the needs of the core business and the delivery of some of the supporting services.  If my servers go down, I’ll fail to print out the pretty designs for six wheel pushchairs and so lose some clients and lose money.

Here’s the rub though, say your servers go down, and you start to lose your core business with customers walking away everyday to Maclaren, what you really, truly ought to care about is getting those servers back up, not how much money you’ll get from your shortly be to non-existent IT team for each day those servers are doing nothing but suck up power in a data centre.

An SLA that requires 99.99% uptime does not guarantee its provision, just impress upon the supplier the importance of its provision.  And the penalties for downtime merely reinforce that importance.

But for a cloud provider, it is core business to keep your cloud services up.  Downtime for services is a death knell for your business.  No SLA in the world can  incentivise someone like Amazon or Rackspace any further to keep the lights on in their data centres.  It might dictate the order of restoration of services, but probably that’s all automated anyway.  It almost certainly won’t change any aspect of the way you manage your data centres and services. (This is all supposition, next time I negotiate a multi-billion pound cloud contract with Amazon I’ll update you all with my insights).

So if you’re a potential cloud customer looking to negotiate enhanced SLAs for your business apps, such SLAs are not going to have any meaningful effect on the execution of your core business.  They will instead cost you extra money now, and give you extra money in the case of an event that leads to loss of some of your services.

And that sounds to me like insurance.  Pay a premium, and get money back in the event of some relatively unlikely occurence.

And further, if it’s insurance then there’s no reason why you couldn’t get that from an insurer, there’s no need to impose that obligation on your cloud provider.

So, a prediction.  Insurance companies will fill this space with off the shelf policies at some point, perhaps re-sold through the cloud providers.  They’ll “certify” cloud providers and sell insurance against their uptime.  Pay Rackspace for the service, pay CloudInsure to cover you against downtime.

Cloud security: Nothing (more) to worry about

Conventional wisdom seems to have it that concerns about the security of data are one of the primary reasons why organisations are dragging their heels in moving apps and data stores up to the cloud.

The rationale is that if it’s running in my data centre it’s more secure than if it’s running in someone else’s in the cloud.  I’m no CIO so it’s not my neck on the block, but I simply fail to understand this argument in most cases.  My thinking is that if you’re connecting your app to the internet for what ever reason (mail gateway, EDI, customer access) then you will be more secure by transitioning to the cloud.

If I deconstruct the reasoning for keeping things in-house, or at least outsourced in a very close relationship under a bespoke contract, rather than in the sky then there seem to be two dimensions at work: perception of risk, and commercial cover for loss.

Taking risk first, part of the laggard’s reasoning seems to me to be nearly tribal.  My data centre staff are trustworthy, upstanding, full of integrity and professional, your data centre staff are ne’er do-wells hopping between prison and the outside world, pausing only to siphon gigs of data from every database they can lay their hands on.  My data centre is standards compliant, you merely tell me yours is standards compliant.  Given that you can’t know for certain whether at any given moment one of your staff is patching that critical issue or seeding a couple of torrents, it seems to me to be more likely that Amazon (to pick my favourite cloud provider) are probably on average going to be recruiting better people doing a better job than you.  It’s their core business after all.

The other side of risk is additional attack vectors.  A cloud provider data centre is a potentially lucrative target and likely to involve operational processes and software and hardware elements unneeded in an enterprise data centre, so it may naturally attract more accomplished attackers exploiting less obvious holes.  Perhaps, but there’s an element here of the security of the herd: if you’re running in the cloud amongst thousands of other customers, a breach is unlikely to affect you directly.  And anyway.  It’s their core business to run a secure data centre, failure to do means the business absolutely fails.

So the second dimension for lagging is do with the commercial cover for loss or breach.  And that’s a topic for another day.

I’m pleased to see that I’m not the only person with this view of the world.

The Cloudspeed Manifesto

This blog believes that:

• migration to cloud services is not only inevitable, it is desirable
• cloud delivered services are supporting a rapid acceleration in the pace of delivery of new technological capability
• slow-pokes in the migration to cloud delivery of services within and without the corporate and government organisations are dragging their heels for largely irrelevant reasons and missing a massive opportunity
• cloud services make a whole class of technical problems (that of infrastructure management and maintenance) simply disappear from view for most organisations
• to get all philosophical and futuristic: cloud related service delivery is a harbinger of a forthcoming technological singularity

Actually this blog’s not really certain about that last bullet, not least because it doesn’t half sound cheesy.  But spending an hour poking around the web reveals an exciting array of services and offerings that represent stupendous opportunity.

Oh and finally this blog believes it is written by Simon Dring, project manager and erstwhile developer and from this point onwards will drop the third-person nonsense.