At Premier Inc., we are fortunate to run a largely virtualized workload as we maintain our own private cloud. As we look to become more efficient over the next 18-24 months, our strategic plan includes moving away from a one-size-fits-all approach to cloud. To do this, we need to drill down and gain a better understanding of the varying degrees of compliance and regulatory oversight that our workloads require.
As we are able to rationalize individual workloads by regulatory and contractual commitments, we’re going to start to identify workloads that can move to alternate cloud providers or Infrastructure-as-a-Service providers. Ultimately, that will enable our team to leverage and build upon the infrastructures, compliance orientations, and certifications built into those individual infrastructure or cloud providers, without having to do all of those things in house.
For us, this prioritization involves looking at individual workloads and the data that those workloads manipulate. Does the data fall under PCI? Does the data fall under HIPAA regulations? Does the data fall under FISMA regulations? Classifying the data in this way helps us determine the options that are available to us for each particular workload.
We also must ensure that the resource consumed by a workload matches the need of the workload. That way, when we move it to an Infrastructure-as-a-Service provider or a Platform-as-a-Service provider, we won’t end up subscribing to more resource than we need. This can be a challenge for CIOs who do not have a show back or chargeback model in place to communicate the resource consumption and cost to their consumers.
Consider this example. If you have an internal application team who has asked for 15 servers, they may never know the cost of those 15 servers. If you then move that workload as is – 15 servers for 15 servers – to an alternate infrastructure provider, you’re going to pay a premium for that service. You’ll be paying for all the infrastructure and the staffing underneath those servers. And if your application is not sized well to consume all 15 of those servers fully, you may end up subscribing to more service than you need.
In this scenario, your cost may very well go up as you move to a cloud-based infrastructure provider. In the long run, it may give you some hesitation about moving additional workloads to cloud-based infrastructure providers, because the cost may seem either unpredictable or larger than what you originally thought.
It's worth it to figure out how you can do this effectively because I believe there are clear benefits of moving workloads to cloud providers. For one, it helps distribute risk by placing workloads in more than one location, or in more than one provider of service. It's also easier to meet a lot of compliance and regulatory objectives because you’re going to be leaning on providers that are on the hook to provide those certifications and commitments to a large number of companies.
A good example of this is SOC 2 reports, which is very common in the services industries. If you’re a Software-as-a-Service provider, you typically have a SOC 2 report that is applied to your entire application stack, everything from your data center facility all the way up to and through your application. If you have outsourced some portion of your application to an Infrastructure-as-a-Service provider, you can ask for their SOC 2 report, and you can incorporate it into your SOC 2.
This is just one example of the layering that can be possible, which can supplement or even take the place of some of the capabilities you are doing in-house. Ultimately, it can be easier to meet some of your regulatory and compliance objectives by leaning on other providers of infrastructure in the compliance workloads that they have to meet already.
If you can spend some time identifying the right workloads that can move to alternate cloud providers, you may be able to create more efficiencies and free up resources to work on the other areas of your strategic IT plan.