Virtual Machine Service
Some application teams may lack the knowledge to operate their workloads in the cloud but may be comfortable with working in a data-center-like environment. Providing these teams with virtual machines as a service offers a stepping stone for bringing lift & shift workloads onto the cloud (see Lift & Shift Landing Zone).
These virtual machines are typically not fully managed, they just provide VMs preconfigured with best practices and can be interacted with via the usual cloud tooling. For example, a team may be able to start/stop/snapshot its VM from the cloud console or via cli. This approach reduces implementation effort for the cloud foundation team (or the team responsible for providing the VM service) and exposes lift & shift teams to a reasonable degree of cloud-native tooling and operation practices.
Proven Patterns When Implementing Virtual Machine Services
Provide Virtual Machine Services in Tailored Landing Zones
Setting up dedicated lift & shift tenants (Lift & Shift Landing Zone) with some opinionated best practices makes the switch to a cloud-native environment even smoother. For example by setting up a simple virtual network structure out of the box or restricting access to undesired cloud platform services.
Set Clear Expectations about Service Levels
Virtual machines on the cloud come with a different set of SLAs and expectations compared to on-premise environments. Hypervisor hosts can fail or degrade more often and VMs may need to be reinstantiated by the customer. This is one of the primary reason we prefer handing over a larger portion of operation responsibilities to application teams compared to an on-premise environment where the typical shared responsibility alignment is “IT operations will make sure the VM is always running”.
🌤️ If this service-level is impractical to work with for the majority of your application teams, consider alternative solutions like “VMware on X” instead or re-evaluate the cloud-readiness of these workloads.
Align Responsibilities for Operating System Maintenance
It’s important that application teams understand their responsibilities once a virtual machine is running. Will they have to patch the operating system or is the OS automatically enrolled in a patch management? Commonly unattended upgrades are automatically configured as part of the base image (see Shared VM Image Repository) and additional agents that ensure SOC Integration come already baked in.
In either case, it’s important the cloud foundation team decides about this early and provides clear guidance to all stakeholders (see Shared Responsibility Model Alignment).
Leverage Existing Services
By ensuring compatibility with existing services lift & shift projects get to benefit directly from their new cloud environment by simplifying operations.
Shared VM Image Repository for a catalog of pre-approved and maintained base images
On-Premise Network Connection for providing or interacting with internal services and applications.
Tenant to Tenant Transit Networks can be used for linking up with other tenants to iteratively transition lift & shift projects to cloud-native tenants.
Every Cloud Foundation customer can offer services on the meshStack marketplace to other teams in your enterprise.Learn More