Cloud Migration Part 1 - Governance
Now that your company has decided to migrate to the cloud and you have completed your preliminary resource and budget planning, what’s next? Often times, companies try to jump right into the migration without focusing on some items that may come back to haunt them down the road. In our opinion, one of those big ticket items is Cloud Governance.
Cloud Governance can be defined in many different ways, but the way we think about it is creating defined policies to control user access, cost, and resource deployments.
Let’s start with user access, which can get messy in cloud environments especially if you have many cloud resources and many users who want to be using them. Before migrating to the cloud, it is recommended to set up Security Groups who will have specific roles to access specific resources within the cloud. These Security Groups could be just within IT, or span the entire company depending on what resources are being accessed. Of course, over time you will need more Security Groups and they will likely evolve, but creating the base Security Groups and policies around them is a must before starting your cloud migration.
Cost can be easily controlled within a properly governed cloud environment. First, how granular is your budgeting strategy? Do you look at how much you are spending just in IT resources as a whole? Do you get to the department level? Do you get to the application level? Do you get even more granular? You can track costs using any of those strategies, but defining the way you want to track costs before you start spending in the cloud is an important step. Once these policies are defined, you can then group together the related resources and provide cost limits or budgets, where you could set a hard line on how much could be spent by a specific department, or track if they are going over budget or not but not prevent them from spending more than $X.
Governing resource deployments is the most complex piece of Cloud Governance because there are so many different avenues that can be explored. One of the first things to consider is how are you splitting up your environments? Are all of your resources going to fall under a single managed subscription? Or might you break it down into Prod/Stage/Dev (or whatever your preference might be) subscriptions? Or will you get even more granular than that? Of course there are pros and cons of any of these approaches that could make your team’s life easier or more difficult depending on how many resources you have. The next thing to consider might be resource naming conventions. How are you going to track which of your resources does what if they are not consistently named? You can run into real trouble when some people know what some resources do, but not others, which makes having a consistent naming convention extremely important when it comes to resource deployment. There’s much more to get into, but the last point I’ll hit on will be resource deployment policies. It’s a very general topic at its core, but there are so many options with what you can do. Do you want to limit VM deployments to certain sizes? Do you want to limit deployments to specific regions? Do you want to make encryption required before deploying blob storage? Do you want some of these policies to be applied in some places and not others? These are just some of the many options you have available to you when it comes to resource governing in the cloud.
Stay tuned for the next blog about Infrastructure Configuration!