When customers migrate to Google Cloud Platform (GCP), their first step is often to adopt Compute Engine, which makes it easy to procure and set up virtual machines (VMs) in the cloud that provide large amounts of computing power. Launched in 2012, Compute Engine offers multiple machine types, many innovative features, and is available in 20 regions and 61 zones! 

Compute Engine’s predefined and custom machine types make it easy to choose VMs closest to your on-premises infrastructure, accelerating the workload migration process cost effectively. Cloud allows you the pricing advantage of ‘pay as you go’ and also provides significant savings as you use more compute with Sustained Use Discounts. 

As Technical Account Managers, we work with large enterprise customers to analyze their monthly spend and recommend optimization opportunities. In this blog, we will share the top recommendations that we’ve developed based on our collective experience working with GCP customers. 

Getting ready to save

Before you get started, be sure to familiarize yourself with the VM instance pricing page—required reading for anyone who needs to understand the Compute Engine billing model and resource-based pricing. In addition to those topics, you’ll also find information about the various Compute Engine machine types, committed use discounts and how to view your usage, among other things. 

Another important step to gain visibility into your Compute Engine cost is using Billing reports in the Google Cloud Console and customizing your views based on filtering and grouping by projects, labels and more. From there you can export Compute Engine usage details to BigQuery for more granular analysis. This allows you to query the datastore to understand your project’s vCPU usage trends and how many vCPUs can be reclaimed. If you have defined thresholds for the number of cores per project, usage trends can help you spot anomalies and take proactive actions. These actions could be rightsizing the VMs or reclaiming idle VMs.

Now, with these things under your belt, let’s go over the five ways you can optimize your Compute Engine resources that we believe will give you the most immediate benefit. 

1. Apply Compute Engine rightsizing recommendations

Compute Engine’s rightsizing recommendations feature provides machine type recommendations that are generated automatically based on system metrics gathered by Stackdriver Monitoring over the past eight days. Use these recommendations to resize your instance’s machine type to more efficiently use the instance’s resources. It also recommends custom machine types when appropropriate. Compute Engine makes viewing, resizing and other actions easier right from the Cloud Console as shown below. 

Recently, we expanded Compute Engine rightsizing capabilities from just individual instances to managed instance groups as well. Check out the documentation for more details.

For more precise recommendations, you can install the Stackdriver Monitoring agent which collects additional disk, CPU, network, and process metrics from your VM instances to better estimate your resource requirements. You can also leverage the Recommender API for managing recommendations at scale.

2. Purchase Commitments

Our customers have diverse workloads running on Google Cloud with differing availability requirements. Many customers follow a 70/30 rule when it comes to managing their VM fleet—they have constant year-round usage of ~70%, and a seasonal burst of ~30% during holidays or special events. 

If this sounds like you, you are probably provisioning resources for peak capacity. However, after migrating to Google Cloud, you can baseline your usage and take advantage of deeper discounts for Compute workloads. Committed Use Discounts are ideal if you have a predictable steady-state workload as you can purchase a one or three year commitment in exchange for a substantial discount on your VM usage.

We recently released a Committed Use Discount analysis report in the Cloud Console that helps you understand and analyze the effectiveness of the commitments you’ve purchased. In addition to this, large enterprise customers can work with their Technical Account Managers who can help manage their commitment purchases and work proactively with them to increase Committed Use Discount coverage and utilization to maximize their savings.

3. Automate cost optimizations

The best way to make sure that your team is always following cost-optimization best practices is to automate them, reducing manual intervention.

Automation is greatly simplified using a label—a key-value pair applied to various Google Cloud services. For example, you could label instances that only developers use during business hours with “env: development.” You could then use Cloud Scheduler to schedule a serverless Cloud Function to shut them down over the weekend or after business hours and then restart them when needed. Here is an architecture diagram and code samples that you can use to do this yourself. 

Using Cloud Functions to automate the cleanup of other Compute Engine resources can also save you a lot of time and money. For example, customers often forget about unattached (orphaned) persistent disk, or unused IP addresses. These accrue costs, even if they are not attached to a virtual machine instance. VMs with the “deletion rule” option set to “keep disk” retain persistent disks even after the VM is deleted. That’s great if you need to save the data on that disk for a later time, but those orphaned persistent disks can add up quickly and are often forgotten! There is a Google Cloud Solutions article that describes the architecture and sample code for using Cloud Functions, Cloud Scheduler, and Stackdriver to automatically look for these orphaned disks, take a snapshot of them, and remove them. This solution can be used as a blueprint for other cost automations such as cleaning up unused IP addresses, or stopping idle VMs. 

4. Use preemptible VMs

If you have workloads that are fault tolerant, like HPC, big data, media transcoding, CI/CD pipelines or stateless web applications, using preemptible VMs to batch-process them can provide massive cost savings. In fact, customer Descartes Labs reduced their analysis costs by more than 70% by using preemptible VMs to process satellite imagery and help businesses and governments predict global food supplies.

Preemptible VMs are short lived— they can only run a maximum of 24 hours, and they may be shut down before the 24 hour mark as well. A 30-second preemption notice is sent to the instance when a VM needs to be reclaimed, and you can use a shutdown script to clean up in that 30-second period. Be sure to fully review the full list of stipulations when considering preemptible VMs for your workload. All machine types are available as preemptible VMs, and you can launch one simply by adding “-preemptible” to the gcloud command line or selecting the option from the Cloud Console. 

Using preemptible VMs in your architecture is a great way to scale compute at a discounted rate, but you need to be sure that the workload can handle the potential interruptions if the VM needs to be reclaimed. One way to handle this is to ensure your application is checkpointing as it processes data, i.e., that it’s writing to storage outside the VM itself, like Google Cloud Storage or a database. As an example, we have sample code for using a shutdown script to write a checkpoint file into a Cloud Storage bucket. For web applications behind a load balancer, consider using the 30-second preemption notice to drain connections to that VM so the traffic can be shifted to another VM. Some customers also choose to automate the shutdown of preemptible VMs on a rolling basis before the 24-hour period is over, to avoid having multiple VMs shut down at the same time if they were launched together. 

5. Try autoscaling 

Another great way to save on costs is to run only as much capacity as you need, when you need it. As we mentioned earlier, typically around 70% of capacity is needed for steady-state usage, but when you need extra capacity, it’s critical to have it available. In an on-prem environment, you need to purchase that extra capacity ahead of time. In the cloud, you can leverage autoscaling to automatically flex to increased capacity only when you need it. 

Compute Engine managed instance groups are what give you this autoscaling capability in Google Cloud. You can scale up gracefully to handle an increase in traffic, and then automatically scale down again when the need for instances is lowered (downscaling). You can scale based on CPU utilization, HTTP load balancing capacity, or Stackdriver Monitoring metrics. This gives you the flexibility to scale based on what matters most to your application. 

High costs do not compute

As we’ve shown above, there are many ways to optimize your Compute Engine costs. Monitoring your environment and understanding your usage patterns is key to understanding the best options to start with, taking the time to model your baseline costs up front. Then, there are a wide variety of strategies to implement depending on your workload and current operating model. 

For more on cost management, check out our cost management video playlist. And for more tips and tricks on saving money on other GCP services, check out our blog posts on Cloud Storage, Networking and BigQuery cost optimization strategies. We have additional blog posts coming soon, so stay tuned!

Modern applications need to process large-scale data at millisecond latency to provide experiences like instant gaming leaderboards, fast analysis of streaming data from millions of IoT sensors, or real-time threat detection of malicious websites. In-memory datastores are a critical component to deliver the scale, performance, and availability required by these modern applications. 

Memorystore makes it easy for developers building applications on Google Cloud to leverage the speed and powerful capabilities of the most loved in-memory store: Redis. Memorystore for Redis standard tier instances are a popular choice for applications requiring a highly available Redis instance. Standard tier provides a failover replica across zones for redundancy and provides fast failover with a 99.9% SLA. However, in some cases, your applications will require more read throughput from a standard tier instance. One of the common patterns customers use to scale read queries in Redis is leveraging read replicas.

Introducing Memorystore for Redis Read Replicas

Today we are excited to announce the public preview of Memorystore for Redis Read Replicas, which allows you to seamlessly scale your application’s read requests by 6X with the click of a button.

With read replicas, you can easily add up to five replicas and leverage the read endpoint to automatically load balance read queries across all the available replicas, increasing read performance linearly with each replica added. Additionally, Memorystore’s support for Redis 6 introduced multi-thread I/O, increasing performance significantly for M3 and higher configurations. Combined, you can achieve read requests of more than a million requests per second. 

You will benefit from this new functionality in several ways. You will be able to scale on demand with up to five read replicas and use read endpoint with any redis client to easily load balance read queries across multiple replicas. This new functionality will also improve availability with automatic distribution of replicas across multiple zones. With read replicas, you will also be able to minimize application downtime with fast failover to the replica with the least replication lag. In the future, Memorystore will also easily enable read replicas on existing standard tier instances to increase read throughput. 

You can learn more about how to configure and use read replicas in the Read Replicas Overview. 

Improving performance with Read Replicas and Redis 6

With the launch of read replicas, you can easily increase the read throughput of a Memorystore instance. You can further enhance the read performance by leveraging Redis version 6 along with read replicas.

To understand why combining read replicas and Redis 6 can significantly improve your application’s read performance, let’s look at the various Memorystore configurations that you can use with your applications today. Memorystore Basic and Standard offerings  provide different capacity tiers. The capacity tier determines the single node performance of a basic and standard tier instance. 

The table below outlines the configuration of the various capacity tiers:

Up until version 5, Redis processed commands using a single thread. The processing involved reading the request, parsing the request, processing the request, and writing the response back to the socket. This approach means that all of the processing, which includes writing the response, was sequentially processed by a single vCPU regardless of the number of vCPUs available in the instance.

Redis 6 introduced I\O threading which allows writing the response using parallel threads. This functionality enables Redis 6 to more effectively leverage available vCPUs, thereby increasing the overall throughput compared to lower versions. Memorystore for Redis version 6 leverages I\O threading and automatically configures the optimal number of I\O threads to achieve the best possible performance for the various capacity tiers. We have also improved the overall network throughput for all redis versions by leveraging improvements in the Google Cloud infrastructure. Together these improvements deliver significant performance improvements and come at no additional cost to you. 

So what can you expect from using Redis 6? As outlined in the table, Redis version 5 and lower uses a single thread to process the write requests for all tiers while Redis 6 uses a larger number of I\O threads at higher capacity tiers which provides substantially incremental throughput for higher capacity tiers.

For example, using a Redis 6 standard tier instance with a capacity of 101 GB (M5), we have observed up to a 200% improvement in read/write performance compared to version 5, though the actual value you’ll see is dependent on your workload. You can get the benefits of Redis 6 by upgrading an existing instance or by deploying a new instance.

By enabling read replicas on an instance using Redis 6, you can further improve the read performance. Read throughput scales linearly with the number of replicas so you can increase your read queries on an instance by up to 500% using five read replicas. By combining Redis 6 and read replicas, you can see a 10X increase in read performance compared to a version 5 standard tier instance with no read replicas.

We are excited about the launch of read replicas but this is just one step in our journey to deliver the scale you need at the best price-performance. You can learn more about read replicas pricing on our Memorystore pricing page and get started using the Read Replicas Overview.

Cloud Functions, Google Cloud’s Function as a Service (FaaS) offering, is a lightweight compute platform for creating single-purpose, standalone functions that respond to events, without needing an administrator to manage a server or runtime environment. 

Over the past year we have shipped many new important capabilities on Cloud Functions: new runtimes (Java, .NET, Ruby, PHP), new regions (now up to 22), an enhanced user and developer experience, fine-grained security, and cost and scaling controls. But as we continue to expand the capabilities of Cloud Functions, the number-one friction point of FaaS is the “startup tax,” a.k.a. cold starts: if your function has been scaled down to zero, it can take a few seconds for it to initialize and start serving requests. 

Today, we’re excited to announce minimum (“min”) instances for Cloud Functions. By specifying a minimum number of instances of your application to keep online during periods of low demand, this new feature can dramatically improve performance for your serverless applications and workflows, minimizing your cold starts.

Min instances in action

Let’s take a deeper look at min instances with a popular, real-world use case: recording, transforming and serving a podcast. When you record a podcast, you need to get the audio in the right format (mp3, wav), and then make the podcast accessible so that users can easily access, download and listen to it. It’s also important to make your podcast accessible to the widest audience possible including those with trouble hearing and those who would prefer to read the transcript of the podcast. 

In this post, we show a demo application that takes a recorded podcast, transcribes the audio, stores the text in Cloud Storage, and then emails an end user with a link to the transcribed file, both with and without min instances. 

Approach 1: Building the application with Cloud Functions and Cloud Workflows

In this approach, we use Cloud Functions and Google Cloud Workflows to chain together three individual cloud functions. The first function (transcribe) transcribes the podcast, the second function (store-transcription) consumes the result of the first function in the workflow and stores it in Cloud Storage, and the third function (send-email) is triggered by Cloud Storage when the transcribed result is stored and sends an email to the user to inform them that the workflow is complete.

Cloud Workflows executes the functions in the right order and can be extended to add additional steps in the workflow in the future. While the architecture in this approach is simple, extensible and easy to understand, the cold start problem remains, impacting end-to-end latency. 

Approach 2: Building the application with Cloud Functions, Cloud Workflows and min instances

In this approach, we follow all the same steps as in Approach 1, with a slightly modified configuration that enables a set of min instances for each of the functions in the given workflow.

This approach presents the best of both worlds. It has the simplicity and elegance of wiring up the application architecture using Cloud Workflows and Cloud Functions. Further, each of the functions in this architecture leverages a set of min instances to mitigate the cold-start problem and time to transcribe the podcast.

Comparison of cold start performance

Now consider executing the Podcast transcription workflow using Approach 1, where no min instances are set on the functions that make up the app. Here is an instance of this run with a snapshot of the log entries. The start and end timestamps are highlighted to show the execution of the run. You can see here that the total runtime in Approach 1 took 17 s. 

Approach 1: Execution Time (without Min Instances)

Now consider executing the podcast transformation workflow using Approach 2, where min instances are set on the functions. Here is an instance of this run with a snapshot of the log entries. The start and end timestamps are highlighted to show the execution of the run, for a total of 6 s. 

Approach 2: Execution Time (with Min Instances)

That’s an 11 second difference between the two approaches. The example set of functions are hardcoded with a 2 to 3 second sleep during function initialization, and when combined with average platform cold-start times, you can clearly see the cost of not using min instances.

You can reproduce the above experiment in your own environment using the tutorial here. 

Check out min instances on Cloud Functions

We are super excited to ship min instances on Cloud Functions, which will allow you to run more latency-sensitive applications such as podcast transcription workflows in the serverless model. You can also learn more about Cloud Functions and Cloud Workflows in the following Quickstarts: Cloud Functions, Cloud Workflows.

Cloud infrastructure offers so many advantages: on-demand scalability, built-in security, and a bevy of tooling to scale your business at the speed of the Internet.

It enables companies to pursue “blitzscaling,” as Reid Hoffman calls it. Capital expenses that take years or decades to pay off are no longer required to establish global networking, compute capacity, storage resources, and application enablement tooling. By renting these assets from cloud providers, you can translate capital costs to operational costs, help your company to manage resources efficiently, keep expenses aligned with growth trajectory, and develop a portfolio of business-driving technology assets faster than would have previously been possible.

Certainly, this is the message from many founders and venture capitalists: move to the cloud, build a ton of software, scale like crazy, and win. Sounds great, right?

But history has shown us that the process is not quite this simple. Scale can be great and is a prerequisite to many of today’s most exciting business opportunities — but scale also frequently produces unintended consequences. You need to be able not only to achieve scale but also to manage it.

When scale produces bloat

To understand how unforeseen impacts can ripple out from a rapidly-scaled technology, consider the first mass-produced vehicle, the Model T. The first production model was produced in 1908, and less than two decades later, Ford had produced 15 million. This rapid growth profoundly affected urban living for decades.

Thanks to cars, fewer workers needed to live near cities or along major public transportation lines. The ease-of-access to personal transportation led to suburban population centers and, ultimately, urban sprawl. “Sub-cities” extricated homeowners from the density of urban population centers but also created a complex web of unintended consequences: new and often duplicative administrative bodies, new taxes, new zoning laws, and more intricate infrastructure projects. We are arguably still dealing with this fallout today as communities grapple with antiquated zoning laws and, in their attempts to find ways forward, often produce only more sprawl.

If your technology is in the cloud, you may be challenged with similar issues. For example, when developers build software in the cloud, many of the barriers to building software are removed. As a result, developers build a lot of software — but often without a lot of intentional design. This in turn results in companies building a large number of disparate systems and overwhelming app sprawl.

The cloud can help you proliferate technologies so quickly, in other words, that effective management and re-use of resources becomes incredibly tough.

Managing scale

Software assets are often seen as comprising the “brains” of a company — but to effectively grow, you should consider not only brains but also the digital nervous system. You need systems that connect the brains to all of the other important limbs that have to coordinate in order for your company to drive value.

One way of creating this nervous system and managing this complexity is to leverage the facade design pattern: applying an API layer that abstracts the underlying complexity of multiple systems into an elegant, reliable interface that encourages discovery and re-use of applications, functions, and other technology artifacts such as build and deployment pipelines.

For example, too many enterprises build a new digital “road” for each application that needs to authenticate or authorize users. Instead, you can leverage a facade pattern to help establish one “main road” for these purposes, encourage reuse of the road for new projects, and — with API management — monitor and control all traffic along the road. For tasks such as aligning risk and compliance operations or unifying developer onboarding functions, the distinction between reusing elegant roads and continually building new complicated ones could not be more important.

API management tools mean you can establish a single-pane-of-glass view into your network of digital roads and destinations or, if you prefer the biology metaphor, into the nervous system routes connecting your company’s software brains. This view becomes a point at which suspicious API usage patterns can be detected, reported, and handled and through which business-driving insights from legitimate traffic can be gleaned. Rather than dealing with IT sprawl, you can maintain visibility over your assets, control how they are used, roll out experimental digital products and get immediate feedback on adoption, and generate analytics to help you effectively divest from and invest in opportunities as the market demands.

More is not always better

More is not always better, and, in fact, it is sometimes worse.

It’s a time-worn sales axiom that would-be customers are more likely to make a choice when presented with two or three options rather than fifty, for example, and virtually all of us can relate to moments of “analysis paralysis” triggered by too many choices. These dynamics of choice are such that the diminishing marginal utility of each choice can detract from each option: with each choice comes a little stress, and as these stresses accumulate, customer satisfaction suffers. IT systems are no different; if developers building new connected experiences are left to their own designs, rather than encouraged with standardized resources and best practices, their work may add to complexity and customer dissatisfaction.

One need look only at the various open air markets around the world to see this point in action. They may offer many things to see but the experience is anything but efficient. The multitude of shops selling similar and duplicate items, the zigzag layout, and the expected friction from bargaining with each vendor all mean concepts such as market-wide product discovery and product inventory go out the window. If your developer experience mirrors these marketplaces, your efforts to scale are more likely to tangle up your operations than to satisfy customers.

Contrast this experience with luxury retail experiences where product areas are clearly demarcated in different retail spaces, product explanations accompany showcase items, inventory is available locally or ready to ship, clear pricing is readily available, and similar stores are intentionally anchored to strategic physical areas to encourage customer flow among them. The developer programs that cloud efforts are often meant to enable require a similar focus on luxurious experiences.

If your growth strategy creates bloat, internal developers will not use resources efficiently and your ability to share resources with external partners will likely be hamstrung. Applying API facades helps to ensure that your growing software portfolio is not a complicated maze to be navigated but rather a series of technology products for developers to leverage.

Indeed, you should think of the API itself as a product, not just a way of surfacing or connecting technology. The better the product, the more easily it can be managed, the better the experience developers will have using it, and the more control you’ll have harnessing the cloud to extend your business’s footprint.

Google Cloud Results

• Enables the speed and agility required to build open APIs
• Connects over 1 million customers through Apigee digital touch points
• Helps enable a range of digital banking and commercial partnerships
• 1billion API requests served annually

In 2016, Macquarie launched a new digital banking experience that was based on empowering customers, creating personalized experiences, and developing intuitive technology. Macquarie had the opportunity to build its digital environment from the ground up and looked beyond financial services to digital companies leading in customer experiences.

Following the launch of its digital banking platform in 2016, Macquarie saw providing customers with a secure way to manage their own data as the logical next step. Macquarie looked to transform its existing technology capabilities into a modern architecture that complements the speed and agility demanded of its digital platform. The Apigee API Management Platform plays an important role in helping Macquarie deliver a highly secure and open digital platform.

“The capability to connect to various platforms with a digital, responsive, technology-agnostic platform is vital. As new digital services emerge, it’s important that our digital banking services are future compatible. The most important part of our approach isn’t what we are doing now but what our platform architecture will allow us to do in the future by creating more human experiences with technology that go beyond just banking,” says Rajay Rai, head of Digital Engineering & Applied Innovation, for Macquarie’s Banking and Financial Services group.

Because Macquarie’s banking platform is based on an open API architecture, it is able to grant controlled access to its business services, enabling others to use, innovate, and build on top of them while increasing the prospects of widespread adoption and developer stickiness.

Empowering the developer

“Macquarie’s strategy has been API-first as it has built and improved its digital capabilities, but it won’t be too long until this approach is superseded by citizen-developers-first,” Rajay says. “We believe that co-creation of value is essential because in the future, we won’t be owning the channels for distribution and engagement. In building a leading digital banking platform it’s important that developers are able to open the front door.”

Macquarie’s API strategy grants internal and external developers with access to its rich repository of APIs exposed via the new developer platform, Macquarie devXchange. With Macquarie devXchange, developers have readily available samples, a sandbox, and simplified connections to all of the bank’s services. Developers are able to test APIs and services through the Apigee platform.

“Not only does the platform provide frictionless access, but it’s also poised to modernize and simplify the way we engage the community beyond our own perimeters,” Rajay says. “The Apigee developer portal is helping us seize new opportunities; access has been democratized and it wouldn’t have been possible without APIs.”

Cloud migration

In order to meet future demand for computing capabilities, Macquarie decided to move to the cloud in order to enable an infrastructure with various configurations on demand. This has cut the provisioning time for Macquarie from months to minutes.

Macquarie has created full end-to-end environments on Kubernetes and can flow traffic to a whole new environment in seconds, encouraging experimentation and learning. This was made possible through the flexibility of APIs.

“APIs and microservices are a great match. Microservices with Apigee provide a powerful, agile ecosystem to form various services topologies and evolve services in an isolated manner. This helps us respond to the fast pace of digital innovation today,” Rajay says.

Empowering consumers

Macquarie’s approach is about delivering customers more personalized banking experiences that are driven by how they want to use their information.

“APIs have enabled us to co-create value with our partners, customers, and developers. You can’t live in isolation; open source tells you that,” Rajay says. “APIs have been vital for us and what we can deliver for our customers as we’ve built our leading digital platform.”