On the back of Amazon’s recent Sydney Customer Appreciation Day and announcement (finally!) of a Sydney based data center I thought I’d talk about the the inexorable move to the cloud and its opportunities and ramifications.
As a relative greyhair in the industry (that is, if I actually still had hair… its a sore point… sniff) from my perspective what we are witnessing is the final realisation of an idea that has indeed been a long time in the making – the maturation of computing to the point of it being a utility service – just like your gas, phone and electricity. Something talked about, anticipated, occasionally attempted during my whole career, but finally reaching fruition.
It was rather interesting listening to Amazon’s cloud chief Andy Jassy (at the Sydney convention) elucidate on the somewhat strange story of how an online bookseller got into the game of public cloud infrastructure provider. One pertinent point that struck with me is the one he made regarding the evolution of the electrical system. In the early days of electricity it was not uncommon for factories to have their own generators to produce the power needed to run the machines. Subsequent to Nikola Tesla’s inventions in AC power (that allowed both the efficient transmission of electricity over long distances and its simple transformation to forms usable by the growing range of electrical devices), electricity supply rapidly moved to be the domain of specialist power companies.
Those of you working in IT that keep your interests solely to the technical aspects of your trade may well be surprised at the view of IT by the ‘beancounters’ in the company. And with good reason! A cursory look at corporate budgets across the entire spectrum of industries highlights the major costs of IT to most companies – even those in industries where one is hard pressed to see anything but a nebulous connection to computing. In industries such as finance where the management of information is both a prudent and legally sanctioned requirement, IT budgets are nothing short of eye-watering.
When you run the numbers over a business, possibly the most horrifying industry imaginable may well be semiconductor fabrication facilities – the factories that produce the high tech chips (particularly memory and CPU) in all your electronic gadgets. A fab costs billions of dollars to initially build, but it does not end there. The remorseless creep of technological improvement mandates an unending need to update equipment to be able to create chips made up of smaller and smaller transistor geometries (which allow more complex features that run faster and use less power). This results in ongoing daily depreciation costs in the millions of dollars. As scary as these numbers are (and I’d pass on the job of ever being production manager for such a facility), these costs are borne by, in the highest tech instances, a handful of facilities. These facilities adequately supply the demands of billions of consumers. In that regard they are incredibly efficient.
There are similarities and differences in IT. Those often improving chips from the fabs beget often improving computing machines. Those improved machines provide extra cpu cycles, memory and IO bandwidth so that operating systems and applications running on them can be made to do ever more sophisticated things. Just like in the chip fab, such ceaseless churn and improvement results in ever higher total costs of management/ownership.
There is a difference though: as complexity of semiconductor fabrication forced rationalisation in the industry to a few major players (the most expensive piece of equipment in the first fabs was under $10,000 – how things have changed), corporate computing has by and large done no such thing. Even though no single company has tech costs as high as a semiconductor fab, in aggregate the costs are far higher, and the efficiencies are far lower. Up until quite recently, every company has operated as a silo, bought and maintained its own infrastructure and applications, and solely bared the associated costs. This, i would argue, has been unsustainable for a long time in the sense that corporate IT costs have severely limited a companies abilities to do what it’s actually supposed to do, but its rapidly getting to the point where its simply flat out untenable as a business proposition. Not that vendors have necessarily had a problem with that. As absurd as it is to fan out to all customers and perform the duplicate task of upgrading application versions on each client’s private infrastructure, it was at the same time quite lucrative.
Let me give you an example: We’ve been involved in projects where the costs of assembling a pre-production environment tallied into the MILLIONS of dollars and months of time! Yes that’s right – add up the bills for the servers, switches, rack space, labour and process time to do all that’s required to deploy a new app into an environment for final test before production release and that’s what it comes to. And not just that, everything had to be ordered from suppliers, and you had to wait for them to be delivered. Then you had to wait for ops to have the time to install and configure them. Since these initial provisioning tasks were manual tasks, costs skew towards labour as much as equipment. Now there are reasons why the work must be done in a careful and rigorous fashion, but at the same time its not rocket science, its not novel or experimental work, and the business is well justified in questioning exactly what value it gets for its money. Yes improvements could be made in streamlining all this, but a company must be of a particular size to justify the expense of doing this.
There are reasons why things have been slow. As complex as a modern CPU is (and they now contain BILLIONS of individual transistors), the software tools on top of which they run are unimaginably more complex. Software systems are the most complex ‘things’ ever made by human ‘hands’. Why? I often characterise it by making the point that physical, tangible objects are constrained by the laws of physics – these laws are provided to you as validation constraints gratis – and as such half the design’s already done for you! When writing computer software, you also devise and are responsible for applying the ‘laws’ upon which the system operates. A physical bridge will never experience the force of gravity spontaneously reversing in direction and pulling it towards the heavens, so not designing for that eventuality does not compromise its reliablility. An analogous ‘computer bridge’ certainly could experience an equivalent absurd scenario, or worse, most happily. You couldn’t pull 20 trillion dollars cash out of your pocket because you made a ‘mistake’ (pity about that), but a corporate billing system may very well decide (and has decided in some cases) to charge somebody several multiples of the worlds money supply without any qualms.
Lets get back to the story of why exactly is Amazon running a public cloud business.
Amazon operates a global online business based on massive volumes and razor thin margins. A meticulous level of operational discipline, and a high level of automation were required in its IT infrastructure and processes to drive the business profitably. This at a scale that very few business could even comprehend.
At some point, Amazon recognised this knowledge and these skills themselves had incredible value in their own right.
In extending these systems and providing them to third parties they have started us along a long dreamed of path, and opened up an opportunity that may at some point eclipse the value of the original business which it was built to support.
Amazon’s cloud infrastructure is, like the chip fabs and power generators, a small number of facilities using best of breed technologies and processes, combined with massive economies of scale, allowing millions of end consumers to pool resources and amortise computing costs. There is no secret sauce, as it were. Amazon uses the same physical infrastructure, operating systems, virtualisation products and so forth as are available to you. Which is why Amazon cannot ensure a single provisioned instance of a server stays up any more then you can. The true value of the entire AWS stack is the pragmatism shown in assembling it. Rather than try and do the impossible (guarantee single node uninterruptible uptime), they’ve provided the tools needed to achieve service uptime in the simplest way using the conventional technology currently available.
They provide this power conveniently pre wrapped, tested, ready to use, at scale, supported, accessible from a self serve digital kiosk, with all the conveniences and benefits encapsulated. You also benefit from the lessons learned in building systems that can sustain a company way bigger than your own – don’t underestimate the value of this. Perhaps the following link will illustrate the logistics required to run Amazon, and by extension the IT infrastructure underlying it: http://imgur.com/a/q1WIO
Going back to our multi-million dollar environment setup – achieving the same in Amazon would not take MONTHS, it would take possibly hours or minutes. It would not cost millions, it would be a tiny, almost insignificant fraction of that (and its not an upfront cost – we’ll get to that). Using AWS, you declaratively design your data center, from the individual internal networks, the routing rules between them, the VPN that allows external access, to the individual servers in each network and possibly what operating system and applications are on them. Of course, when you do this, nobody is physically moving or manually configuring anything, but you get the same result – that’s the power of virtualisation and why its a giant leap in efficiency.
Another thing to bear in mind is: of the costs involved, none of it is capital expenditure. You rent the resources you need as and when you need them. There’s no need to be forced to anticipate computing load and pay if you are wrong (in unused infrastructure on one side and unhappy customers on the other). A properly designed application can be scaled across virtual instances as load increases (and scaled down when not – overnight for example). In the extreme example, environments can be set up and torn down on an hourly basis. So – you can start quickly, end quickly, and in between pause (by extension your costs as well) or scale down, or up, as your heart desires. Taking it one step further, you can also set this up to happen automatically, or event further – place it under computational algorithmic control (new data coming into the data warehouse reaches a trigger level? start up a 1000 node cluster to crunch the data, then shut it all down). I hope you can see the power of this. Your own needs may be staggered, but the aggregate computing needs of all clients, across all timezones, is far more consistent. Thats the other advantage of pooling resources – someone else is using your excess capacity when you are not, so a smaller number of physical servers can satisfy everyone’s aggregate demand, rather than everyone having their own under-utilised servers, sized to handle a brief spike in peak demand.
Virtualisation is not new, but Amazon’s offering provided the first large scale implementation with ‘critical mass’ in breadth and depth. They are starting to have competition, sure, and there are a number of projects providing the tools to assemble a ‘private cloud’ – one of which honours the AWS service API interface. Unless you have specific requirements, it’s too much hassle (and a recent Forrester survey suggests that of the companies that attempted to build private cloud infrastructure with a provisioning portal like Amazon AWS, only 10% succeeded in the task). Private clouds use private infrastructure as well – which is something we’d ideally like to avoid.
BUT BUT BUT…. you say – my company X in industry Y will never go to the cloud because of reason Z. Oh really? That’s an awfully long time for us to challenge the hypothesis. Industrie IT has clients in diverse industries including financial services and health, where data security is paramount – but you would be surprised how much interest even they show in cloud computing. Incidentally, some pundits have said that Amazon aren’t exactly going out of their way to correct the murmurings that whole industry sectors cannot or will not use public cloud infrastructure in its current guise. Amazon are well aware of who is using their cloud infrastructure and may be keeping quiet to extend their first mover advantage.
Obviously the non availability until recently of a local data center presence in Australia has stymied adoption by virtue of legal mandate in data residency (no offshore storage or transit), but with the opening of Amazon’s Sydney data center we have no doubt (and experience even in these early stages seems to bear this out) a tidal wave is about to crash over the way we’ve traditionally done corporate computing.
Disruptive change is not uniform, it doesn’t even distribute itself in a statistical normal ‘bell curve’ fashion, it rather behaves more like an earthquake – when things happen they happen abruptly, interspersed with less drastic but ever improving continual optimisation and refinement. We are in the very early stages of utility computing, and you could say it’s the early adopters dipping their toes in. But whatever hesitation holding adopters back due to real or perceived issues, because of the massive efficiencies gained, a small trickle will at some point result in an avalanche of adoption by companies no longer prepared to wait when they know they are starting the race at a significant competitive disadvantage to those who have made the leap. At that point, the days of silo corporate computing will come to an end, for the vast bulk of companies. I believe we will look back in hindsight and marvel at how quickly it happened.
There are issues with any change. Having given up your home generator and bestowing the responsibility of electricity supply to the electric company, how do you know the plant is being maintained adequately enough to be reliable? Well, the reason you don’t think about it is that most of us do not know a time when we couldn’t plug an appliance into a wall socket and, in all but the very rarest of circumstances, not have it work. To illustrate – go and turn off your power via the main switch in your meter box. I can almost guarantee, when you walk back into your darkened house you will instinctively flick the light switch – and this is when you KNOW you just turned the power off! Even though anything more then a localised short term cessation of electrical supply would have potentially catastrophic consequences, and some organisations like hospitals keep a backup generator ready just in case, its not something most of us concern ourselves with. Why? At the end of the day we place an IMPLICIT trust that the service will be provided – and experience and familiarity continue to reinforce it.
The same thing will happen to utility computing. It may be that, bearing in mind the critical nature of the system, in many counties a general regulatory standards and enforcement regime is put in place to ensure acceptable levels of data security and resilience are applied (similar to those applied to financial institutions now). These things are yet to play, or are currently playing, out. Initial experience, however, is good. Amazon’s AWS cloud offering is the same base upon which Amazon’s significant businesses are run, so they have much to lose themselves. Amazon’s S3 object storage service now holds in excess of a trillion objects, and not one has been lost since the service’s inception 7 years ago – giving rise to Amazon’s claim (in truth technically dubious), of 11 nines reliability.
That is not to say you should personally be complacent. Indeed, you must NEVER make any assumptions whatsoever about how your data will be handled by any ‘cloud’ offering. The term, like many in IT, is an overarching concept, imprecisely defined, with no strict guarantees about, well, anything (big data anybody?). Amazon provides a wealth of information about their cloud services, and quite explicitly and openly spells out exactly what expectations you can place on their component offerings. Vigilance is key, but i do again make the case that it comes down to an element of trust whenever you cede responsibility for anything to a third party.
Corporate computing is finally going the way of other utilities. It has reached a point in its maturity where it’s best handled by specialist organisations which facilitate efficiencies of scale. Just like electricity – what you actually do with that power is where your competitive advantage lies.
We’re at a pretty exciting nexus.
In this blog I covered one aspect of cloud computing – the physical part. In future blogs I will delve deeper into how the cloud will change the way we do almost everything else in IT as well.
Industrie IT is an Amazon AWS Consulting Partner. If you would like to discuss the possibilities of any aspect of cloud computing, or any general IT needs, do not hesitate to contact us and meet the team.