Sometimes, the meaning of a word or a phrase changes so quickly that you don’t even notice that it’s changed; at some point, you just realize that you’ve been using it differently. Â Take “on-prem,” for example. Not too long ago, if you said that a component of your IT system was on-prem, you meant that it was physically located at your facility. If it was hardware, the hardware was in the IT room down the hall. If it was software, it was running on a server in the IT room. But today it means something entirely different.
Image Source: bsdrocker on netowrking-forum.com
But when you say that something is “on-prem” now, what do you mean? Is it really in a room down the hall, or do you mean that you can control key elements of its infrastructure from your facility, even if that infrastructure is physically located at a different site?
In the increasingly virtualized world of IT, proximity is becoming irrelevant. It doesn’t matter where something is; what matters is how much and what kind of control you have over it.
Consider, for example, the basic practical differences between PaaS and IaaS. With PaaS, the infrastructure is typically a given: you build your site, you write your code, you upload it, and the platform/service takes care of the details. There’s very little about it (if anything) that could be considered “on-prem”. The tradeoff is that while you give up control of the infrastructure and have to essentially take the options that the PaaS provider offers you as-is, you no longer need to spend time and effort provisioning and configuring that infrastructure.
This isn’t the first time that the IT world has experienced a large-scale shift from “hands on” configuration to automated “hands off” configuration. Until the late 90s, installing any kind of peripheral device was strictly a “hands on” affair in the literal sense of the term  —  you had to manually set DIP switches or jumpers on the device, as well as adjusting the IRQ and DMA settings on the computer and checking for conflicts with other devices. When plug-and-play became the standard for installing and managing peripherals, it did take away some of the control over device and system settings which had been a part of manual installation, but hardly anyone saw it as a loss. For one thing, it eliminated the frustrating and tedious labor associated with installing peripherals, and more often than not, there was no real advantage to having direct control of hardware settings other than the fact that manual installation required such control. Instead of spending time tweaking the configuration of a peripheral, you could concentrate on getting the best possible use out of it.
Which brings us back to the question of on-prem vs. not on-prem. A highly non-on-prem service such as PaaS is basically a kind of abstracted plug-and-play IT; it frees you of unwanted labor and generally unneeded responsibility for the infrastructure, allowing you to concentrate on making the best use of the services that it provides. It is off-prem not just in the physical sense, but also because you don’t have to do the contemporary equivalent of setting DIP switches or sending it printer escape codes.
And on-prem IT? It consists basically of those elements of infrastructure which for one reason or another you do maintain more direct control and responsibility. It can be physically located at your site, but more often than not, it’s likely to be cloud-based IaaS, and the real difference between on-prem and off-prem will simply be whether or not you need to take control of the infrastructure layer of a service. On-prem is defined not by its location, but by what you can or need to do with it.
Consider what this means in relation to the hybrid cloud. How important are strict definitions of such things as “private” or “public” cloud services, and where do you draw the boundaries between them? Â If the physical location of the infrastructure is irrelevant or meaningless, then any definitions or boundaries have to be based on functional and practical considerations. Â Can you take this service as a given, with no thought to the underlying infrastructure? Â Do you need to configure that service at the infrastructure level? Â Are you simply uploading code, and trusting the built-in services to run it correctly, or are you looking at the cloud equivalent of bare metal?
Ultimately, the answers to these questions are going to be based on your organization’s specific IT needs, and on what’s convenient. If it’s easiest to handle some elements of your IT system by means of applications running on a PaaS platform, that’s what you’ll do.  If it turns out to be necessary (or convenient) to configure a large database on a bare-bones IaaS system, you’ll do that as well.  How you categorize these elements may not be particularly important  —  it might turn out, for example, that with a few changes in requirements or in available services, it would be more convenient to handle the database by means of off-prem PaaS services, or it might become necessary to deal with the applications in an on-prem IaaS environment. Â
So rather than thinking in such location-based terms as “on-prem” and “off-prem”, it makes more sense in the contemporary IT world to think in terms of what needs to be done, and what the best ways are to do it. Â The concept of “where” simply doesn’t mean very much any more; physical proximity has been replaced by “degree of control at the infrastructure level”, and even that is based on convenience, or on the specific requirements of the situation. Â “On-prem” isn’t “where” Â — Â it’s what you do with it.
