Financing digital transformation poses a significant problem for many enterprises we work with. It’s not because the C-suite doesn’t support it: the need to become more agile, digital, and data-driven is nearly ubiquitous in executive public pronouncements. But most large organizations look at IT investment in a way that’s ineffective for a successful digital transformation effort.  

A varied combination of  factors affect an organization’s success in the digital ecosystem, and a lack of alignment between IT and business leaders can hamper even the most digitally sophisticated organizations. Empirical research by the Apigee Institute shows clear evidence that a solid digital transformation effort, aligned across business and marketing, whose progress is carefully tied to core enterprise metrics, must be supported by an investment strategy that uses a “real options” portfolio approach.

Let’s explore ways to think about funding digital transformation.

Planning for the Unimaginable

Common IT investment strategies are focused on straight-line net present value (NPV) business case calculations, which emphasize linear solutions and impacts. These methods ignore the value of enabling a range of options and potential future use cases, which an API program, with its reusable, highly consumable digital assets, makes available for the enterprise. In addition, these methods often ignore the value of the new categories of business data generated by such programs, as well as business capabilities that were impossible to imagine before the capabilities came online.

One media company we’re working with was astounded by a project that now makes key sales provisioning available to large distribution partners within two months, when previous estimates predicted two years and many millions of dollars, each.

More importantly, that functionality will now be reused across all of their numerous current partners and sales channels, and is enabling exciting new partnerships that were too costly before. This functionality was an unexpected by-product of their original API effort—it wasn’t even the main focus of the initial project.  

There was no way that the impact of this capability or its implications on new business could have been predicted at the outset, and no way to formally model the outsized impact this functionality will have on the enterprise. Any attempts to do so would have been deemed ludicrous.

Breaking from the Status Quo

So how do you fund an API-driven digital transformation, which by nature emphasizes speed and optionality to unlock new ways of doing business, instead of the business-as-usual single-use, point-to-point integrations that perpetuate status quo thinking? For a world where the latter is the dominant paradigm and you don’t have a clear C-level mandate, here are three suggestions.

1.  Enable your web/e-commerce teams. Many such teams find their responsibilities expanded to include mobile, kiosk, and many other digital initiatives, while being trapped in the traditional web server, do-it-yourself paradigm. These teams are actually quite open to technology, and often harbour weekend hackers who love to explore the new capabilities that are expanding the digital ecosystem at light speed. Tapping this passion by funding new approaches and quickly realizing immediate projects can create first the technical, and then the business proof points that resonate with a strategy team. These capabilities must be nurtured to move out of the lab into production, where real results are created.  

2. Focus on partnerships. Opening and accelerating  your relationships with partners via APIs (read more about partner API initiatives here) is high-impact and relatively easy to model. This business area can prove out an API platform, and in our experience creates clear business value that can support future justifications for other business units. What’s best about these wins is that sales operations groups are typically very tactical and demanding, so when they see the value, these groups will send a message to the rest of the organization that APIs have business value. Further, your enterprise’s core partnerships have the focus of executive attention. Adding value here will elevate the stature of the API program in the C-suite.

3. Work on your CFO/financial organization. Using your successes in e-commerce and partnerships, you can propose a more robust investment using a real options approach that leads to treatment of APIs as products. This path is predicated on what research has proven to work: the adoption of a digital KPI target, coupled with a portfolio of programs whose net result is to achieve the target KPI.  

Building Toward the Big Vision

But what about the visions of ground-breaking business models, ubiquitous connectivity, and enablement of an ever-shifting set of opportunities on big platforms and with unlimited partnership possibilities? Yes, these are still the endpoints to work toward, and fundamentally comprise the strategic reasons to embark on a digital transformation. If your enterprise has the C-Level leadership (in the form of a CDO or CDO-like figure), supported by a well-funded, sophisticated investment approach, by all means, build that new world now.

However, should that vision be shared only within your business unit, a forward-thinking IT group, or a dedicated innovation team, the most important thing to do is to build your team’s capability—and your program’s credibility—while delivering value along the way. The approach we suggest here has been proven in many of the organizations we work with; once your organization begins working faster and at lower costs by orders of magnitude, you’ll have created enough leverage to change the way your organization invests in its API program.

Electric vehicles already account for one in seven car sales globally, and with new gas and diesel cars being phased out across the world, global sales are forecast to reach 73 million units in 2040. But with power grids becoming increasingly dependent on variable energy sources such as wind and solar, rising demand from electric vehicles risks overstraining grids at peak times, potentially leading to power outages.

At Kaluza, we believe that our platform has a vital role to play in helping power grids and utility companies to stabilize their networks, while at the same time delivering more affordable, cleaner energy to the consumer. Powered by Google Cloud, the advanced algorithms behind our Kaluza Flex solution automatically charge electric vehicles when the power supply is at its cheapest and greenest, helping to accelerate the global transition towards a zero-carbon future. 

Decarbonizing the grid with low-cost smart charging programs

Launched by OVO Energy in 2019, Kaluza has taken its deep understanding of the energy market to partner with some of the world’s major energy suppliers and vehicle manufacturers, including AGL in Australia, Fiat and Nissan in the UK, and Mitsubishi Corporation and Chubu in Japan, to launch smart charging programs that help customers save money while reducing their carbon footprint.

A good example of this is Charge Anytime, which we recently launched with OVO Energy in the UK. With this tariff, customers use Kaluza to smart-charge their electric vehicle, and pay just 10p per kWh — a third of their household electricity rate — to do so. This means that if the customer plugs in their vehicle to charge when they get home from work at, say, 6:00 p.m. — a time when both demand and the carbon intensity on the grid are at their highest — their vehicle will then be smartly charged at the lowest cost and greenest periods throughout the night, ready for when they need it in the morning. 

This smart charging reduces the energy company’s costs by enabling them to take advantage of lower wholesale electricity prices. These savings are then passed on to the end customer through tariffs such as Charge Anytime, saving customers hundreds of pounds a year and reducing their carbon footprint. Meanwhile, the National Grid is able to reduce the strain on the network during peak hours, while simultaneously using up the excess renewable energy that might otherwise have gone to waste. 

Optimized charging schedules, fueled by Google Cloud

Behind Kaluza’s smart charging solution lies some sophisticated technology, all of which is built on Google Cloud. Our core optimization engine gathers real-time data from a wide range of sources, including battery and charging data from the electric vehicles, and data from the energy suppliers and grid operators, such as the carbon intensity, and price forecasts. 

After passing through our real-time data backbone, that data is stored in BigQuery where it’s used to train and validate our smart charging optimization models. These models are then deployed with Google Kubernetes Engine so that whenever a customer plugs in an electric vehicle, data from that vehicle passes in real-time through our optimization engine to calculate the ideal charging schedule for that vehicle, ensuring it uses the cheapest, least carbon-intensive energy available.

Customer interface: easy to use, simple to build

Of course, the customer isn’t aware of any of this complexity. All they need to do is open their charging app and use Kaluza’s intuitive interface to set what time they want their car to be ready and how much charge they want in their battery. Then they simply plug in their car, and our algorithms take care of the rest. 

Customers can also use Kaluza to view breakdowns of how much carbon and money they’ve saved, along with insights around things like billing and battery life, all of which is backed by Cloud SQL. 

With Google Cloud, we were able to roll out this end-user app very quickly. Instead of having to build a different version of the app for each operating system, we were able to build an OS-agnostic version using Flutter, which then builds the app for each platform, enabling us to get to market faster. 

This has been a benefit of our architecture in general. With Google Cloud taking the complexity out of otherwise time-consuming development processes, we’ve been able to experiment with and validate propositions rapidly, and roll out new products and features at speed, to ensure that we remain at the vanguard of a rapidly evolving sector. 

Giving energy companies full visibility with BigQuery and Looker

As for the grid operators and energy companies, the Kaluza platform allows them to visualize how many participating electric vehicles are plugged into the network at any one time. BigQuery and Looker Studio dashboards provide granular insights, such as how many vehicles are idle, how many are charging, and how well our optimization engine is working. 

The platform also allows companies to view those vehicles on an aggregate level, and identify any issues. Google Cloud machine learning capabilities can even allow grid operators to use this aggregate view to forecast how much energy will be required at any one time, and dial the power generation up or down accordingly. 

Ultimately, these insights help network operators and utility companies to optimize energy usage, and balance out the peaks and troughs of supply and demand, ensuring that excess renewable energy is captured, while carbon-intensive fuel use is reduced. 

Feeding energy back into the grid with bidirectional charging

Vehicle-to-Grid (V2G), or bidirectional, charging is something that we are very excited about, and have begun rolling out in the UK, as we prepare to launch in other global markets. Built on the same Google Cloud architecture as the rest of Kaluza Flex, V2G not only enables smart charging, but allows electric vehicles to feed stored energy back into the grid. 

Imagine an electric vehicle battery that can store 40 kWh of energy, but only uses 5 kWh a day. That leaves 35 kWh a day that can be charged to the battery during times of low demand, when energy is cheapest and greenest, then fed back into the network during peak periods, removing the need for more fossil fuels to be burned to meet demand. 

Not only does V2G go further than conventional smart charging to make use of renewable energy when it’s abundant and support the balancing of the energy system, it also results in even lower energy prices for the customer, as they are effectively selling energy back to the grid. For example, as part of a large domestic V2G trial made in partnership with OVO and Nissan, Kaluza saved customers an average of £450 a year, with some customers saving up to £800/year by selling surplus energy back to the grid — transforming their homes into mini power stations.

With Kaluza Flex, we have a platform that offers benefits for all parties, from the grid operators, through to energy retailers and vehicle manufacturers, and all the way to the customer. Now, our aim is to bring this exciting offering to as many markets as possible, a goal which is made easier thanks to the scalable infrastructure and time-saving solutions of Google Cloud. 

As more people make the switch to electric vehicles, our goal is to ensure that smart charging becomes standard practice, as we help to deliver on the potential of electric vehicles to contribute to a greener, decarbonized future.

To help improve your security posture, improve the reliability of your applications, and reduce configuration drift in your environment, we’re excited to announce a new Anthos reference architecture.

Written in collaboration across our product, engineering, support, and field teams, this new reference architecture helps you plan, deploy, and configure the required components for Anthos hybrid environments.

Anthos hybrid environments give you the flexibility to deploy on-premises components that run container-based workloads and VMs using Anthos clusters on VMware and Anthos clusters on bare metal. You can continue to utilize existing investments in your on-premises infrastructure, and start to add components like Anthos Config Management. When you’re ready to bring everything together, you can add additional Google Cloud-based services like Artifact Registry, Cloud Monitoring, and Identity and Access Management (IAM).

The following sneak peek covers some of our best practices for architecting an Anthos hybrid environment. For more detailed guidance and planning information, see the full Anthos hybrid environment reference architecture.

When you design and deploy an Anthos hybrid environment, we recommend that you use two or more on-premises computing customer sites and two or more Google Cloud regions. In your sites, run multiple clusters. This approach is recommended for several reasons, such as:

• Disaster recovery. If one cluster or site fails, you can continue to run workloads.
• Multiple environments, like production and staging, to test infrastructure changes.
• Different cluster types in each environment: admin clusters and user clusters. This approach separates administrative resources, which is a security best-practice.

The following diagram shows an example of an Anthos hybrid environment that’s spread across customer sites and regions, with different clusters for admin and user workloads and for production and staging:

In each site, you can use Anthos clusters on VMware or Anthos clusters on bare metal. For both products, we recommend the following:

• Use a highly available (HA) control plane with three members for continued control plane availability concurrently with operating system upgrades, control plane software updates, or single-machine hardware or kernel failures.
• Deploy two admin clusters so that admin cluster configuration changes and updates can be tested in the staging environment first.

The following diagram shows an example of Anthos clusters on bare metal with control plane and worker nodes spread across physical machines. With Anthos clusters on VMware, the control plane and worker nodes are spread across VMware VMs:

Configure your on-premises clusters and applications to send logging and monitoring data back to Google Cloud for analysis and review. Different personas should only be granted access to the environments they need. The following diagram shows how application developers and application or platform operators can then view logging and monitoring data in Google Cloud:

Use Anthos Config Management to manage Kubernetes objects in your clusters. Anthos Config Management is a GitOps-style tool that uses a Git repository or Open Container Initiative (OCI) as its storage mechanism and source of truth. Git provider workflows allow multiple stakeholders to participate in review of changes.

As shown in the following diagram, a common Anthos Config Management deployment uses one folder containing configuration for all clusters. Use separate additional folders to hold configuration data, one for application:

Plan and implement a way to secure the network traffic in your Anthos hybrid environment. The following services help with authentication, connectivity, and communication in a cluster:

• Anthos Identity Service connects clusters to on-site identity providers to authenticate local access.
• Connect gateway and workforce identity federation can provide secure cloud-mediated access to mobile workforce clusters without using a VPN.
• Workload Identity provides on-premises workloads with managed short-lifetime credentials for access to cloud resources.
• Anthos Service Mesh encrypts and controls communication between services in the same cluster.

The following diagram shows how Anthos Service Mesh can control the flow of traffic between services within your clusters:

You don’t have to implement all these cloud-based services as part of your initial on-premises deployments. As you become more comfortable and want to expand your capabilities, you can add in some of these hybrid offerings. But, we hope that this blog post has given you some ideas to think about when you start to plan and design your own Anthos hybrid environments.

For more detailed guidance and planning information, see the full Anthos hybrid environment reference architecture. Let us know what you think!

Kubernetes is an increasingly key part of the application deployment strategies at large organizations, and one of the most recommended options for the teams we work with. An idea brought to life at Google, organizations throughout the world use containers and Kubernetes on-premises, in Google Cloud, or in a multi-cloud scenario, and it has emerged as a leading application deployment platform. And because it’s open source, anyone can pop the hood, so to speak, to see how each component of it works, creating a trusted, verifiable framework that users can rely on.

Customers begin their Kubernetes and containerization journeys using various offerings in our product portfolio. Some, like Colgate, started their modernization journey with Kubernetes. Colgate is an $18B global consumer products company with ~34,000 diverse and dedicated people serving over 200 countries and territories. Through science-led innovation, they drive growth and reimagine a healthier future for all people, their pets, and our planet. 

During ideation, they talked through various considerations: What technology strengths does their organization have? What skills do their teams need? What will this initiative look like a decade from now? They implemented the following Kubernetes-focused architecture:

Supporting a variety of use cases and teams

Google Cloud also helped Colgate break new ground over the years, especially in the areas of cloud-native networking, security, monitoring, pub/sub, managed containerization, and multi-tenant environments.

Over time Colgate began to leverage Google’s managed container portfolio, which includes Cloud Run. Cloud Run lets you run containers on top of a serverless platform, unlocking workload possibilities for public websites, private services, APIs and batch jobs and eliminating a lot of the time spent on infrastructure management. Cloud Run also requires no prior knowledge of Kubernetes or containers.

Simplified enterprise-level management

Many teams have found that they prefer the serverless, hands-off approach that Cloud Run provides, and Colgate now evaluates Google Cloud’s serverless solutions alongside GKE for any applications destined for the cloud. At the same time, Cloud Run lets them continue to leverage their investment in workloads based on the Open Container Initiative. 

For example, Cloud Run is designed for Kubernetes compatibility with consistent management capabilities such as the ability to manage resources using kubectl via the config controller, and the ability to browse logs and metrics from both platforms in Cloud Logging and Monitoring. Cloud Run and GKE data planes are also interoperable, allowing Cloud Run and GKE services to be exposed behind a VPC behind private IPs using an internal load balancer. Cloud Run as an option has contributed to faster innovation, allowing Colgate to bring smiles to many more faces globally.

Google’s managed container offerings provide a composable and comprehensive set of solutions for customers’ applications. At Colgate, container-based managed services are used across the stack: on the front-end, where they use Identity-Aware Proxy to manage authentication and External Load Balancers to handle incoming traffic with high availability and low latency; at the application layer, where they can choose from Cloud Functions, Cloud Run, or GKE, depending on the level of control they need over the application; and at the internal load balancing level where NGINX® controllers serve internal applications. Together, these managed services ensure that Colgate has the flexibility to choose the right toolchain and maximize their goals for each use case. 

Colgate wanted to build internal applications on Cloud Run in a way that complied with their organization’s policies while maximizing developer productivity. They were able to use new features like the Cloud Run Identity Aware Proxy GA to build a secure, serverless deployment for their applications.

A great partnership with Google Cloud

Colgate and Google Cloud have enjoyed a deep partnership for many years, engaging across many technologies, teams, and design patterns.

They’ve engaged with Product and Engineering across compute, networking, Kubernetes, and serverless as they brought this new way of thinking to their users.

For Colgate and many of our customers looking to address the needs of the modern user, Google’s managed container offerings are a breath of fresh air. Its reliability, scalability, and control offer the  flexibility to build applications that meet the demands of both internal and external consumers. In addition, the variety of container offerings available on Google Cloud — GKE and Cloud Run — allow customers to make app deployment decisions based on the amount of Day 2 operations the users are willing to take on. Platform administrators appreciate the reduced management effort, users enjoy reduced downtime, and developers can simply deploy.

^{Google Cloud contributors: Rex Orioko, Rachel Tsao
Colgate-Palmolive contributors: Matthew Tattoli, Nicholas Farley, and David Wiser}