At Google Cloud, we believe you get most benefits from the cloud when you scale infrastructure based on changing demand. Compute Engine allows you to configure autoscaling to save costs during periods of low demand, and add capacity to support peak loads. 

When you use a managed instance group (MIG), you can have an autoscaler automatically create or delete virtual machine (VM) instances based on increases or decreases in load. However, if your application takes several minutes to initialize, creating VMs in response to growing load might not increase your application’s capacity quickly enough. For example, if there’s a large increase in load (like when users first wake up in the morning), some users might experience delays while your application is initializing on new instances.

A good way to solve this problem would be to create VMs ahead of demand so that your application has enough time to initialize beforehand. This requires knowing upcoming demand. If only we could predict the future… Well, now we can!

Introducing predictive autoscaling

Predictive autoscaling uses Google Cloud’s machine learning capabilities to forecast capacity needs. It creates VMs ahead of growing demand allowing enough time for your application to initialize.

How does it work?

Predictive autoscaling uses your instance group’s CPU history to forecast future load and calculate how many VMs are needed to meet your target CPU utilization. Our machine learning adjusts the forecast based on recurring load patterns for each MIG. 

You can specify how far in advance you want autoscaler to create new VMs by configuring the application initialization period. For example, if your app takes 5 minutes to initialize, autoscaler will create new instances 5 minutes ahead of the anticipated load increase. This allows you to keep your CPU utilization within the target and keep your application responsive even when there’s high growth in demand. 

Many of our customers have different capacity needs during different times of the day or different days of the week. Our forecasting model understands weekly and daily patterns to cover for these differences. For example, if your app usually needs less capacity on the weekend our forecast will capture that. Or, if you have higher capacity needs during working hours, we also have you covered.

Why should you try it?

Predictive autoscaling continuously adapts forecasted capacity to best match upcoming demand. Autoscaler checks the forecast several times per minute and creates or deletes VMs to match its prediction. The forecast itself is updated every few minutes to match recent load trends so if your growth rate is higher or lower than usual we will adjust the forecast accordingly. This gives you capacity needed to cover peak load while saving on cost when demand goes down. 

You can start using predictive autoscaling without worry as it’s fully compatible with the current autoscaler. Autoscaler will calculate enough VMs to cover both forecasted as well as real-time CPU load—whichever is higher. This works with other autoscaling features as well: you can scale based on schedule, your Load Balancer request target or Cloud Monitoring metrics. Autoscaler provides enough capacity to all of your configurations by taking the highest number of VMs needed to meet all your targets.

Getting started

You can enable predictive autoscaling in the Google Cloud Console. Select an autoscaled MIG from the instance groups page and click Edit group. Change predictive autoscaling configuration from Off to Optimize for availability.

To better understand whether predictive autoscaling is good for your application, click the link See if predictive autoscaling can optimize your availability. This will show you a comparison of the last seven days with your current autoscaling configuration vs. with predictive autoscaling enabled.

In the above chart, 

• Average VM minutes overloaded per day shows how often your VMs exceed your CPU utilization target. This happens when demand is higher than available capacity. Predictive autoscaling can reduce this by starting VMs ahead of anticipated load. 
• Average VMs per day is a proxy for cost. This shows how much additional VM capacity you need to keep your CPU utilization within the target you have set. You can optimize your cost by adjusting Minimum instances andCPU utilization as explained below. 

Optimizing your configuration

Make sure your Cool down period reflects how long it takes for your application to initialize from VM boot time until it’s ready to serve the load. Predictive autoscaling will use this value to start VMs ahead of forecasted load. If you set it to 10 minutes (600 seconds) your VMs will start 10 minutes before the load is expected to increase.

Review your autoscaling CPU utilization target and Minimum number of instances. With predictive autoscaling you no longer need a buffer to compensate for the time it takes for a VM to start. If your application works best at 70% CPU utilization you don’t need to set target to a much lower value as predictive autoscaling will start VMs ahead of usual load. A higher CPU utilization and lower Minimum number of instances allows you to reduce the cost as you don’t need to pay for additional capacity to prepare for growing demand.

Try predictive autoscaling today

Predictive autoscaling is generally available across all Google Cloud regions. For more information on how to configure, simulate and monitor predictive autoscaling, consult the documentation.

Responding to multiple, simultaneous disruptive forces has become a daily routine for most demand planners. To effectively forecast demand, they need to be able to predict the unpredictable while accounting for diverse and sometimes competing factors, including:

• Labor and materials shortages
• Global health crises
• Shifting cross-border restrictions
• Unprecedented weather impacts
• A deepening focus on sustainability
• Rising inflation

Innovators are looking to improve demand forecast accuracy by incorporating advanced capabilities for AI and data analytics, which also speed up demand planning. According to a McKinsey survey of dozens of supply chain executives, 90% expect to overhaul planning IT within the next five years, and 80% expect to or already use AI and machine learning in planning.

Google Cloud and SAP have partnered to help customers navigate these challenges and supply chain disruptions starting with the upstream demand planning process, focusing on improving forecast accuracy and speed through integrated, engineered solutions. The partnership is enabling demand planners who use SAP IBP for Supply Chain in conjunction with Google Cloud services to access a growing repository of third-party contextual data for their forecasting, as well use an AI-driven methodology that streamlines workflows and improves forecast accuracy. Let’s take a closer look at these capabilities.

Unify data from SAP software with unique Google data signals

When it comes to demand forecasting and planning, the more high-quality and relevant contextual data you use, the better, because it helps you understand the influencing factors of your product sales to sense trends and react to disruptions or capitalize on market opportunities more timely and accurately.

The expanded Google Cloud and SAP partnership helps customers who use SAP® Integrated Business Planning for Supply Chain (SAP IBP for Supply Chain) bring public and commercial data sets that Google Cloud offers into their own instances of SAP IBP and include them in their demand planning models in SAP IBP. So, in addition to sales history, promotions, stakeholder inputs and customer data that are typically in SAP IBP, a demand planner can incorporate their advertising performance, online search, consumer trends, community health data, and many more data signals from Google Cloud when working through demand scenarios.

More data enables more robust and accurate planning, so Google continues to build an ecosystem of data providers and grow the number of available data sets on Google Cloud. Some current providers include the U.S. Census Bureau, the National Oceanic and Atmospheric Administration, and Google Earth, and partnerships are underway with Crux, Climate Engine, Craft, and Dun & Bradstreet to help companies identify and mitigate risk and build resilient supply chains.

Augmenting demand planning with additional external causal factor data is a starting point to drive more accurate forecasting. For example, knowing what regional events may be happening, or the weather patterns that may impact sales of your products, allows you to react faster to these changes by making sure adequate supply is being provided. The result is a more accurate overall plan that reduces resource waste and out-of-stock events. Planners can respond with more accurate and granular daily predictions about sales, pricing, sourcing, production, inventory, logistics, marketing, advertising, and more based on the expanded data.

Get more accurate forecasts with Google AI inside

Extending the already expansive algorithm selection available in SAP IBP, the release of version 2205 allows SAP IBP customers to access Google Cloud’s supply chain forecasting engine, which is built on Vertex AI — Google Cloud’s AI-as-a-platform offering — from within SAP IBP as part of their forecasting process.

The benefit of using an AI-driven engine for demand forecasting is that it meaningfully improves forecast accuracy. Most demand forecasting today is done through a manually set, rules-based model versus an AI-driven model that is smarter and gets better at predicting demand as it works.

Take the fastest path from data to value with streamlined workflows

Vertex AI can include relevant contextual data sets for demand planning, and the results can be shown in SAP IBP for planners to incorporate when building their workflows.

In addition to more accurate forecasts, planners can work faster and more efficiently as they build potential scenarios, meaning they can do more simulations than they do now so that a wider range of disruptions can be modeled. Customers of SAP IBP don’t have to do any of the heavy lifting. They just have to share their data from SAP IBP with Google, then access the process workflow capabilities to set up automated workflows that use the combined data. Google makes the data available so that planners can use it as they’re setting up their workflows in Vertex AI.

Users of the Google Supply Chain twin and SAP IBP can combine the rich planning data from IBP with additional SAP data and other Google data sources to provide better supply chain visibility. The Google Supply Chain twin is a real-time digital representation of your supply chain based on sales history, open customer orders, past and future promotions, pricing and competitor insights, consumer history signals, external data signals and Google data.

Leverage Google data signals with SAP IBP for more accurate forecasts

It’s not difficult to access these new capabilities, and the benefits are more accurate near-term forecasts and more return on your investments in SAP IBP and Google Cloud. If you happen to be at the Gartner Supply Chain Symposium from June 6-8th in Orlando, Florida, stop by our booth to say hello. Or, get started now

When our founders began Mambu in 2011, their goal was to bring the latest digital technologies to the banking and finance world. Banking, in particular, is an industry built on decades of deep legacy technology. So initially, Mambu was embraced by microfinance — 100 organizations in 26 countries in just the first two years. 

Since then, acceptance of modernizing core banking services by using composable, cloud technologies has grown across financial services institutions (FSIs). We now service top-tier banks, fintech startups, and other finance organizations across six continents, helping them deliver flexible, personalized, customer-centric banking products and services that their customers can depend upon.

One of the main reasons we’ve been able to scale the Mambu composable banking platform across the globe and at our current pace is our partnership with Google Cloud. The decision to move forward with Google Cloud happened for several reasons.

1. Flexibility and openness. Many FSIs are on hybrid and multicloud technology stacks, as they may still be transitioning from legacy systems, or have data residency requirements that have led them to use different clouds in different regions. Mambu meets customers wherever they are in their cloud journeys. We support interoperability without vendor lock-in. This need for openness, as well as the scalability benefits, led Mambu to evolve our platform on Google Kubernetes Engine (GKE). Many customers use open-source Kubernetes because, this common foundation can help streamline integration, speed up time to market, and reduce development. Just as important, the Google Cloud open cloud approach matches our company values. 

2. Security and data residency. For customers in highly regulated finance industries, security isn’t just top of mind,  it’s the No. 1 requirement. In addition to Google Cloud’s secure infrastructure, external audit certifications, and encryption, its wide array of regions has allowed us to expand into more countries, where we serve banks that must meet local data residency requirements. For example, Google Cloud’s Jakarta Cloud Region, has allowed us to support Bank Jago in Indonesia as it brings more financial inclusion to the unbanked in that country.

3. Availability. It’s critical for banks to maintain basic financial functionality, like accepting deposits and serving cash, even amid a service disruption. We needed a cloud partner with impeccable redundancy, failover, and disaster recovery capabilities.

In addition to GKE, the Mambu platform uses several other Google Cloud services for specific functions, including Cloud Armor, Cloud Load Balancing, Cloud VPN, Cloud Memorystore, and Google Cloud Operations.

Another important reason we chose to partner with Google Cloud was its expansive ecosystem and commitment to innovation. We are midway into a three-year journey to modernize our own technology stack to meet customer needs.

Building a roadmap with Google Cloud

Our customers need a core banking technology platform that will grow with them as they bring to market innovative services built on the latest technology advances. For Mambu to be that platform, we need a cloud partner that supports and scales with our growth. While we originally built our cloud architecture on GKE and Compute Engine (among a few other Google Cloud services), we’re now looking to a serverless future where we can scale more easily and leverage managed services within Google Cloud and its partner ecosystem to focus on our core offerings. 

These are just some of the modernization and customer-led innovations that we’re cooking up: 

• More workloads in GKE: Like many companies, our cloud transformation is a work in progress. While much of our codebase is in GKE, we’re continuing to break up some larger pieces of code into microservices to increase agility and velocity, enabling us to make consistent updates to discrete areas of our platform without affecting the whole. GKE is the leader for orchestrating microservices at scale and continues to be a natural fit.
• Native BigQuery integration: Mambu customers collect a tremendous amount of data within the platform that can be used for analytics, personalization, and other use cases. We’re planning to create a seamless integration for feeding core banking data from Mambu into BigQuery so that customers can better leverage their valuable data.
• CloudSQL vs. self-managed MySQL: We have almost completed migrating from our own MySQL instances to managed Cloud SQL databases, which will open up new opportunities to implement customer-centric solutions such as BigQuery integration.
• A serverless future with Cloud Run: Compute Engine is working well for Mambu, providing the flexibility to choose the virtual machines that best balance performance and cost needs. As we seek even more time and cost efficiencies, we believe the elastic scalability of a serverless architecture built on Cloud Run will get us there, and we’re considering going serverless in the future. Doing so would abstract infrastructure for simpler management, while allowing us to fire up containers to meet our customers’ high transactions-per-second needs, spin them down when not needed, and pay only when they run. It would also boost security: Without long-running compute, there are no patches or fixes, and each new instance is isolated and fresh by default.

These are just a handful of examples of the ways we want to best leverage Google Cloud services to simplify how we manage our tech stack, as well as continue to bolster security, scalability, and performance. There are many other ideas we’re exploring: using Dataproc and Datastream to support the specific data needs of Islamic banking, Cloud Functions so that customers can run their own queries against Mambu, and AI-enabled features. 

At Mambu, our mission is to empower our customers to deliver great modern financial experiences easily to everyone around the world. Every time Google Cloud opens a new data center, we can enter a new market. Every time we move to a new-to-us managed service via the Google Cloud Marketplace, we free up time to build new ways to deliver customer-centric banking solutions. And so, we look forward to continuing this partnership with Google Cloud well into the future.