This is part 1 of the Absence Highlights Change Series
When I first entered the field, thin-client was the rage. The intent was to offload the computing requirements from the desktop machines, and instead pass only entered / parsed data and screen refresh information back to the desktop. I’m dating myself here, but the functional imperative of thin-client was borne of the weak processing power of the desktops of yore.
As Moore’s Law asserted itself, desktop machines became more and more robust… and the technical limitations that made thin-client de rigueur were rendered moot.
Application developers, on the other hand, kept asserting their own dominance in the guise of “code bloat”, and the applications (and their resulting file sizes) have grown as well. While I haven’t done a formal regression analysis on the topic, I would posit that over a long-term baseline, both processing requirements and file sizes have also obeyed Moore’s Law!
Thus, I contend that “Thin Client” was synonymous with “cloud computing”, to the observer of the time (1990’s through the mid-2000’s).
Over the years, I have watched as hardware developed to “try to” keep pace – from single core to dual, to quad, to sex-core (is that a PC term?) to octa-core, and I fully-expect that when I go to sleep this night, somebody is drafting a patent application for a 64-core chip…
But we need to remember that hardware development will always lag behind software / application development by 6-12 months. If my PLC experience over the past 6 years taught me anything, it is that the process of hardware development is necessarily slow: hardware isn’t code, and needs a longer time to develop to fruition. Take a quality R&D program, then prototype, alpha build, UL listings, FCC testing, beta build and testing, other required compliance issues – hardware takes a long time! And because of that, application requirements will always outstrip the capabilities of affordable hardware.
In today’s world, I see incredibly-stout platforms, engineered to a high level of precision and capability – and yet, each customer interaction is unique in its own way, and demands the care and attentiveness of experts in the Solutions Engineering role.
It’s not all about a stout box. While it might be possible, from an Engineer’s point of view, to throw a four-processor quad-core platform at any challenge, will it meet the technical and financial objectives of the client? (Indeed, it was this fact above all else that drew me to Carpathia – the concept of a customer’s “technical profile” doesn’t exist – there are no “cookie cutters” here.)
And yet, with great power comes great responsibility. An Enterprise seeking to leverage the power of today’s hardware, in today’s customer service environment, faces many challenges – such as the Capex needed to obtain the hardware, the Opex needed to maintain it (including burdened costs for multiple support employees), and – oh my – the cost of building a Data Center to four, five, or even six-nines reliability. All of this constitutes a non-trivial undertaking.
When the pain of the undertaking becomes too great to bear, the savvy enterprise will outsource the operation to a web hosting provider (of whatever Tier meets the profile of the company’s needs).
Thus, I contend that “web hosting” was synonymous with “cloud computing”, to the observer of the time (Mid-2000’s - 2010).
Continue reading this series, check out Part 2 of the Absence Highlights Change Series: Virtual Machines Should Augment Not Replace
Write a comment
Posts: 2
Reply #2 on : Fri September 23, 2011, 12:12:09
Posts: 2
Reply #1 on : Sun September 18, 2011, 00:03:41