Virtual data center: offloading your own data center to Azure virtual machines

What a virtual data center is

The speakers point out that quotes for expanding an on-premises data center stay valid only briefly, and that prices have risen sharply in some places. Timing can be a problem too: whether an expansion can be done this year depends on the size of the order.

A virtual data center is a standardized landing zone in Azure where virtual machines are created automatically on shared subscriptions. The machines share subscription resources in one place instead of being scattered, which is meant to lower costs. The team gets simple guidelines on how to add another machine or move one from the on-premises data center, so it does not choose a service and a resource group for each machine.

The platform mirrors the requirements you apply on premises, including those from your security policies. It has several layers:

• a set of subscriptions in the form of a landing zone,
• a network that matches your on-premises segmentation, that is, the split into VLANs and zones,
• governance: security policies, tags, budgets and alerts,
• infrastructure as code (scripts or Terraform, depending on preference) and machine templates that install the same agents as on premises, e.g. for scanning, DLP or monitoring,
• identity: the access model,
• backup: native Azure Backup, Veeam (Protopia’s preference) or another vendor’s tool you already use, if it supports Azure.

The platform can also connect to a ticketing system. Teams then order machines themselves through forms (self-service).

Which systems to move to the cloud

You move less critical systems to the virtual data center: applications of lower business importance, back-office applications and nonproduction environments, meaning development and test. In this scenario the cloud is an extra source of compute that frees up resources in the on-premises data center.

The selection criterion is business risk. Łukasz Kałużny: “We don’t migrate everything, only what may be getting in our way, or what could free up local resources safely for the business, without much risk.” (translated) 16:18

How to match a pricing mechanism to a machine

You pay for the disk separately, even when the machine is off. The amounts in this section cover compute and do not include the disk.

A machine that is on only during working hours runs about 210 hours a month instead of an average of 730. Łukasz Kałużny: “We have a very mistaken belief that it has to run 24 hours a day.” (translated) 06:14

An example from the price list: compute for a popular machine with an Intel or AMD processor costs about 160–170 USD a month. With automatic shutdown, its cost drops to 46–51 USD.

How to keep costs in check after launch

Two layers keep costs in check, and both are built into the platform from day one. The first is the standard FinOps tooling in Azure: budgets and Azure Advisor. The second is a set of alerts and scripts that Protopia adds to the platform. The scripts regularly look for unused and oversized resources.

The speakers often come across machines sized for headroom, with unused CPU. In the milder response, an alert goes to the machine’s owner, who downsizes it. In the more aggressive one, if the organization agrees to it, the platform regularly checks usage metrics, e.g. every week. It then resizes machines automatically or after prior notice, according to the agreed policy.

An example policy: a machine gets 2 cores instead of 4, and the RAM stays the same. For one machine that runs around the clock, the cost drops from 177 to 117 USD.

How to move existing machines

You deploy new systems with scripts and templates as soon as the platform is built. Existing machines move in one of two ways:

• Azure Migrate assesses machines from VMware, Hyper-V and other platforms, then converts and moves them. The migration requires downtime because the machine has to be transferred.
• A backup tool that integrates with Azure, e.g. Veeam, restores the machine from an existing backup directly in the virtual data center. The tool must support this scenario, and you must have a license for it. This kind of migration is faster or, depending on the approach, runs without downtime.

How the rollout works and how long it takes

Protopia estimates 4–8 weeks to build a working platform.

The platform build has three stages:

1. Discovery in workshops: whether the company already has Azure, what the network concept looks like, what the requirements are and which approach to choose.
2. Design: adapting Protopia’s standardized infrastructure as code to the company’s needs.
3. Setup and configuration, the main phase: the subscription, the network, tests of the scripts and machine templates, and the rollout of the governance, identity and backup layers described above.

After these stages, you deploy new virtual machines on the platform. Migrations are a separate stage.

1. Pilot migrations of the first machines.
2. After successful pilots, migration of less critical systems at a larger scale.