Google has released the latest version of its managed application platform Anthos. Anthos 1.7 focuses on anchoring customers’ cloud journeys, creating a consistent operator experience, and establishing a familiar deployment target for developers.  

The company believes that cloud journeys should be anchored to a single cloud because rather than bringing their current state to a desired location, operators can bring the characteristics of the desired state to their current location. “And instead of re-creating foundational behaviors in each cloud, you anchor on a single cloud, and use those practices everywhere else,” Jeff Reed, VP of product management at Google Cloud, wrote in a post

In Anthos 1.7, operators will be able to send logs and metrics from Anthos to Cloud Logging and Cloud Monitoring so they can use a single logging system for all of their environments. Other key features that will help anchor the cloud journey include the new Connect gateway that allows operators to interact with any cluster, and a preview of its managed control place for Anthos Service Mesh. 

In order to create a consister operator experience, Anthos 1.7 introduces Windows container support, support for Google’s container-optimized OS, a CSI driver for vSphere, and an expansion to the number of clusters Anthos Config Management (ACM) supports.  

In addition, it added features to help establish a secure and familiar deployment target for developers. These include making it easier to build YAML files, the ability to create Cloud Build definitions that deploy to any Anthos-connected cluster, and the ability to run Workload Identity on-premises and in AWS. 

“With multicloud, developers can use the best services from each cloud and run each workload in the right place. The hard part? Creating some level of repeatability across all these environments. How a developer deploys to a hypervisor or container environment on-prem is very different from how they deploy to an app-centric platform in the cloud. There are different requirements for how to package up the software, different deployment tools, and different handoffs or automated integrations to expose the application for use. Can we normalize it a bit? Indeed we can, by creating a consistent dev experience for the inner loop, and a standard deployment API for every environment,” Reed wrote.