Anthos is a fully managed hybrid cloud platform that enables you to run Kubernetes clusters in the cloud and on-premises environments. As an open cloud computing platform that works well with multi-cloud environments, it works across public clouds such as Microsoft Azure and AWS. In other words, as you work to containerize and modernize your existing application environment, Anthos allows you to do this on-prem or across any cloud provider. It does not force you to have to use the Google Cloud Platform to modernize.

History of Anthos

Because Anthos is a pretty broad product suit, Anthos means different things to different people. Before we get any deeper into Anthos, let’s take a journey on how Google got to Anthos. Over the last 10 years, there have been a number of fundamental technological shifts. These shifts have made it different in how we build our applications, and the way they are run in the cloud. Some of the new fundamental technologies that have helped shape Anthos include:

• Cgroups: 2006, developed by Google as an early containerized implementation for Google’s internal software
• Docker: 2013, built a lot of tooling around containers based on things learned from Cgroups. It’s used for deploying containerized software to one machine. As developers were making more and more containers as monolithic software was being reorganized into microservices, it became hard to orchestrate all these containers.
• Kubernetes: 2014, Leveraging what Google had learned running Containers in Docker at scale, this was released. Kubernetes is used for deploying containerized software to multiple machines and is now the standard way for running containers at scale.
• Istio: to help manage services in production the same way Google does. Allows you to deploy things like Site Reliability Engineering Practices.

Many of you are saying cloud is here to stay and an even larger portion believe multi-cloud (multiple cloud vendors being used) and Hybrid (on-prem and in cloud) is key and have multi-cloud plans, yet most company’s applications remain on-prem, with a small fraction of workloads having been moved to the cloud. Many of you have also made big investments into your on-prem infrastructure and datacenters and, if moving to the cloud, want to still leverage your on-prem investments as you move incrementally to the cloud. Additionally, for those of you that did move your applications to the cloud, not all were successful, and some of you had to roll-back to your on-prem environments.

As you tend to try and modernize your applications, and pull apart your monolithic services and try to make microservices out of them, you are moving to the cloud at the same time and things can get complicated. This is full of risk as you are reengineering your application, familiarizing yourself with new tools and processes, and trying to discover new cloud workflows at the same time.

Introduce, Anthos

Anthos was developed in 2019 to try and meet you where you currently stand, to help you try and modernize where you are, in-place within the on-prem setup, in the datacenter, before you move to the cloud. That way, by the time you want to move to the cloud, things are already set; you’ve done the organizational work on-prem. Therefore, Anthos was developed to work in the cloud as well as in the datacenter.

At a high level, Anthos is an application deployment and management tool for on-premise and multi-cloud setups. It accomplishes this while remaining entirely a software solution, with no hardware lock-in. From your standpoint, your infrastructure is abstracted away so you can focus on building your applications, not managing your infrastructure. As Anthos is built on open technologies, you can typically avoid vendor lock-in as well.

Anthos Tools

Anthos has different types of tools for different types of people within your organization. There are both open-source and hosted versions of many tool types as outlined in the table.

When you work on-premises, the hosted versions of the software are brought to you via VMware vSphere.

Anthos Components

Let’s look at all the Anthos components:

When you first look at diagrams like this, you may be overwhelmed by the complexity of Anthos, but the more we delve into these components, the more familiar you will become. We will break this diagram down piece by piece to understand every component.

Kubernetes

Let’s spend a moment looking back at Kubernetes. Kubernetes are:

• Container packaged (portable and predictable deployment with resource isolation)
• Dynamically scheduled (Higher efficiency with lower operational costs)
• Microservices oriented (Loosely coupled services that support independent upgrades)

Kubernetes uses the kubectl command to administer your cluster. Kubectl communicates with the master via a set of APIs and tells it to deploy the required containers, scaling type, etc.

Kubernetes Engine (GKE)

Kubernetes Engine was then developed as a managed Kubernetes platform that will run on GCP. It also includes:

• Managed Kubernetes
• Fast cluster creation
• Automatic upgrade and repairing of nodes
• Curated versions of Kubernetes and node OS

This made it much easier to run your Kubernetes clusters on GCP. With Kubernetes, it could take hours to spin up your infrastructure and get it to a Kubernetes-ready state. With GKE, there is an easy interface on the cloud console and after a few clicks, you will have a running Kubernetes cluster.

With GKE, you can still use kubectl to communicate with the master, but you are also given the cloud console to interface with the master from the cloud. This uses the same set of APIs to communicate with the Master as Kubernetes.

GKE On-Prem

Anthos introduces GKE On-prem and runs as an automatic deployment on top of vSphere within your environment. This allows you to not just run Kubernetes on your infrastructure, but GKE entirely, giving you all the GKE benefits on-prem. It offers:

• Benefits of GKE, plus
• Automated deployment on vSphere
• Easy upgrade to latest Kubernetes release
• Integration with cloud hosted container ecosystem

When using GKE On-Prem, there is now introduced an Admin Workstation and you can also use kubectl to talk to this new type of cluster called an Admin Cluster. The Admin Cluster is responsible for creating your clusters for you, in your environment. You can also continue to use kubectl to interface directly with your cluster as you had with Kubernetes and GKE.

GKE Hub (within the GKE Dashboard)

Even easier than continuing to use kubectl, you can also manage your on-prem GKE and other Kubernetes environments from the cloud console via the GKE Hub. GKE On-Prem clusters are automatically registered upon creation and the Hub gives you centralized management of hybrid and multi-cloud infrastructure and workloads. You are given a single view for all clusters in all of your estate.

Now, if you refer back to the Anthos Components diagram above, using what we know so far from Google Kubernetes Engine (GKE) and GKE On-Prem and GKE Dashboard, we can start to build out the diagram from the ground up. The Cloud Interconnect is just added to allow the two to communicate.

Service Mesh

Let’s continue to add to our diagram by discussion the Service Mesh. The Service Mesh provides a transparent and language-independent way to flexibly and easily automate application network functions. Another way to look a Service Mesh is to think of it as a network that is designed for services, not bits of data. It’s a layer-3 network that does not know what applications it belongs to and does not make network decisions based on your application settings.

The Istio Service mesh is an open framework for connecting, securing, managing and monitoring services and manages interactions between services. The mesh deploys a proxy next to each Service, and this allows you to make smart decisions about routing traffic, and enforcing security and encryption policies. This gives you:

• Uniform observability
• Operational agility
• Policy-drive security

First, let’s look at a typical service architecture with our Service Mesh:

The problem with this configuration, is there is no way to enforce security policies between services. For example, even though it is not designed to do so, we do not want the Pictures service to be able to talk to the Auth service.

When deploying the Istio Service Mesh, we create a proxy that acts like the original Service Image, but instead is an Istio-enabled service where the communication to the image must go through the Istio proxy first:

With this deployment, no change in code was required as Kubernetes has deployed the service and simply provides smart decisions on how we route traffic.

The end result after Istio Service Mesh is enabled to the service architecture looks like this. You see they must all communicate through the proxy now:

You can also use Istio for Traffic Control, Observability, Security, Fault-Injection and Hybrid Cloud.

Just as Kubernetes has been turned in a managed service in the cloud with GKE, Istio has also has also been released as Istio on GKE (Beta). Istio and Kubernetes are independently released so they have independent versions. By using Istio on GKE, you are giving Google the trust to certify version compatibility between Istio and GKE. So when there is a new version of Kubernetes, there will be a matching version that Google will release of Istio that has been tested and certified to work. With Istio on GKE there are some additional adapters that were created to be able to plugin to other GCP products. Some of these Istio on GKE adapters are:

• Apogee Adapter
• Stackdriver (the destination Istio sends from telemetry data from the Istio Mixer component) – this gives you observability into Istio.

To continue our diagram, we now can include the Service Mesh components:

Anthos Config Management

Anthos Config Management was designed to make it easy to apply your policies between this heterogeneous of Multi-Cloud and On-Prem. Config Management lets you enforce guardrails for central IT governance. You can manage configuration of the tools in all of your clusters in one place. You don’t need a separate repository for on-prem and a separate one for any of your cloud providers. It becomes a single, auditable source of truth. It allows you to:

• Sync configs across clusters on-prem and in the cloud
• Continuous enforcement of policies
• Security and auditability through policy-as-code.

As Config Manager acts as the Policy-as-Code you can have:

• Git repository as source of truth where your policy gets checked into
• YAML applied to every cluster
• Integration with your SCM
• Pre-commit validation

Now, updating our diagram, we can now include Anthos Config Management:

Knative

Knative is the efforts by google to bring serverless workloads into Kubernetes. Knative is the open-source serverless framework that builds, compiles, and packages code for serverless deployment, and then deploys the package to the cloud. For some context, serverless computing itself is a cloud computing model in which Google allocates machine resources on demand, taking care of the servers on behalf of you. Serverless computing does not hold resources in volatile memory; computing is rather done in short bursts with the results persisted to storage. When an app is not in use, there are no computing resources allocated to the app.

Knative provides:

• Building-blocks for serverless workloads on Kubernetes
• Backed by Google, Pivotal, IBM, RedHat and SAP

Cloud Run

Remember that Knative is the open-source implementation of the serverless framework. Google has then taken Knative and provided a managed version of it called Cloud Run. Cloud Run is a fully managed serverless product, compatible with Knative. It provides:

• Stateless containers via HTTP(s) requests
• Built-in domain handling
• Scales to zero – or as high as you need

Cloud Run is fantastic for application developers because if you have any stateless component in your application, you can package it up as a container and give the container image to Cloud Run. Cloud run is going to deploy it for you and give you a secure URL that you can map to your domain and it will even scale it for you. You don’t need to think about any of the rest. You just focus on your code. The contract with the Cloud Run container is simple:

1. It is Stateless
2. The port that you need to run it on is given to you as an environmental variable

Cloud Run can make the application modernization journey much easier, because at the end of the day this is just a container. Meaning you can write it in any language you want, use whatever tools you desire, use any dependencies you desire, put them into a container, and Cloud Run handles the rest. So, in terms of bringing in legacy applications that are not working on the latest versions of Java, Python, COBOL or whatever, Cloud Run supports all of it. At the end, Cloud Run is just a binary. It’ll allow you to bring your applications into the cloud journey but still work within your comfort zone using the skillset that you are most comfortable with.

Further, Cloud Run for Anthos integrates into the Anthos ecosystem. We did mention that with Cloud Run, if you give it the container image it will be automatically scaled. You may want more control than that and scaling to not be fully automated. Cloud Run for Anthos allows you to deploy your containers on your clusters, giving you freedom to run Cloud Run anywhere, such as your on-prem environment. Let’s again review the iterations we’ve discussed:

• Cloud Run – Fully managed and allows you to run the instance without concern for your cluster
• Cloud Run for Anthos – Deploy into your GKE cluster, running serverless side-by-side with your existing workloads.
• Knative – Using the same APIs and tooling, you can run this anywhere you run Kubernetes, allowing you to stay vendor neutral.

Stackdriver

Discussed earlier when we were reviewing Istio adaptors, Stackdriver is a tool for visibility. When you enable Istio and GKE, the logs and telemetry from your Kubernetes cluster are sent to Stackdriver. This one tool gives you logs across your entire estate. It provides:

• Logging
• Monitoring
• Application Performance Management
• Application Debugging (Link Stackdriver to source code)
• Incident Management

Marketplace

There are times when you don’t need to build everything yourself. You may have a specific job to do, and something like a standard Redis database would be perfect. The GCP Marketplace is a collaboration with Google and third-party vendors to certify software to be run on GCP. One of the places you can run that software is your Kubernetes cluster. And with Anthos, those clusters could be on-prem or in the cloud.

https://console.cloud.google.com/marketplace

Now, finally, we can complete our diagram as we saw it from the beginning, with all of our components for Anthos:

We’ve added Marketplace and Stackdriver in the middle. So now we should be able to understand all of this. We have

• Google Kubernetes Engine and GKE On-Prem for container orchestration
• Istio for security policies, traffic routing across the services in our estate
• Anthos Config Management to make sure we can have a centralized place for governance and application policies and settings, keeping them consistent between on-prem and GCP.
• Marketplace and Stackdriver to help us have a much better application experience

Migrate for Anthos

Up until now, everything we have talked about in Anthos has been centralized around the applications running as containers. Many of you still deploy your applications with Virtual Machines and if you have been looking to migrate to containers, the path is not necessarily straight forward. Migrate for Anthos literally takes your Virtual Machines and converts them into containers. This makes your container image much smaller than the virtual machine image as you no longer have the bulk of the operating system. Migrate also releases the operating system security burden for you, as once the virtual machine is containerized, the OS security is now handled on Google’s hosted infrastructure. The unique automated approach extracts the critical application elements from the Virtual Machine so those elements can be inserted into containers in Google Kubernetes Engine or Anthos clusters without the VM layers (like Guest OS) that become unnecessary with containers.

Use discovery tool to determine which applications might be a good fit for migration, as not all applications can migrate this method.

Let’s look at the technology landscapes that are helping enterprises scale, adopt and modernize while they migrate to Google Cloud. We’ll review strategies and the tools to help you get there.

Cloud Migration Approach

Migrations are often considered for an extended period of time by enterprises as they fair considerations about moving their workloads over to a cloud environment. There is also the a difference in approach between small companies and large companies as they have different needs and migration paths. Let’s look at dissecting this process.

Why Move to the Cloud?

The first question to as during the cloud migration process is, why? Why are we going down this path? What is the business or technical goal you are looking to accomplish? Here are some common reasons why you might be moving to the cloud. You may want to:

• Develop faster
• Decommission workloads
• Consolidate systems
• Move VMs to cloud
• Modernize by transforming into containers
• Utilize the efficiencies and scaling the cloud offers.

These answers will vary greatly based on the size of your business and your business goals. Once the answer has been framed, you can begin to provide a clearer path on how to get from where your company is today to where you want to be.

What Are You Moving to The Cloud?

The next question to ask yourself is what? What do you have right now? For example, you will want to provide a:

• A catalog of all the applications you have
• The workloads that you are thinking about moving
• Network and Security Requirements

This will help further build your migration strategy moving forward. Many businesses think they will need to build a very complicated system diagram, showing all the connections taking place or perhaps schematics showing the way all of our applications will work in the cloud. However, for many large organizations that have grown organically, this will not be feasible. As the what phase starts, sometimes all that is needed is to sit down with a napkin or sheet of paper and write a general overview of what apps, workloads, etc. you are looking to move. Later, when you need to expand this list, you will work with the various groups and lines of business that you have to find other resources and applications that you are concerned about.

What Dependencies Do You Have?

As we expand this further, we need to get more specific about our dependencies and start making lists of such things as:

• Dependencies on application stacks
• Database and message brokers
• Underlying infrastructure
• Firewall and security rules
• Source code repositories

Often times, the “gotchas” happen as your business has grown organically and we see business unites popping out of the woodwork as the migration is moving along saying things like, “I’m actually keeping my source code over here and not in the official repository.” Overall, the more comprehensive your evaluation is ahead of time, the less headaches you will have during the migration.

Does Moving Everything to the Cloud Always Make Sense?

Sometimes there are cases where moving something to the cloud is not practical or might not be technically feasible in the near term. For example, maybe you have licenses that you can’t move to the cloud, your technology stack may not be virtualizable, you have 3^rd party frameworks being used, or you have mainframes that need to stay independent. In these cases, it is OK to say NO! Rather, you want to focus what can be moved to the cloud. The last thing you want to do is force something into the cloud that doesn’t belong. Finally, you may also find that there is an interim path for one of your services that might not directly place it in the cloud, but aligns with your strategy. For example, if you are shutting down a datacenter that has a design too complicated to migrate to the cloud, you could move it to a co-location facility. This would allow you to gain some of the benefits, such as being closer to a cloud entry point, or getting that high-throughput or low-latency that you were looking for.

Choosing a Migration Path

There are a lot of ways to approach a cloud migration, such as an all-in-one lift in switch, a hybrid approach or private and public cloud. The answer to this will depend on what you are looking to accomplish and where you are coming from. If you are coming from legacy applications and hardware, you will likely have a much different migration path than if you are already cloud-native and just looking to scale. There could also be a scenario where you have an aggressive deadline to shutdown a datacenter, and do not have time to modernize. In this case, you would likely want to lift-and-shift your datacenter to the cloud and worry about modernizing or containerization strategies later on once the dust has settled.

Application Containerization Strategy

As a developer, containers can provide you a lot of freedom to package an app with all of its dependencies into an easy to move package.

One of the major moves during a cloud migration is deciding to containerize your applications rather than brining them back up into their own virtual machines. How do we know if an application is a good candidate for containerization? For example, you might have apps such as Dev Test Applications, Multi-Tier Stacks, LAMP applications, or a Java or web applications running on-premises. How do we know if these are good to containerize? There are a few questions we should ask.

1. Is the app pre-packaged as a stand-alone binary or JAR file?
   1. Stand-alone binaries, such as EXE or JAR files are easy to containerize. Java and JAR files are especially flexible because the JRE can stay within the container.
2. Is the platform on which your app is built available in a containerized version or package yet?
3. Are any of your 3rd party apps available in a container version yet?
4. Is the app stateless?
5. Is your application already part of continuous integration/continuous deployment pipeline?

This may still leave us to question monolithic applications (think a monolithic SAP application), as many enterprises still use these. How might we convert these to a microservice environment that is more compatible with a containerization strategy? It may be possible to slowly break down the monolithic application into its subsequent services for a microservice strategy. It is also possible to containerize the entire application into one application container. This would allow for some of the containerization benefits such as fault tolerance and portability that containerization provides, without breaking down the monolithic application all at once.

Next, we want to look at what options are available to containerize your apps. In GCP, there are three main options, Google Kubernetes Engine (GKE), Cloud Run, and Compute Engine (GCE). Although the concepts underlying containers have been around for many years, Docker, Kubernetes and a collection of products and best practices have emerged in the last few years. This has enabled many different types of applications to be containerized. The solutions for running containers in Google Cloud Platform vary in how much of the underlying infrastructure needs to be exposed.

Google Kubernetes Engine (GKE)

As the inventor of Kubernetes, Google offers a fully managed Kubernetes service, taking care of scheduling and scaling your containers, while monitoring health and state. Getting your code to production on GKE can be as simply as creating a container deployment with the cluster being provisioned on the fly. Once running, these GKE clusters are secure by default, highly available, and run on GCP’s high-speed network. They can also be targeted for zonal and regional locations, and use specific machine types with the option of adding GPUs or Tensor Processing Units (TPUs). GKE Clusters also can provide you auto-scaling, auto-repair of failing nodes and automatic upgrades to the latest Kubernetes version. GKE is also a key player within Anthos, Google Cloud’s enterprise, hybrid and multi-cloud platform. Using Anthos, you can even migrate existing VMs directly into containers and move workloads freely between on-prem and GCP.

Cloud Run

It is also possible to shift your focus from building stateless apps, not on writing YAML files, and still deliver code packaged in a container. Cloud Run combines the benefits of containers and serverless. With cloud run, there is no cluster or infrastructure to provision or manage and any stateless containers are automatically scaled. Creating a Cloud Run service with your container only requires a few simple fields, such as name and location and choosing your authentication method. Cloud Run supports multiple requests per container and works with any language, library, binary or base Docker image. The result is serverless with pay-for-usage, the ability to scale-to-zero (can be reduced down to zero replicas when idle and brought back up if there is a request to serve), and out-of-the-box monitoring, logging and error reporting. Because Clour Run using Knative (offering serverless abstraction on top of Kubernetes), you can have a dedicated private hosting environment and deploy the same container workload on Cloud Run for Anthos in GCP or on prem.

Compute Engine (GCE)

It is also possible to use the Google virtual machine environment to run your containers. This means using your existing workflow and tools without needing to master cloud-native technologies. When you create the GCE virtual machine, there is a container section which will allow you to specify the image and other options the container will use. It is when you get to the boot disk section of setting up the VM, the suggested virtual machine OS is a Container-Optimized, which optimized for running Docker containers. This comes with Docker Runtime preinstalled.

Google Container Registry (GCR)

Where do these container images come from, where do you store them, how are they versioned, and how is access restricted to them? Google Container Registry (GCR), a container registry running on GCP. It is possible to push, pull and manage images in GCR from any system, VM instance or hardware. You then use it to control who can access, view and download those images. It also possible to deploy to GKE, Cloud Run, or GCE right from the registry. GCR works with popular continuous delivery systems, such as Cloud Build, Spinnaker, or Jenkins to automatically build containers on code or tag changes to repository.

System Containers

There are situations where you may want to go all-in on application containers, but due to technical requirements, you may want to explore system containers. System containers are similar to virtual machines, as they share the kernel of the host operating system and provide user space isolation. However, system containers do not use hypervisors. (Any container that runs an OS is a system container.) They also allow you to install different libraries, languages, and databases. Services running in each container use resources that are assigned to just that container.

Migrate VMs to Compute Cloud

After we have an application migration strategy defined, it is time to start thinking about a machine migration path. Migrate for Compute Engine (GCE) which allows one or many workloads to be moved in a unified way to GCE. Migrate also provides cloud testing and validation, including a plug-in that is available to find workloads and move them over. There is also the possibilities for a stateful rollback, so if at any point you feel like you need to get out the migration, there is the capability to roll-back to the on-prem environment. This can give you time to take a pause and see what is going on with a migration. There may also be a use-case where you need to maintain a VMWare-based control plane, there is support for VMWare and vSphere workloads that can be moved to GCP.

Unify On-Prem Applications

Some applications will need to stay on-premise, yet you may still want to take advantage of cloud-native capabilities. Anthos can be used to manage your on-premise and your hybrid-cloud or multi-cloud environments in one place. Anthos uses a tool called GKE On-Premise, which allows you to implement a containerization strategy in your on-premise environments. For example, you might use Cisco HyperFlex and use Anthos to develop a strategy for on-premise and cloud together. This can be used to simplify monitoring, logging, and config management and still get access to all the benefits of being on cloud. It’s as if Cisco HyperFlex was cloud-native but the underlying infrastructure is still on-premise.

Where to Start with Google Cloud Migration?

1. Start by looking at the migration guides found at https://cloud.google.com. These are great at getting started guides that can help you think through what is required to migrate your business.
2. Google also offers professional migrations services, known internally as PSO (Post Sales Department). For example, PSO can help leverage workshops to help out with the migration strategy.