The first is to make sure that your move to the cloud is business-driven. Each of the pros and cons of a cloud solution can be balanced. However, you want to make sure that the effort of a migration to the cloud is balanced by the business value you’re going to get.
For example, the cloud handles Big Data well. However, if you don’t need to work with Big Data, and you’re not doing Internet of Things, and you’re not doing data science, and if your on-prem solution is working perfectly fine, then moving to the cloud just for the sake of it may not be the right driver.
You also need to have a migration strategy. What happens when you migrate any on-prem solutions to the cloud? Is there enough value in that refactoring? In many cases, there can be cost savings and a benefit. However, you should understand what you’re trying to get out of it before you take on that effort.
Change Management and Best Practice Guidelines
It’s also important to have a change management strategy in place. If there are new tools and new skillsets that you want to take advantage of, who are you going to train on that? What is that process going to look like? Will end-users be impacted during that change?
As you go through those processes, it’s also important to make sure you’re documenting guidelines so other team members can understand your best practices.
Understanding the Pricing Model
Understanding the pricing model is also important. There are various service offerings available like Infrastructure-as-a-Service, Platform-as-a-Service, and Software-as-a-Service. Some offerings might be capacity-based: as soon as you provision it, you’re starting to pay for it whether you use it or not. Others are consumption-based: if you provision and don’t use it, you’re not paying anything. Some might automatically scale, so heavy usage may result in increased and unexpected costs.
You should understand the upfront pricing so you’re not surprised. Estimate your costs and validate against actual costs. You should also regularly validate your usage and needs against the actual invoice to make sure you are getting the most out of your solution. Are there opportunities to scale down certain resources (based on usage metrics)?
Preventing Unexpected Costs in the Cloud
When I gave this webinar, one of the Q&A questions was how to prevent unexpected costs with a move to the cloud. My tongue-in-cheek answer was that the best way to prevent unexpected costs is to get burned once. Probably everybody early on in their experience accidentally leaves something running, scales it too high, or forgets to pause or stop it. Ultimately, those costs continue to accrue, and then you realize you’re out of credits or you hit your budget.
I think learning that once gives you the “Oops” feeling that makes you keep a better eye on it in the future. Generally, that’s a good experience, but you’d obviously like to avoid that altogether.
There are several options depending on how you’re paying for your service. Many of us can sign up for a free trial and start working with the data costs there. Or, if you have an MSDN subscription, you get monthly dollars (credits) to work. You can also set a budget on a subscription and have alerts around that. If you assume your average cost should be a certain amount, you can set up an alert for when you’re getting close to that. That can be useful.
Be Attentive to Invoices
It’s also important that the people who are responsible for the various components pay attention to their invoices. They should verify that there aren’t unexpected costs. Have an invoice approval process where individuals close to the work are included in the review.
For a large organization that wants to get a little more sophisticated, you could start having your own reporting around cloud costs and watching for any unusual spikes. There’s even a nice API around Azure resource usage. But having a budget and making sure you’re being diligent about reviewing your invoices is a good place to start.
Is Skyline in the Cloud?
We’ve also been asked if Skyline Technologies is in the cloud. The answer is, “Yes!” Skyline is entirely in the cloud. We did an evaluation of all the various servers we had and an analysis of what we thought the benefits would be. This is what we recommend to clients, and we did it ourselves. We didn’t want to assume there would be a benefit.
On its own, that assessment process can offer a lot of value because it has you inventory every server, note how it’s being used, and look for opportunities for consolidation. We went through that process, and we eventually moved each of our servers into the cloud. It went so well that most of our associates didn’t even realize we moved into the cloud, which is a success in itself.
Done right, the transition to the cloud can have minimal impact on your average user. You can have virtual networks and other options to create a high-speed link between the cloud and your on-premises network. So, as some of your servers and systems move to the cloud, users can still access them in the same way they did. If they open SQL Management Studio and type in a server name, the user can now access that same server in a virtual machine in the cloud vs on-premises.