When I flick on the light switch, I am consuming electricty. It doesn’t matter to me at the moment of consumption where it is coming from as long as:
- It is there when I want it
- It comes on instantly
- It delivers enough of it to power the bulb
- It doesn’t cause a breaker to trip
- It doesn’t cause the bulb to explode
So that’s the consumption model. That’s independent of the provisioning model – at least as long as those requirements are met.
I could satisfy that need through several mechanisms:
- I could have it delivered to my house from a central distribution facility
- I could make it myself
- I could steal it from a neighbour
Regardless of which provisioning methods I use, I am still consuming the electricty. The lightbulb doesn’t care. However the CFO of the birdhouse does care. Thinking about the service of electricity – it’s about how I procure it and pay for it, not how I consume it. Sure I can add elasticity of demand, it’s summer and I am running the air conditioners throughout the house and both oven are on and every light…..But that is a requirement on how I procure the service not on how the devices use it.
Similarly in the software defined infrastructure world, the application that is running doesn’t really care how the infrastructure it is running on was provisioned. The “as a service” part of IaaS is about the procurement of the environment on which the application runs.
The procurement model can, of course affect the physical environment of the equipment. Just as delivering electricity to my house requires cable, effects on the landscape, metering, centralized capacity management we have to have those kinds of capabilities in our IaaS procurement worlds. No argument there, but at the end of the day it’s about how the capability is delivered and paid for, not in how it operates that really matters.