There’s been lots of talk about “Cloud Computing” for a long time now of course. A term that never really got much traction was “Utility Computing”. Wikipedia defines it as
Utility computing, or computer utility, is a service provisioning model in which a service provider makes computing resources and infrastructure management available to the customer as needed, and charges them for specific usage rather than a flat rate. Like other types of on-demand computing (such as grid computing), the utility model seeks to maximize the efficient use of resources and/or minimize associated costs. Utility is the packaging of system resources, such as computation, storage and services, as a metered service. This model has the advantage of a low or no initial cost to acquire computer resources; instead, resources are essentially rented.
I mostly agree with that, with the exception of the metering part, something that certainly has existed in platforms like vSphere for many years, but it’s never been anything I have gotten involved with or ever had interest in.
To me, Utility Computing is basically utilizing server virtualization, along with storage virtualization, and in some cases network virtualization as well. Network virtualization only really goes so far. Many hyper converged solutions claim network virtualization but at the end of the day once the traffic leaves the host it goes on a real network, and it’s rarely virtualized at that point (almost never, really). Don’t listen to what people may tell you, a VLAN is not virtualization, it is a poor man’s segmentation.
(Side note: The Ethernet switches I use from Extreme Networks actually do have some virtualization abilities in them, called “Layer 3 Virtual Routers“, or “Virtual Switches“(two different PDFs from different eras, may have slightly different info), in which you carve the switch up into virtual switches, VLANs can only belong on a single virtual switch. The virtual switches cannot talk to each other without a bridge or a router. One way for two virtual switches to talk to each other is to literally connect a cable between two ports on the same switch that are assigned to different virtual switches. In most cases this would cause a loop, but not in this situation. Virtual switches can have overlapping IP spaces as well. You can even “tag” virtual switches across uplinks to other compatible switches. It’s really quite useful, I have been using this feature since 2005. My production Ethernet network leverages four virtual switches(and 38 VLANs) today.)
I never really thought of the term Utility Computing much myself, until I was introduced to 3PAR Utility Storage back in 2006 (3PAR was acquired by HP Enterprise in 2010, the brand has since been dropped but from what I can see the technology lives on in 2025 in other products). The fact that they used the term “Utility” in their name made me think about the computing aspect of IT.
So you have the ability to create virtual machines of pretty much any size(depending on how powerful your hardware is), and the storage platform is super flexible as well, maximizing efficiency.
If you are used to running the VMware hypervisor by itself, or even with vCenter, and really even if you use VSAN or another hyper converged platform, at their most basic level that is Utility Computing (in my mind anyway). Same goes if you use Proxmox, or Hyper-V, KVM, Xen, or any other hypervisor. It’s a very basic concept.
In my opinion, the vast majority of organizations only need Utility Computing.
Where things can get more complicated is dealing with people who want more. They may want “Infrastructure as Code”, they may want to have everything running with Terraform, or maybe they want Kubernetes. They may want flat out cloud stuff, whatever else it may be. The decision to make is – is it worth the time and money to go down that path, what is the value we get out of those things, and what are the costs associated with achieving them. This is where I believe most organizations fail, because they don’t realize in many cases these solutions are looking for a problem to solve, usually one that doesn’t exist in the Utility Computing model.
Because I believe such a path is a fairly slippery slope, and most organizations do not need that. In fact I believe already most organizations don’t do those things to begin with. There is endless talk about these technologies in news and social media. But the real market penetration of true cloud computing is still low relative to the entire market as a whole(well last I checked it was well under 50%, and you should subtract more from that as many organizations that use public cloud don’t do those things themselves anyway, or if they do they often do them quite poorly. Sorry for now you’ll have to take my word for that, or don’t, I can’t find examples at the moment, but have seen many times people talking about this very issue).
I can speak from professional experience myself having worked with people who wanted to go down that path, and went down that path to some degree, only to really have it be a wasted effort(thousands of hours of wasted time), and at the end of the day all of the things related to concepts like “Infrastructure as Code”, deploying systems with Terraform, and even Kubernetes be completely ripped out because they solved problems we didn’t have. Not only that, but they introduced massive amounts of needless complexity that we didn’t have the resources to manage properly. I realized this before anyone ever started down that path, but it took others literally years to realize I was correct from the beginning.
That said, on the “Infrastructure as Code” aspect, I will say I do fully support the usage of Configuration Management systems. In my case for the past fifteen years I have used Chef(or CINC which is an open source build). The people that ran Chef were rabid IaaC fans. I can see use cases for the technology for sure just not at the scale any company I have worked for has operated at. So yeah, I use Chef, but we don’t use it in even a remotely IaaC way. There was an effort about a decade ago to go down that route, but as mentioned above, it was abandoned. Prior to Chef I used CFEngine for seven years, so a total of just over twenty years of using Configuration Management systems on Linux. While things are checked into source control, and from a high level may look like IaaC, if you dig deeper you would find many of the things IaaC wants you to do, are things we never do, because we don’t need to, solving problems we don’t have again. Leveraging Configuration Management software alone you can scale an environment really to thousands of systems without much effort.
I have had people flat out say to me they want to use this or do that because it would help their resume, or because it is “on trend” on many occasions over several years. It may very well be good for the resume, but the flip side is true as well they were not needed because our Utility Computing model was simple and reliable.
“Cloud Computing” has a whole different number of layers on top of Utility Computing to create the cloud part. If you are using KVM for example for Utility Computing, if you wanted to move to Cloud Computing with KVM one obvious choice is OpenStack. If you are in the VMware ecosystem, the obvious choice is VMware Cloud Foundation. Other hypervisors may not have available solutions out of the box to do cloud stuff. I’m pretty sure I have read that some hyperconverged systems like Nutanix have a full cloud level offering, others may have as well. I have been waiting for a “user friendly” version of OpenStack since 2011, well I stopped holding my breath a long time ago, I don’t expect it may ever arrive(fortunately I don’t need it, but the idea sounded neat at the time).
Just talking out of my backside here but I’d say if you are managing more than 5,000 systems depending on your workloads, Utility Computing may not be suitable for you at that scale. But if you are deploying 10,000 servers that are basically mirrors of each other(big web farm hosting the same app stack for example), then I think a simple model is still better in that situation.
Don’t forget about bare metal either, especially if you need a lot of compute. Myself I have been leveraging LXC on bare metal Linux systems for over a decade for stateless web services, with wonderful results.