Tallan’s Cloud Transformation Framework is our proven approach to helping clients evaluate, implement, and adopt cloud technologies to transform their business.  Our framework is centered around helping you create and ultimately implement the necessary business and technology strategies required to successfully utilize cloud technologies for your organization. This is the conclusion of a three part series introducing Tallan’s Digital Accelerator. Part 1 and Part 2 serve as the Envision and Roadmap phases.

Establish

Now that you’ve done extensive planning around understanding your business drivers & outcomes, defining your desired strategy, and creating your migration roadmap, you are now ready to establish yourself in the cloud.

The first step is to develop a “landing zone” that has been provisioned and prepared to host workloads that are being migrated from on-premises to Azure.  When designing your landing zone, you will want to define considerations around:

• Infrastructure
• Data
• Governance, security, & compliance
• Operations & business continuity
• DevOps/deployment process

Infrastructure

When considering your infrastructure in Azure, there are multiple core areas you will want to begin including.

Azure AD

Your Azure AD tenant will provide identity access management to ensure that authenticated and authorized users have access to only the resources for which they have access permissions. 

Ultimately, Azure AD becomes the access gateway within infrastructure for applications and services both deployed in Azure and outside of Azure.  If you are an organization that already uses an on-premises active directory, you can utilize your existing infrastructure and extend authentication to the cloud by integrating with Azure AD.

Additionally, one key to success is ensuring that both your O365 and Azure subscriptions are backed by the same Azure Active Directory from the beginning.

Network topology and connectivity

Network topology is critical to the foundation of your infrastructure footprint in Azure. It defines how applications can communicate with each other.  As part of your landing zone preparation, you must identify the networking capabilities that your landing zone will support. When defining your network topology, there are generally two approaches that businesses take: Azure virtual WAN vs. traditional topology.

Generally, the virtual WAN approach is preferable for large deployments or for when a customer needs to connect global locations to both Azure and on-premises. A traditional topology approach is for those with smaller scale deployments in just a few Azure regions.

In terms of connectivity, Azure ExpressRoute generally allows for dedicated private connectivity to both Iaas and PaaS services in Azure from on-premises locations.  In terms of configuration, this will vary based on the scale of your deployment and other considerations like your decision on leveraging IaaS or PaaS services in Azure.

Some key questions to ask yourself will be:

• Will your workloads require a virtual network?
• Will your workloads require connectivity between virtual networks and your on-premises data center?
• Will you need to inspect and audit outgoing traffic by using on-premises network devices?
• Do you need to connect multiple virtual networks?
• Will your workloads be accessible over the internet?
• Will you need to support custom DNS management?

Compute Options

When reviewing compute options in Azure, it is essential to consider the needs around your workload’s governance, technical, and business requirements.  Part of creating your landing zone from an infrastructure perspective entails identifying all the compute resources that your landing zone will need to support.  To do this, you must assess each application and service to determine both the compute and hosting requirements.

Beyond your compute options, you will also want to consider which Azure region(s) you will need to deploy resources to.  It is important to note that not all Azure regions support the same types of services, so once you identify the compute options needed for your workload(s), selecting Azure regions is a natural next step.

Some key questions to ask yourself when considering compute options will be:

• Are you building new applications and services or migrating from existing on-premises workloads?
• If you are migrating existing workloads, can they take advantage of modern cloud technologies?
• Can your applications or services take advantage of containers?
• Are your applications web-based or API-based, and do they use PHP, ASP.NET, Node.js or similar technologies?
• Will you require full control over the OS or hosting environment of your workload?
• Will your workload involve high-performance computing capabilities?
• Will your application use a microservices architecture?

If you are migrating existing workloads, can they take advantage of modern cloud technologies?

Storage Options

Having proper storage capabilities are critical to supporting your workloads and the services being hosted in the cloud.  Storage in the cloud is generally highly available, secure, durable, scalable, and redundant.  As your workloads grow with your business, considerations around storage will become critical in helping you prepare and plan for future data storage needs. This is especially accurate in regards to security, regionality, data residency and compliance.

Key questions to ask:

• Do your workloads require disk storage to support deployment of IaaS virtual machines?
• Will you need to provide downloadable images, documents, or other media as part of your workloads?
• Will you need a location to store virtual machine logs, application logs, and analytics data?
• Will you need to provide a location for backup, disaster recovery, or archiving workload-related data?
• Will you need to support big data analytics workloads?
• Will you need to provide cloud-native file shares?
• Will you need to support hybrid cloud storage for on-premises, high-performance computing workloads?
• Will you need to perform large-scale archiving and syncing of your on-premises data to the cloud?
• Do you want to expand an existing on-premises file share to use cloud storage?

Data

When establishing your landing zone, another key component you will want to consider is data.  How you configure your landing zone to support your data requirements will depend on your governance standards as well as technical and business requirements.

Some key questions you should be asking yourself around data when establishing your landing zone are:

• Do you need full control or ownership of your database software or host OS?
• Will your workloads use a relational database technology?
• Will your workloads use an SQL Server?
• Will your workloads use key/value database storage?
• Will your workloads use document or graph data?
• Will your workloads use column-family data?
• Will your workloads require high-capacity data analytics capabilities?
• Will your workloads require search engine capabilities?
• Will your workloads use time series data?

Regional Availability

One major consideration concerning your data will be based upon the Azure region you select, as you will want to be able to deliver services while leveraging data for your customers and partners no matter where they are located.

In general, nearly all database services are available in most Azure regions.  However, you will want to evaluate the region you are deploying to as well as those you will back up in assurance that all services are supported.

Data Residency & Compliance

Often, there are legal and contractual requirements related to data storage that will apply to the workloads you are moving.  These sorts of requirements tend to vary based on the location of your organization, but you will typically consider data location, data classification, and data protection/security when planning your move to the cloud.

Establish Controls for Database Services

You will want to establish both governance and controls to allow better management of database services in the cloud, just as you have in your infrastructure.  In preparing your landing zone, you can establish controls that limit what data stores users can deploy.

These sorts of controls can help you manage costs and limit security risks while still enabling your development team to maintain access to the correct resources that support your workloads.

Hybrid Model

Many strategy driven organizations choose a hybrid model to start, where they will move their infrastructure first and keep their databases on-premises.

This approach tends to be adopted by those that are starting with the lift and shift approach, and often have strict guidelines around data residency and compliance that need to be addressed prior to a move to the cloud.  More often than not, it is easier to move infrastructure first and then evaluate data secondly. There are also benefits to moving your data in parallel with infrastructure. These benefits include reduced latency, reduction in on-prem database maintenance, and the ability to move faster into adopting cloud services (Paas) for your business.

More often than not, it is easier to move infrastructure first and then evaluate data secondly.

Authentication

As you’ve done in terms of infrastructure, you will also want a way to authenticate your database services. Typically, there are two types of authentication for SQL databases:

• SQL Authentication
• Azure Active Directory Authentication

Regardless of which route you take, you will ultimately want to create central management identities for your database services. This will allow you to achieve:

• Management around group accounts and controls for user permissions
• A simplified and flexible permission management for your databases
• Management of applications and database services at scale

Access Management

Establishing best practices around authorizing/managing user access and privileges to Azure SQL databases or SQL managed instances in Azure is another security consideration for your data. These practices ordinarily include the following:

• If possible, start with the least possible amount of permissions before adding permissions on a continuing basis.
• Refrain from assigning permissions to individual users – instead use Role Based Access controls (RBAC rules).
• Create and leverage custom roles.  Typical roles include:
  • Security Deployment
  • Administrator
  • Developer
  • Support personnel
  • Auditor
  • Automated Processes
  • End User
• Use built-in roles only when permissions are an exact match. You can always assign users to multiple roles if needed.
•  It is best practice to use schemas for granting permission inside a database. Permissions in the database engine can be applied within the following scopes:
  • Server
  • Database
  • Schema

Separation of Duties

Another critical security component in protecting against data breaches is your ability to split sensitive tasks between multiple tasks that are assigned to different users.

Best practices include:

• Using different accounts between Dev/Test and productions environments
• Staying away from assigning permissions to individual users
• Using built-in roles
• Creating and implement user-defined roles when built-in roles grant too many permissions or insufficient permissions
• Ensuring DBA’s don’t have access to the encryption keys or key stores and that security administrators with access to keys have no access to the databases
• Always keeping an audit trail

For more information on Tallan’s Digital Accelerator, please connect with Ryan Clark or click here to learn more about our cloud consulting services.

---

Ryan Clark, Sr. Business Development Manager, Microsoft Technologies

Connect via LinkedIn