Over the last six months or more, I have been talking with customers that are in very different situations from the ones that I have worked with in the past. Most of the customers that I get brought in to talk to are ones that are usually well into their Cloud journey and have a good understanding of the value it provides. They usually already have as much as half or more of their overall system footprint in one of the major cloud vendors.
However, there are a lot of customers who for any number of very important reasons, would like to migrate one or more of their data centers into the Cloud and do it in one big motion. Although this is a viable migration strategy and there are some great tooling that make this process a lot easier than it used to be, there are a lot of pitfalls. For example, it should always be best practice to perform this migration in a very strategic manner building up the right base for Cloud use before moving the first VM. In other words, the design process for the “Target” environment in the Cloud is just as important as the migration itself.
What I would like to talk about in this article, is the best practices and processes that I believe should be followed by many to most of the customers that are looking at a Data Center migration to the Cloud. Most if not all of these best practices can be considered as Cloud agnostic and should be considered during your migration no matter which of the major Cloud providers you may choose.
Governance & Compliance
The term Governance & Compliance can have different meanings to different people and within the scope of the Cloud, it can have different meanings again. All of that being said, in my opinion, it is one of the areas that cannot be overlooked when planning a new Data Center migration because it can definitely have long-term ramifications and be extremely difficult to re-mediate if you don’t deal with it early on.
When I talk about Governance & Compliance with respect to the Cloud, I typically refer to items like auditing, tagging & naming conventions, cost controls, and resource policies just to name a few. Each of the major cloud providers provide different ways for handling each of these areas. Before you sit down to have these conversations, let’s make sure that you have a good understanding of what I mean by these terms.
- Auditing – Each of the major cloud providers will provide some level of auditing usually for free. This feature is pretty straight forward and will usually be available out of the box, but if you want long-term reporting, then you will need to figure out a way to store the data associated with the audit. The audit trails will typically contain information about each action that is performed within your Cloud account such as:
- Who performed the action
- Timestamp
- Type of Action performed
- Status of Action
- Which Cloud resource the action was performed on
- Tagging & Naming Conventions – This item of governance & compliance will not have long-term ramifications if you don’t get it right the first time, but it could make the administration of your Cloud Account difficult for your Cloud Admins, Architects or Engineers. In addition, this item can be very difficult to re-mediate if you make changes in the future, so please keep that in mind.
- Cost Controls – This is the one that almost always comes back to bite people if they do not think about it before migrating. In addition, the implementation of cost controls usually requires some kind of conversation with people from finance and if the migration project is instigated by a member of the Technology organization, this can easily get overlooked. All cost controls can easily be segmented and applied based on how you organize your resources into Accounts/Subscription, Resource Groups and/or can be tied to Naming and Tagging conventions. The implementation of cost controls refers to things like:
- Cloud Budgets
- Charge Back Models
- Segmentation of Resources across different Accounts of Subscriptions
- Resource Cost Reporting
- Resource Policies – This is a difficult one because not all of the major Cloud Providers are made equal with respect to this functionality. The idea of Resource Policies is to put rules in place that can prevent users from performing actions that will go against specific business/enterprise/security or security related compliance definitions or enforce specific rules. For example, enforcing that a Storage Account has encryption turned on by default, might be an enforcement policy created by someone from the Security team. At the same time, someone from It might want to prevent users from creating resources in specific geographic regions that are not viable for the business.
Some of these items can absolutely be put in place after you have already started your implementations within the Cloud, but some of them can be extremely difficult to retro fit after the fact. I highly recommend to all of my customers that they spend the required time to sit down and design out each of these areas before starting their migration projects no matter which of the major Cloud vendors they might be using.
Identity & Security
The next major area that requires some level of discussion and maybe design before a migration project gets under way is around Identity & Security. I do realize that I talked about Security in the above section on Governance, but that was focused on Security Rules and Policies and how to implement them within your given Cloud Provider. What we need to talk about here is actually the very first piece of a Cloud implementation and that is user security, such as access control and permissions with your given Cloud provider.
For most organizations, this discussion will start with Active Directory as that does seem to be the de facto standard for the management of users and groups. It is these users and groups that are then used to determine access control within the Cloud Provider for the following:
- Who Can do actions within the Cloud Provider
- What actions can those User perform within the Cloud Provider
- When can those users perform those actions
- How do they Access the Cloud Provider and be Authenticated
Each of the Cloud Providers have different levels of integration with Active Directory and require different levels of initial configuration, but setting all of this up should be your first discussion point. One thing to keep in mind is that Microsoft Azure does have a built-in integration with Active Directory as it does have a Cloud version that is part of all its Cloud properties.
NOTE: One topic that should be discussed with IT before you start implementing any system in your Cloud provider is Active Directory Domain Controllers. If you are implementing a lot of Infrastructure as a Service (IaaS), then the question is extremely important because you will probably need them, but not necessarily if you are using Azure. Azure provides a lot of the same services that AD DCs provide and you might want to look at using more Cloud Native services. So make sure to talk about this before moving forward too quickly.
Networking
Once you have talked about the basic components mentioned above, you can finally start to think about the deployment of your systems into the Cloud. Most of your systems already have a clear architecture and defined ways of either talking within themselves or with each other. However, to make sure that those systems continue to function the same, it will be important to deploy a Network within the Cloud that can allow this to happen.
FIRST
A base Network will look and act very much like your On-Premises VLANs, but that is where the similarities both begin and end. You will want to start with one single Network and then can grow from there based on your specific system requirements. I say this, because the most important thing to setup before any systems are migrated is any Hybrid connectivity that will be required and this is done through a VPN connection which will connect to that first Network. You will need to understand the different VPN options for your Cloud Provider and then decide which one to implement based on the amount of data and bandwidth requirements that you have. Each Cloud Provider have different options that support VPN connectivity, ones that work as a IPSec tunnel over the internet and others that require a dedicated physical circuit is put in place between you and your Cloud Provider.
SECOND
Once you have your base network and Hybrid strategy, it is now time to talk about specific networking requirements. The starting point for that is around your High Availability and Security hardware that you may have On-Prem. I bring this up, because although all the major Cloud Providers all have native networking services that provide load balancing, firewalls and the like, it does not mean that they will meet all of your specific requirements in those particular areas. In addition, I have worked with a lot of customers that have had a significant investment in a particular networking vendor, like BigIP, Cisco, Barracuda, etc. Maybe your IT organization is extremely familiar and comfortable with a particular vendor and want to reduce the migration support required by sticking with something that they know.
No matter which of these reasons or scenarios best fits your organization, let me introduce you to the virtual appliance. All of the major Cloud Providers have a “marketplace” where you can purchase Virtual Machines that have been created and are supported by many of the major networking vendors including the ones that I mentioned above. These VMs are virtual representations of the hardware that you currently have On-Prem and are typically called Virtual Appliances or NVAs. In some instances, you can even transfer the configuration files from your On-Prem hardware directly into the Virtual Appliance making your migration efforts a lot easier. With all of this information, make sure that you do your research and talk internally to determine if you want to use NVAs or use the Cloud Native networking services.
LAST
The last thing to discuss is how you are going to implement the network within your preferred Cloud Provider and understanding what native services you will need to use to make sure that your systems have not just the same level of functionality, same level of traffic flow, but also the same level of security. Remember I stated earlier that it is important to understand that Cloud Providers use Software Defined Networks, so there are going to certain features and functions of the networking services that are made available that would be extremely difficult to implement in a On-Prem environment. So getting a thorough understanding of the native services will help you understand how best to implement your network.
Operational Management
The last area to discuss before starting your actual migration is how you are going to manage and maintain the Cloud environment once the migration is complete. There are two main areas to talk about and you may already have some pretty strong opinions on how you might want to handle them.
Monitoring & Logging
Once your systems have been migrated, how are you going to make sure that they are performing as expected, especially those mission critical systems like your financial systems or your systems that have to be up 24×7. If you have systems like that On-Prem, then I am sure that you already have tools that you are familiar with and already understand your applications.
Just like I mentioned above in the Networking section, there are appliances that you can deploy with your favorite Monitoring & Logging tools like Zabix, SolarWinds, NewRelic, etc. However, all of these tools rely on not just metric data from the virtual machines or applications, they also rely on log files and you will need to think about how to get the logs from your Cloud resources into there systems. This will absolutely add a layer of complexity to your overall Cloud migration.
You absolutely can move forward with your existing monitoring & logging tools, but I would highly recommend looking into your preferred Cloud Provider’s native tools and there are a number of reasons for doing this. The level of integration that you get between the resources that you deploy your systems/applications into with their native tools will be much better than what you will have to do with your third-party products. In addition, the cost of using the native tools will traditionally be considerably less than what you are paying for your third-party tools. In some cases, the functionality that you will get may even be better than what you get from your third-party tools.
System Maintenance
This is a pretty broad category, but when I talk about maintenance, I talk about things like Configuration Management, Backup/Restore, Disaster Recovery, and Automation. This covers a lot of different systems that you probably have in place for your On-Prem environment, but I will tell you right now, that none of them will work as well in the Cloud as what the Cloud Providers have natively, with one exception and that is around configuration management.
Let’s start with something easy and that is Backup/Restore and DR features. Most Cloud Architects agree that there is no reason to maintain your third-party tools for these functions. They are too hard and expensive to maintain and there are not that many of them that are designed well to work in the Cloud. All of the major Cloud Providers provide native services that are extremely inexpensive in comparison and you don’t have to worry about maintaining storage, because the Cloud is infinite in that regard.
With respect to Configuration Management and Automation, I am a little torn on how to talk about this. Although the major Cloud Providers all have the capability, none of them do it as well as Chef, Puppet, or Red Hat’s Ansible do it natively. In fact, AWS provides both Chef and Puppet as a service to try and get customers to user their native services rather than brining your own Virtual Appliances into the environment. The other Cloud Providers do have their own services, but they aren’t as good in my humble opinion and not a full featured as the third parties I already mentioned.
All of the Cloud Providers have automation capabilities, some of them are built-in where as others just allow for you to build CLI scripts that can be run from a Cronjob server or Windows Scheduler service. Make sure that you read up on what they do provide, because you can probably move your own scripts directly into your Cloud so that they work the same in the Cloud as they do On-Prem.
Conclusion
I am sure that you have noticed that I did not talk at all about how to migrate your actual machines or applications into your preferred Cloud Provider. That was by design because there are plenty of tools and articles that talk about how to migrate and/or modernize them depending on which Cloud Provider you are working with. In this article, I truly just wanted to focus on the important topics and questions that should be focused on before the migration activities occur.
- What questions should you be asking before starting?
- What areas of research should you be doing to understand the Cloud native services provided?
- What discussions should you have and with who? (This is not just an IT journey)
- What policies should you have defined ahead of time? (Permissions, Tagging, Resource & Feature policies, etc.)
I hope that all of this is helpful and makes you more successful in your migration. GOOD LUCK.
