The unfinished warthog
Listen to this page
On my daily route home I drive past a group of street vendors (or, more accurately, artists) who make animals, flowers, sports team emblems, key rings, cars and more from just wire and beads. What they are able to produce from those raw elements is astounding. Recently, an unfinished piece caught my eye – an unfinished
Warthog, to be specific. I have a thing for incomplete works of art, probably because they provide some insight into the journey that the artist has taken, and I was impressed by the careful and deliberate way the frame was constructed to provide the structure around which the final, scruffy campsite visitor we all know so well was formed. It’ so obvious that you’d need this frame to build the wire beast, but I doubt anyone looks at these beaded artworks thinking about the skeleton they’re formed around.
The relevance of this is of course how little we think about the skeleton around which IT products and services are built.
Hyperscale Cloud vendors – primarily AWS, Microsoft and Google – provide hundreds of services as ‘finished’ products. You no longer have to think about hardware components, building networks, troubleshooting complex devices, filling the generator fuel tank….you can simply choose a server, storage, database platform, application service, serverless function, etc. It’s like buying the warthog in its final form, and we wax lyrical about the benefits of not have to manage the complexity of the underlying nuts and bolts. But perhaps we’re a little flippant about just that – surely the hardware, systems, processes and everything else that underpins the services we use are critical? How do I know I’m not buying something that looks like the real thing most of the time, but crumbles under pressure? How do I unpick the beads to see what’s underneath?
Well, it’s not quite the Socratic method, but you need to ask lots of questions. Dive deep, as they say. For example:
- Do you build and manage the facilities yourself or do you outsource these functions? Who fixes the hardware when it breaks?
- What options do I have to plan, and build, for the inevitable failure of your systems?
- How do your facilities and services cater for the specific needs of ‘as-a-service’ at scale, and what does that customisation look like?
- Do you guarantee the availability of services, and are there penalties if you don’t meet these SLAs?
- Do your facilities meet local and international regulatory requirements? Which ones?
- How long have you been doing this?
We made the decision to partner with Amazon Web Services based in part on the answers to questions like these. If you want a more comprehensive list, check out the cloud platform evaluation sheet from AWS, but what we found was that AWS stood out in three key areas – two empirical and one subjective:
Amazon spends more on R&D than any other company* and have lead the way on cloud computing since they launched their first service in 2004. Hardware, power supply and networks are meticulously customised to increase reliability, shorten fault resolution times and increase performance. For example, their exclusive Nitro system offloads tasks to specialized hardware to enable high performance, high availability, high security and bare metal capabilities to eliminate virtualization overhead. AWS even own and manage the parallel 100GB links connecting their 60+ datacentres.
As Amazon CTO Werner Vogels says, “There is no compression algorithm for experience”, and AWS has been 100% focused on operating public cloud infrastructure at scale since inception. They’ve run even Windows workloads in public cloud for longer than Microsoft have, and 58% of all Windows cloud workloads run in AWS**. Despite providing services to millions of organisations running in 60 zones across 20 geographic regions, AWS has never had a whole datacentre go down.
One of Amazon’s leadership principles is “Customer Obsession”, starting with the customer and working backward. It’s not hype – we’ve seen first-hand how they have helped clients recover from security breaches and accidental spend when AWS was not at fault. Even the more than 160 AWS services are driven by customer feedback and often released early to allow that feedback to drive the road-map.
If you’re a wannabe geek like me, you’ll be fascinated by this presentation by James Hamilton at AWS re:Invent (just the first half is his presentation). It’s a few years old now so even more progress has been made, but it’s still impressive.
We believe that the move to public/hyperscale cloud is inevitable for every organisation. It may take the form of a hybrid deployment, it may be more PaaS and Saas as the vendors take more of the infrastructure management away to ease adoption, it may be serverless – it doesn’t really matter. The point is that the longer you wait to start your investigation, the more significant the leap you need make will become.
**IDC, Windows Server Operating Environment Market Update, Doc # US44217118, Aug 2018/