I vividly remember the process of changing TV channels when I was a kid. Turn the channel select knob, turn a dial to rotate the antenna, then make fine adjustments to tune in the channel. This process usually resulted in an adequate picture, but it required considerable effort, the quality of the picture was inconsistent, and the viewing options were limited to two or three channels.
Now I have access to many channels, no tuning or antenna adjustments required. All is good until a thunderstorm takes out a junction box or some yahoo with a backhoe slices the cable and service is lost, and depending on the timing of the outage my mood can vary from acceptance to maniacal - as I wait to be returned to my normally scheduled programming. Yeah, I’m spoiled. I have come to expect a certain level of service.
How can we compare this to on-site and cloud IT models?
My childhood experiences with TV are similar to the on-premises IT model. As a kid I trusted that when I turned on the TV, I would have access to shows - just as on-premises IT is trusted to provide secure and high-availability computing services. However, the quality of the picture and access to channels was limited - just as budgetary constraints often force IT to leverage the hardware and personnel they have at hand. As I had to accept the limited access, the lines of business must often accept what IT provides.
My current-day experience with cable TV service is similar to public cloud services. I have access to high quality TV viewing, ease of use and nearly uninterrupted service – until it is interrupted, and then I am at the mercy of the cable provider. Similarly, public cloud services provide access to hosted computing power that is easy to access, and highly available, as in uninterrupted service – until it is interrupted. Just as I expect a certain level of service from my cable service provider, so do businesses have expectations of public cloud service providers.
There are valid arguments for on-premises IT and public cloud services, and there are real reasons to support both environments co-existing within IT departments. The best guidance I have heard on migrating workloads to public cloud services is to move workloads that make sense, when they make sense. Increasing numbers of SAS customers are moving workloads to public cloud services, and SAS 9.3M2 customers can take their SAS on-premises licenses to Amazon’s Virtual Private Cloud (VPC) to deploy and access SAS products on Amazon.
Hopefully, this analogy conveys the idea that we already rely on services throughout our lives. There are other services that more closely align with cloud computing, such as movie viewing options: theater, on demand cable/satellite, rental; and the evolution of power delivery: from windmills and waterwheels to the modern-day power grid. While some view cloud computing cautiously - from the perspective of risk and loss of control - leveraging services to improve our lot is not foreign concept.
Every service may not be well-suited for everyone - while I could take advantage of public transportation, I have chosen to not move that workload to the public transportation “service provider”. On the other hand, it makes sense to rely on my cable service provider to deliver my TV services – for now anyway, but I have been researching online video services. Regardless, I do not miss the manual process and effort of changing channels, and I’m glad to not have to climb up on my roof to work on the TV antenna from time to time, as my dad had to do.
How do you decide which workloads to move to service providers?