If you read my “stuff” you know I am a very big proponent of cloud computing.
I wrote a small e-book on how to be a cloud purist (which talks about and describes the proper way to — well, cloud).
I have engaged in numerous battles and debates (both online and offline) that were lengthy and passion-filled about this topic and have always tried to approach them as a way to explain why cloud computing should be the way organizations approach their computing.
There is so much potential and value in adopting cloud computing that it is almost impossible to understand how the bastardized concepts of private-cloud and hybrid-cloud even became a reality (don’t worry, Sameer Patel – no rant about that here… fodder for another post).
In keeping with the role of “thought leader” and “visionary” often assigned to me I wanted to find a way to explain why we are not approaching cloud the right way. Then the other day came to me in the middle of a run. Electricity.
We take electricity for granted in this country (well, in most places around the world where a comprehensive solution exists). We expect it to be plentiful, available, and low-cost. We use it to power our lives, businesses, and just about everything else (including cars lately). The true test for anything in this world is to compare it to electricity: you flip a switch and it’s there; you flip it again and it’s gone.
If you bear with me for a few minutes I can explain how we can make cloud work as electricity.
The entire US is covered by an electrical grid. This is what makes electricity always available (or shortly after it goes out in most cases). The grid’s purpose is to ensure easy sharing of electricity that is generated in any one region with many other regions. It also ensures that disruptions that occur in one location don’t affect a larger area and they can be easily and fast overcome.
In the old days, before the grid existed, each town and or region needed to have their own power-generation. A town that generated too much electricity could not “sell it” to a neighboring town (unless they laid out a cable between them – and another for every other city or region they wanted to sell it to) and would often end up being wasted (it is not possible, counter to popular sayings, to store electricity in a bottle for a long-term).
The grid that is laid out around the entire country (and parts of Canada) is used to backup power failures and ameliorate peak load usage. It also makes it far more efficient and cheaper to operate. It was established in the 1920s (and evolved many times since) on the same principles that made telephony and telegraphy work: sharing common infrastructure costs reduce costs and improve efficiency among the suppliers and providers.
The concept of cloud computing, based on models of distributed computing established around the same times as the electrical grid – even before computers, should work the same way. A public network connects myriad resources (storage, computing power, services, etc.) that should be shared. By providing a centralized set of security, management, and allocation rules enables anyone connected to that public network to use those resources.
Before the internet was the public network we could barely do cloud computing: it was a dream (if you remember, CORBA, COM/DCOM were early versions of distributed computing that failed due to the lack of a public network – think of them as “private network” technologies). The introduction of the ubiquitous and cheap network made it possible.
And this is where the story differs.
Software vendors decided, as the electricity and telephone providers did before them, that controlling their customers (and retaining them in their own private networks somehow) was more important than building a computing grid similar to electricity. Today, we are still undergoing that same problem.
The question that always kills me is when I hear someone ask “how many clouds do you have?”.
When we talk about cloud as if it was a storage location for files, or when we discuss how each vendor offers their own cloud (or even clouds – hybrid, private, government-only, etc.), or when we say that anyone that offers a product or service via a browser is “in the cloud” we are missing the big picture.
The public network, is not the cloud – it is the equivalent of the power lines that transverse the world (and having lived in Argentina and Roseville, CA I know power lines – trust me).
Delivering an application via a browser is not the cloud – it is the equivalent of selling someone an electrical generator.
Hosting your own “cloud” is not the cloud – it is the equivalent of selling someone a transformer.
A cloud requires infrastructure built by each participant and common standards to support the connections between those components. If you want to operate a power plant you better make sure you connect to the appropriate grid to take advantage of all the benefits of operating within it. While building your own power plant for your own purposes may work for some situations not every homeowner will benefit from doing so. Even if you have solar or wind energy in your house – you still need to connect to the grid to both sell excess production or power your house when there is no sufficient production.
The cloud is the grid that distributes all those resources so that anyone who needs them can use them with the assurance that their solution will not be “hacked”, changed, altered, or stolen. Just like you don’t expect an electrical appliance you plug into the electrical grid to be corrupted or blown away (as long as it complies with basic standards), you expect any application you plug into the cloud to be secure and perform as expected.
That is the model we need to strive for. Not owning electrical transformers, generators, or power lines.
Let’s build a cloud computing grid.
9 Replies to “On Electrical Grids, Cloud, And What We Are Doing Wrong”
It seems to me that way too much time is being wasted on esoteric debates involving terms with no standardized definition.
Instead, would it not be much more productive to engage in discussions focused on the specific strengths and weakness of a solution/implementation and its ability to quickly and securely leverage other relevant resources accessible on the Web, wherever they may be? Who cares if the solution lives on “private” or “public” systems infrastructure?
The plug-and-play cloud that you speak of where one can quickly, seamlessly and securely combine multiple services in a single, synergistic solution does not yet exist on a material scale beyond the hyperbole of vendor marketing and “visionary” musings. Sure, with lots of professional services almost anything is possible, but…
Is it not time to get these discussions out of the clouds and into the mud where implementations actually live and die?
I appreciate you are never afraid to enter debates and conversations. I do.
But there’s too much here… let me parse it out.
1. standardized definitions? sure, there are many. the US govt entered the fray and there are plenty of other standard definitions of what cloud computing is. my book lists a pletorah of resources and Wikipedia does a decent job of including them in their discussion. we don’t lack standardized definitions, we lack adherence to those definitions. problem is down to vendors that don’t want to or can’t change their basic architecture bc its expensive, complex, or just don’t get it. witness some of the most interesting re-architecting of the last few years: twitter, facebook, salesforce, microsoft dynamics, SAP… and some of the not-going-to: oracle, virtually every financial institution, most manufacturing (if not), healthcare, government, etc. notice a common trend? complex, monolithic solutions that are a beast to change (same as the first group) led by people who don’t want to invest in R&D and change (and use compliance and security as boggie men… different post, sorry). we have standards, we don’t have adherence.
2. who cares? no one who is looking at the future use of the application does not care. Y2K, Client-Server, Internet — all business shifts that were started by people who didn’t care for the long term. cloud computing is a commoditized conclusion at this point – not a maybe. if you are going down that road (and virtually all people, companies, and vendors are – thus commoditization) then you care about your model and implementation. private is a stupid idea and a misnomer used by vendors that don’t want to change and by lazy CIOs that don’t understand how to change. It is “acceptable” (by sheer volume, not by its own merit) as a transition step to public cloud (the only cloud) but it is an incredible waste of resources and money. Alas, that is how most biz operate – in short baby steps, and “private cloud” is one of them unfortunately.
3. the specific strengths of being able to access those resources is what baffles me. this is the main reason why cloud computing even exists as a model – what am i missing? you are saying that you want to be recognized for that ability – yet, decry cloud computing? if you are saying you can interconnect with any other system out there – sure you can. we’ve been doing it for many years – its cumbersome and expensive to do spaghetti networks of integrations and manageability is impossible over time.. but if you think that is better than using metadata and systems management in a proper cloud infrastructure – go ahead. long term you are wasting time and resources… not sure its the best way to do that.
4. the plug-and-play cloud (as you call it, cloud as i do) totally exists today: it is not being used bc legacy vendors cannot sell into it. the few up-and-comers that can sell into it are making a killing and doing a great job of leveraging those resources. i have clients using AWS and paying few thousand dollars a month in exchange for tens-of-thousands in revenue – while using minimum resources (people mostly). very profitable and they can change their system to take advantage of other cloud offerings in very short term. just bc large monolithic, single-vision companies are not using it doesn’t means it is not being done. i know cio’s that are so into cloud that won’t consider doing it any other way – even stating for the record they don’t care where the data or resources live, just that they are available (as it is supposed to be). there’s plenty of experiences around that and i will higligth them in this blog in coming months as time allows.
I would, finally, argue the opposite. let’s get the discussions out of the mud where they’ve been stuck for decades and imagine and build a better grounded model.
thanks for participating, always open to feedback and debate.
We disagree on just how integrated and easy it is to put services together in the Cloud as it is today. However, I too believe that the potential benefits of true Cloud computing are huge and game changing.
I also would be interested in you pointing me to this standardized definition that includes specific criteria to define if a software solution should be considered “public”, “private” or “hybrid” Cloud.
Let’s try talking in specific terms to see if we can get on a common plane.
How would you define a software solution that could be run on a company’s servers or on an unfettered AWS instance and was built using Web technologies to quickly accept functional updates and easily and quickly share services and data with other services on the Web? Would it be defined one way when run on AWS and another way when run on-premise?
I totally agree that some vendors totally bastardize “Cloud” when marketing their solutions. I also believe there are legitimate Cloud vendors that totally oversell the benefits, capabilities and costs of Cloud.
On a quick side. Running in the Public Cloud is certainly a great option that should be considered by just about everyone. However, believe it or not, the best option for many companies is still to run on their own servers instead of platforms like AWS. Of course, accessibility to/from the Cloud will almost always be vital.
few comments to the above….
the standardized definition is linked inside my book. hate to point you there, but don’t have the time to look it up right now – it was either reply to this or do that.
the definition for the solution running on-premises is not-cloud-but-on-premises. regardless of the technology used, the facf that it is in a protected network is the first indication, second is that the hw is owned by the solution-user, third is that it is unlikely pay-for-use by the transaction, fourth is that it cannot be easily replaced if necessary unless a new machine and solution is setup, etc.
see the point here? is not the technology, its the deployment that makes a difference… and without the openness of cloud, it is not cloud.
the best company for everyone is still running on open cloud. no one benefits from running on-premises. the ones that think they do don’t truly understand the value of cloud computing.
thanks for engaging…
So, are you stating as fact that the “cloud capable” application defined in my example would always be best run on AWS or another like platform service?
With all due respect, I know there are plenty of people like myself who have extensive real-world experience building, provisioning, scaling and paying for system infrastructures that reside on-premises and in the Cloud that believe your apparent Cloud-Only view of the world is faulty and dangerous for companies with lazy managers who fail to do their homework.
Again, I too believe that many CIOs inappropriately disregard the Cloud as a viable option for some of their software solutions, but I also believe that others jump in with little if any practical knowledge to fairly assess their options.
Looks like we agree to disagree, even with this discussion at 50 thousand feet.
Always? When did I say always? Let’s say as close to always as you can get without being an absolute. I never make absolute statements.
I am not judging your abilities to do it. I’m saying there is a better way. And yes, you need to do your homework beforehand. True.
We are not agreeing to disagree. You are not agreeing to my superior model. You are proposing faster horses because it is how we move around and we know how to take care of them. I’m saying let’s not use horses anymore even though they still get the same thing accomplished because there is a far better and faster and cheaper model. I’m also saying you need to trust me to see those benefits since we don’t have this new machine built yet.
And then you say…
Esteban: I’ll trust you when the “new machine” actually delivers what you are suggesting. Right now, it does not. In my opinion, the Cloud delivers tons, but not to the extent you are claiming.
We do agree that people need to do their homework. We did and it did NOT make sense to run our services via AWS or any other like platform. We do use AWS to provide geographic redundancy.
It’s pretty sad that others have not entered this debate. Most likely they are too “afraid” as you alluded to, but what exactly are they afraid of?
No matter how forcefully you and others try to make Cloud decisions such an absolute, they are hardly so black and white, especially when the debate moves from 20,000 feet to implementation realities.
I never said anything about absolutes – but the truth is: no war or battle has ever been born on mediocre terms throughout history. It is a world of 1s and 0s – not of 0.25s and 0.63s.
You want to see a revolution, a “disruption”? you need to go absolute.
“Implementation realities” are feeble attempts at status quo and an excuse. The reality is that the more you fight to “look at the implementation reality” the more the reality becomes the path forward (or rather not).
And that, in this case, is just unacceptable given the potential left behind.
You can call me (and others like me) anything you want, but the reality is that unless we adopt an absolutely different view of cloud computing we are going to continue paying vendors exorbitant amounts for limited value at best and not squander the potential in front of us.
that’s an absolute certainty.
Comments are closed.