Migrating to the cloud from on-premises
A new company starting up today can build its IT services as cloud native from day one. These born-in-the-cloud enterprises arguably have a much simpler route.
For existing businesses, especially larger ones, they must consider how any cloud-based service operates with existing applications currently running within their infrastructure.
Even when a corporation chooses to migrate to the cloud, this is rarely performed in a single big-bang approach. Tools exist to perform a lift-and-shift copy of existing servers to VMs, but even this takes time and lots of planning.
For such companies, consideration at each step of the way is crucial. Individual services don't always run on a single piece of hardware—even websites are generally split into at least two tiers: a frontend user interface running on an Internet Information Services (IIS), with a backend database running on a separate SQL server.
Other services may also communicate with each other—a payroll system will most likely need to interface with an HR database. At the very least, many systems share a standard user directory such as Microsoft Active Directory (AD) for user authentication and authorization.
An architect must decide which servers and systems should be migrated together to ensure these communication lines aren't impacted by adverse latency and can move independently with adequate cloud-to-on-premises network links. Should we use dedicated connectivity such as ExpressRoute, or will a virtual private network (VPN) channel running over the internet suffice?
As already discussed, as we move to the cloud, we change from an inherently secure platform whereby services are firewalled off by default, to an open one whereby connectivity is exposed to the internet by default. Any new communication channels from the cloud to your on-premises network, required to support a potentially long drawn-out migration, effectively provide an entry point from the internet back into your corporate system.
To alleviate business concerns, a strong governance and monitoring model must be in place, and this needs to be well designed from the outset. Will additional teams be required to support this? Will these tasks be added to existing teams' responsibilities? What tooling is used? Will it be your current compliance monitoring and reporting software, or will you have a different set for the cloud?
There are many different ways to achieve this, all depending on the answers to these specific questions. However, for those who wish to embrace a cloud-first solution, this may involve the following technologies:
- Azure Policy and Azure Blueprints for build control
- Azure Recovery Services
- Azure Update Management for VM patching
- Azure Security Center for alerting and compliance reporting
- Azure Monitor Agent installed on VMs
- Azure Monitor
- Azure Log Analytics and Azure Monitor Workbooks
Although these are Azure solutions, they can, however, also be integrated with on-premises infrastructure as well. The following diagram shows an example of this:
Figure 1.6 – Cloud compliance and monitoring tooling
As you can see, having a well-architected framework in place is crucial for ensuring the health and safety of your platform, and this in turn feeds into your strategies and overall solution design when considering a migration into the cloud.
Once we have decided how our integration with an on-premises system might look, we can then start to consider whether we perform a simple "lift and shift" or take the opportunity to re-platform. Before making these choices, we need to understand the main differences between IaaS and PaaS, and when one might be better than the other.
