Anthos and what it means for app modernization

Google recently announced Anthos, their multi-cloud and on-prem platform offering. Anthos had its beginning on Google Cloud Platform (GCP) with as a managed Kubernetes service (Google Kubernetes Engine / GKE). As Google began expanding on their hybrid cloud strategy, GKE made its way on-prem and was rolled into Google’s Cloud Services Platform offering for hybrid cloud which eventually expanded and rebranded to Anthos. Anthos is Google’s attempt at reaching customers that have a need to be fully on-prem or haven’t taken the migration/modernization plunge out of concern of being locked into any single cloud provider. As part of the launch, Google also announced Anthos Migrate, a tool aimed at helping companies modernize their workloads in addition to migrating them. Cloud adoption is usually seen in two phases — migration followed by modernization. Cloud providers have been investing in tooling to assist customers with migration for a while now. As an example, a customer committed to migrating their business to the cloud could make use of such a migration tool (i.e. AWS SMS) to take a VM running on-prem and migrate it to run on a cloud provider (i.e. EC2). However, running on the cloud might not always be better. In the same VM migration example, let’s assume the VM was heavily over-provisioned while on-prem. Since the customer owns the host running the VM, while the host will be underutilized, the compute cost of running the VM will be fixed. When migrating the VM to a cloud provider, an administrator will likely migrate the VM to a cloud instance with similarly over-provisioned specifications. However, because the workload is over-provisioned, the customer will end up with an expensive monthly recurring bill for an underutilized instance. As such, a common activity is to rightsize and optimize workloads to be cloud-native (e.g. leverage resources efficiently for VMs in the cloud). Without this, a common problem with lift and shift migrations is the resulting low “density” deployments/utilization of computing. Part of the above problem results from VMs being very bloated runtimes for applications — in addition to the running the application, VMs also run a guest OS. Containers, on the other hand, are concise runtimes for the workloads at hand. In conjunction with a container orchestrator, containers can be optimally packed to maximize utilization of the underlying compute, resulting in “dense” deployments. Enter Anthos Migrate. Anthos Migrate assists customers in containerizing the application-only portions of their VMs. At a high level, Anthos Migrate achieves this by analyzing a VM’s disk and separating OS/system files from application and user files and containerizing the latter. In doing so, Anthos Migrate will ideally allow customers to containerize compatible workloads and realize denser deployments. It is worth noting that while Anthos Migrate will allow customers to realize denser deployments, not all VM workloads are ideal for modernization. For example, if the VM has kernel level modifications Anthos Migrate won’t work. Another aspect to note is that a complex monolith that is migrated to a container will still be a complex monolith. While a containerized complex monolith might be more cost effective for the customer, it might not realize the benefits of an application stack built from the ground up to be cloud-native (i.e. horizontally scalable, highly available, etc). Anthos Migrate will allow customers to get their foot in the door on their path to modernization and allow them to realize better compute costs for compatible workloads. However, as it is now, it is not a panacea for complete modernization as customers will still have to invest time and energy to properly modernize their workloads to be fully cloud-native. The thoughts and opinions expressed above my own and don’t necessarily represent Amazon’s position.