FM Logistic provides its international customers with complete logistics solutions that cover everything from warehousing and handling, to transport and distribution, co-packing and co-manufacturing, and supply chain optimization. Operating in 14 countries including France, Russia, Poland, India, Vietnam, Brazil, and China, FM Logistic supports its clients by offering specialized services across a number of markets including consumer goods, retail, cosmetics, and health.

“We are in the process of transforming all our tools and integrating new solutions to be able to work faster and more efficiently. Two main IT priorities are mobility and openness, in terms of working from anywhere and being able to interact with other information systems.”

– Communication Manager, FM Logistic

As a business that has existed since 1967 and in 2018 achieved a turnover of €1.178 billion with 9.5% annual growth, FM Logistic is always looking to help secure the company’s position within an evolving sector. To better serve its customers, FM Logistic decided to launch an innovation project in 2017 to transform the internal digital tools of the company and replace its intranet, email, and productivity software. The company looked for an integrated solution that would enable more collaborative ways of working and bring its international operations closer together. The company found that implementing G Suite and LumApps social intranet was the perfect combination.

“We are in the process of transforming all our tools and integrating new solutions to be able to work faster and more efficiently,” says the Communication Manager at FM Logistic. “Two main IT priorities are mobility and openness, in terms of working from anywhere and being able to interact with other information systems.”

A global transformation

For large international companies with global operations, implementing a single integrated solution to enable collaboration across regions while respecting regional variations can be a real challenge.

“We have 26,000 employees spread across a broad geography, with a variation in cultures and technological maturity. There was an aspiration to work in collaboration, but the necessary tools were not in place,” says FM Logistic’s Communication Manager. FM Logistic looked for a solution to enable new, more collaborative work practices, which were flexible in terms of usage and that, most importantly, would work as part of an integrated solution.

To do that, FM Logistic worked with Google Partner Devoteam G Cloud to implement G Suite alongside the LumApps intranet portal. It took six months to complete the migration of 7,000 accounts, with employees accessing the Business or Basic G Suite edition according to their needs. “Before, with our physical infrastructure we found ourselves buying additional hard drives as we ran out of storage,” says the Technical Project Manager at FM Logistic. “That’s no longer a problem, and we can tailor access depending on whether or not employees need unlimited storage .”

“It’s a real advantage to be able to access your account from any device and work from anywhere. Hangouts Meet has been really transformational in that respect: it has reduced the need for travel significantly, even in the few months we’ve been using it so far.”

– Communication Manager, FM Logistic

“We followed Google’s G Suite migration advice and had early adopter ambassadors in every country. By the time we got around to the final country, very little input was needed as they were ready to go!” says the Technical Project Manager. “Many of them were already familiar with the product, so it was very intuitive. Our feedback surveys gave a satisfaction rating of almost 4.5 out of 5 in relation to the transition. We also had significant executive support, with two members of the executive committee on the steering board. That really helped the project to move quickly.”

As a result, employees were quick to understand the benefits of the new system. “It’s a real advantage to be able to access your account from any device and work from anywhere. That was clear from the start,” says the Communication Manager. “Hangouts Meet has been really transformational in that respect: it has reduced the need for travel significantly, even in the few months we’ve been using it so far.”

LumApps: a fully-integrated enterprise hub

One of FM Logistic’s main reasons for choosing G Suite was the seamless integration with LumApps’ intranet portal. LumApps adds value to G Suite, thereby boosting and sustaining employee adoption. FM Logistic chose LumApps to create a hub for its enterprise, where everything is centralized from internal communications to business apps.

“We didn’t want a patchwork of solutions, we needed a platform that worked as an integral whole,” says the Technical Project Manager. “With LumApps, employees access the intranet using their Google authentication and can access all their G Suite tools through the intranet. Moreover, LumApps is Google native, so the integration is seamless and we know that it will evolve to accommodate any changes that might take place.”

“The main advantages we see are communication and knowledge sharing,” says the Communication Manager. “With LumApps, all 26,000 of our employees are now able to access the portal in their own language and access local news.”

For the next step, FM Logistic is considering integrating social communities so that employees can express themselves and be more engaged in the corporate culture.

Supporting digital maturity

Thanks to Drive, employees can now work from wherever they are, and are able to work more efficiently and more collaboratively. “From an administrative point of view, users can benefit from automatic updates, so there is less pressure on the IT department,” says the Technical Project Manager. “And we’re seeing many innovative uses of the tools to work in more efficient ways: many services have gone paperless with Forms, so less time is wasted; commercial agents are using Drive to work together on tenders simultaneously; and with Sheets, tasks are automatically sent from the team manager’s file to employee’s Calendar.”

“G Suite and LumApps are the first step of our digital transformation, in terms of collaboration and moving into the cloud. We have real confidence in our partners LumApps and Google, and we’re investing in those relationships for the long-term benefit of the company.”

– Communication Manager, FM Logistic

Now, FM Logistic wants to further support its employees in exploring all the tools G Suite has to offer. “We are embarking on a second phase to give our employees the skills they need for advanced uses of Docs, Sheets, and Forms,” says the Communication Manager. “It’s a learning curve, but it’s key to our goal of transforming our everyday processes.”

“G Suite and LumApps are the first step of our digital transformation, in terms of collaboration and moving into the cloud. We have real confidence in our partners LumApps and Google, and we’re investing in those relationships for the long-term benefit of the company.”

Cloud migration is top of mind for most companies with SAP applications. While the advantages of the cloud for SAP customers is generally understood, the move itself can be complicated and disruptive. So what actually are the business benefits and cost savings? How long will it take to recoup such an investment? Two recently published reports from Forrester and IDC can help to quantify the benefits and ROI. 

Getting answers to the million-dollar questions
Forrester and IDC bring different methodologies to the table; they asked somewhat different questions and used different models to calculate their financial KPIs. This allows you to get two different points of view on the same basic questions about value, risk, and ROI.

As it turns out, both reports found that customers who migrate their SAP environments to Google Cloud see an impressive return on their investments. From uptime and infrastructure to efficiency and productivity—both Forrester and IDC identified major benefits to companies that have made the move to Google Cloud.

Let’s walk through some of the highlights from both reports.

Forrester’s TEI model spotlights the power of uptime improvements
Based on in-depth conversations and quantitative research with six companies, here are the key findings from the Forrester Total Economic Impact (TEI) study for companies running SAP systems on Google Cloud: 

• Direct cost savings. When they compare cloud subscription and related costs to what they spent on legacy systems and infrastructure, most IT leaders expect a cloud migration to deliver up-front savings. But according to Forrester, the companies interviewed reported average savings of more than $3 million a year, including eliminated hardware purchases, right-sized software licensing, staffing efficiencies, and other operational cost savings.

• Dramatically improved uptime. Customers told Forrester that migrating SAP to Google Cloud pretty much eliminates downtime—planned or unplanned—as a significant IT concern. According to Forrester, companies realized an average of $1.5 million in savings per year by avoiding the revenue and user productivity losses that had once been a fact of life for their IT teams.
• Significant efficiency gains. Because Google Cloud works to mitigate performance bottlenecks, infrastructure mishaps, network delays and more, the companies Forrester interviewed reported a yearly average of $500,000 in productivity gains for SAP business users and frontline workers.

Companies also reported an annual average of $500,000 in additional IT efficiency gains after migrating SAP to Google Cloud. This quantifies what happens when IT practitioners no longer have to deal with the bottlenecks that come with legacy systems, and are able to spend their time on tasks that actually build value and help the business. Based on the Forrester analysis, the companies interviewed could expect average three-year net benefits of about $15.4 million.

“We benefit from any technical innovation in the infrastructure area because Google Cloud is doing that for us,” one customer told Forrester. “So, whenever there’s new hardware available or new processes or whatever, I don’t have to run the specific project to migrate from A to B.” 

IDC finds that good things happen when SAP downtime is reduced 
The IDC report highlights four areas where Google Cloud generates the most value for customers:

1. Cutting infrastructure costs. According to IDC, customers running SAP on Google Cloud spent 31% less on infrastructure each year, or an average of $233,000 less per company. The ability to scale SAP environments dynamically and to keep them right-sized was a major factor; so were the advantages of automated infrastructure monitoring and savings on software licenses once these companies could stop overprovisioning.

2. Giving a team better things to do. IDC found that the infrastructure, database, and security teams of the companies they interviewed reduced the time they need to maintain and manage SAP environments by an average of 66% per year, for a savings of $443,000, per company. As a result, these companies got the equivalent of a major staff expansion from their SAP migrations—giving them both the staff time and the expertise to focus on far more valuable activities.

3. Limiting unplanned downtime. These companies reported to IDC an average 98% reduction in unplanned downtime. Migrating SAP to Google Cloud significantly reduces the threat of downtime and saves the business an average of nearly $770,000 per year in lost revenue and user productivity. For some firms, the downtime savings topped $1 million per year.

4. Making users more productive. The companies interviewed told IDC that by avoiding downtime and disruptions associated with upgrade and maintenance tasks for their legacy SAP systems, they saved an average of $363,000 annually in user productivity. But there’s an even more interesting under-the-hood stat contributing to these gains: These companies reduced the time required to deploy new SAP compute and storage resources from an average of 8.8 days to 1 hour.

When IDC added up these and other savings associated with running SAP on Google Cloud, it found an average three-year savings of more than $3.5 million and a five-month payback period. 

“We acquired another company, so basically overnight we needed to be able to deal with that increase,” said one customer IDC spoke with. “We doubled our footprint overnight, and we had to take on hundreds of additional employees. We needed a platform that we could easily scale up if we required, and that’s the benefit of running SAP on Google Cloud for us.” 

Explore the reports
There is a lot to think about when considering a move of SAP systems to the cloud. The cloud has many advantages, but migration can seem complicated and tricky; we appreciate that you are looking to understand the full picture. These papers are a great place to start. 

Download the reports—Forrester’s “Total Economic Impact of SAP on Google Cloud” and IDC’s “Business Value of SAP for Google Cloud Environments.” Then, get in touch.

As an enterprise admin, when you choose to use Google Cloud Private Catalog to enable curated, self-serve Google Cloud infrastructure provisioning, you need the ability to manage your organization’s deployments. Today, we’re pleased to announce support for several improvements to Terraform driven deployments through Private Catalog. 

With this new release, you can update Terraform configurations and keep your end users informed about updates. At the same time, Private Catalog users have the ability to view new updates, note version highlights and then update the deployment. This gives you greater control over managing deployments for solutions provisioned through Private Catalog and ensuring compliance with organizational policies and standards.

Let’s take a closer look at the features you’ll find in this release. 

Deployment change management

Terraform solutions use Cloud Storage’s Object Versioning to manage updates to configuration files. With this release, you may update configuration files using multiple approaches.

• Update the solution’s Cloud Storage object with a new configuration version
• Use a different Cloud Storage object that contains a new configuration file

Once you view and apply the changes to the solution in a Private Catalog, end users are immediately able to consume the new version of the deployment configuration.

Additionally, prior to applying any changes, you can evaluate the contents of an update by comparing versions to download and compare the current and latest versions of the configuration and use new version highlights to add a description about the updates.

Ease of consumption

Once Private Catalog detects a change to the deployment configuration, it automatically informs catalog users about the change. On the Solutions page, end users have the ability to:

• Get informed about solutions that have updates
• View version highlights published by the admin
• Apply the new version 

Additionally, with this release, Catalog users can retry existing deployments by modifying deployment parameters.

Reporting improvements

The deployment reporting dashboards for Private Catalog-based deployments now show additional information about the version of a solution deployed. This enables deeper insights into the overall deployment status across all Private Catalog solution assets.

Get started today

These new features are available to all Private Catalog customers. To learn how to use these features, refer to our documentation:

• Create a Terraform configuration in Private Catalog
• Manage and update your Terraform configurations in Private Catalog

Records are made to be broken. In 2019, we calculated 31.4 trillion digits of π — a world record at the time. Then, in 2021, scientists at the University of Applied Sciences of the Grisons calculated another 31.4 trillion digits of the constant, bringing the total up to 62.8 trillion decimal places. Today we’re announcing yet another record: 100 trillion digits of π.

This is the second time we’ve used Google Cloud to calculate a record number1 of digits for the mathematical constant, tripling the number of digits in just three years.

This achievement is a testament to how much faster Google Cloud infrastructure gets, year in, year out. The underlying technology that made this possible is Compute Engine, Google Cloud’s secure and customizable compute service, and its several recent additions and improvements: the Compute Engine N2 machine family, 100 Gbps egress bandwidth, Google Virtual NIC, and balanced Persistent Disks. It’s a long list, but we’ll explain each feature one by one.

Before we dive into the tech, here’s an overview of the job we ran to calculate our 100 trillion digits of π.

• Program: y-cruncher v0.7.8, by Alexander J. Yee
• Algorithm: Chudnovsky algorithm
• Compute node: n2-highmem-128 with 128 vCPUs and 864 GB RAM
• Start time: Thu Oct 14 04:45:44 2021 UTC
• End time: Mon Mar 21 04:16:52 2022 UTC
• Total elapsed time: 157 days, 23 hours, 31 minutes and 7.651 seconds
• Total storage size: 663 TB available, 515 TB used
• Total I/O: 43.5 PB read, 38.5 PB written, 82 PB total

Architecture overview

Calculating π is compute-, storage-, and network-intensive. Here’s how we configured our Compute Engine environment for the challenge.

For storage, we estimated the size of the temporary storage required for the calculation to be around 554 TB. The maximum persistent disk capacity that you can attach to a single virtual machine is 257 TB, which is often enough for traditional single node applications, but not in this case. We designed a cluster of one computational node and 32 storage nodes, for a total of 64 iSCSI block storage targets.

The main compute node is a n2-highmem-128 machine running Debian Linux 11, with 128 vCPUs and 864 GB of memory, and 100 Gbps egress bandwidth support. The higher bandwidth support is a critical requirement for the system as we adopted a network-based shared storage architecture.

Each storage server is a n2-highcpu-16 machine configured with two 10,359 GB zonal balanced persistent disks. The N2 machine series provides balanced price/performance, and when configured with 16 vCPUs it provides a network bandwidth of 32 Gbps, with an option to use the latest Intel Ice Lake CPU platform, which makes it a good choice for high-performance storage servers.

Automating the solution

We used Terraform to set up and manage the cluster. We also wrote a couple of shell scripts to automate critical tasks such as deleting old snapshots, and restarting from snapshots (we didn’t need to use this though). The Terraform scripts created OS guest policies to help ensure that the required software packages were automatically installed. Part of the guest OS setup process was handled by startup scripts. In this way, we were able to recreate the entire cluster with just a few commands.

We knew the calculation would run for several months and even a small performance difference could change the runtime by days or possibly weeks. There are also a number of combinations of parameters in the operating system, infrastructure, and application itself. Terraform helped us test dozens of different infrastructure options in a short time. We also developed a small program that runs y-cruncher with different parameters and automated a significant portion of the measurement. Overall, the final design for this calculation was about twice as fast as our first design. In other words, the calculation could’ve taken 300 days instead of 157 days!

The scripts we used are available on GitHub if you want to look at the actual code that we used to calculate the 100 trillion digits.

Choosing the right machine type for the job

Compute Engine offers machine types that support compute- and I/O-intensive workloads. The amount of available memory and network bandwidth were the two most important factors, so we selected n2-highmem-128 (Intel Xeon, 128 vCPUs and 864 GB RAM). It satisfied our requirements: high-performance CPU, large memory, and 100 Gbps egress bandwidth. This VM shape is part of the most popular general purpose VM family in Google Cloud.

100 Gbps networking

The n2-highmem-128 machine type’s support for up to 100 Gbps of egress throughput was also critical. Back in 2019 when we did our 31.4-trillion digit calculation, egress throughput was only 16 Gbps, meaning that bandwidth has increased by 600% in just three years. This increase was a big factor that made this 100-trillion experiment possible, allowing us to move 82.0 PB of data for the calculation, up from 19.1 PB in 2019.

We also changed the network driver from virtio to the new Google Virtual NIC (gVNIC). gVNIC is a new device driver and tightly integrates with Google’s Andromeda virtual network stack to help achieve higher throughput and lower latency. It is also a requirement for 100 Gbps egress bandwidth.

Storage design

Our choice of storage was crucial to the success of this cluster – in terms of capacity, performance, reliability, cost and more. Because the dataset doesn’t fit into main memory, the speed of the storage system was the bottleneck of the calculation. We needed a robust, durable storage system that could handle petabytes of data without any loss or corruption, while fully utilizing the 100 Gbps bandwidth.

Persistent Disk (PD) is a durable high-performance storage option for Compute Engine virtual machines. For this job we decided to use balanced PD, a new type of persistent disk that offers up to 1,200 MB/s read and write throughput and 15-80k IOPS, for about 60% of the cost of SSD PDs. This storage profile is a sweet spot for y-cruncher, which needs high throughput and medium IOPS.

Using Terraform, we tested different combinations of storage node counts, iSCSI targets per node, machine types, and disk size. From those tests, we determined that 32 nodes and 64 disks would likely achieve the best performance for this particular workload.

We scheduled backups automatically every two days using a shell script that checks the time since the last snapshots, runs the fstrim command to discard all unused blocks, and runs the gcloud compute disks snapshot command to create PD snapshots. The gcloud command returns and y-cruncher resumes calculations after a few seconds while the Compute Engine infrastructure copies the data blocks asynchronously in the background, minimizing downtime for the backups.

To store the final results, we attached two 50 TB disks directly to the compute node. Those disks weren’t used until the very last moment, so we didn’t allocate the full capacity until y-cruncher reached the final steps of the calculation, saving four months worth of storage costs for 100 TB.

Results

All this fine tuning and benchmarking got us to the one-hundred trillionth digit of π — 0. We verified the final numbers with another algorithm (Bailey–Borwein–Plouffe formula) when the calculation was completed. This verification was the scariest moment of the entire process because there is no sure way of knowing whether or not the calculation was successful until it finished, five months after it began. Happily, the Bailey-Borwein-Plouffe formula found that our results were valid. Woo-hoo! Here are the last 100 digits of the result:

4658718895 1242883556 4671544483 9873493812 1206904813
2656719174 5255431487 2142102057 7077336434 3095295560

You can also access the entire sequence of numbers on our demo site.

So what?

You may not need to calculate trillions of decimals of π, but this massive calculation demonstrates how Google Cloud’s flexible infrastructure lets teams around the world push the boundaries of scientific experimentation. It’s also an example of the reliability of our products – the program ran for more than five months without node failures, and handled every bit in the 82 PB of disk I/O correctly. The improvements to our infrastructure and products over the last three years made this calculation possible.

Running this calculation was great fun, and we hope that this blog post has given you some ideas about how to use Google Cloud’s scalable compute, networking, and storage infrastructure for your own high performance computing workloads. To get started, we’ve created a codelab where you can create and calculate pi on a Compute Engine virtual machine with step-by-step instructions. And for more on the history of calculating pi, check out this post on The Keyword. Here’s to breaking the next record!

1. We are actively working with Guinness World Records to secure their official validation of this feat as a “World Record”, but we couldn’t wait to share it with the world. This record has been reviewed and validated by Alexander J. Yee, the author of y-cruncher.

Google Cloud is built on world-class technical infrastructure that supports services that are loved and relied on by billions of people across the globe: Google Search, YouTube, Gmail, Google Maps and more. A core tenet at Google Cloud is to leverage Google’s experience building and operating highly available and highly reliable planetary-scale compute, storage and networking systems and data centers. 

Google takes a workload-optimized approach to building its infrastructure, employing a combination of dedicated hardware and software components to meet its workloads’ ever-growing demands. Underpinning this infrastructure is Titanium, a system of purpose-built, custom silicon and multiple tiers of scale-out offloads that together power improvements in the performance, reliability, and security of our customers’ workloads (for example, 25% faster block storage IOPS/instance compared to the other two leading hyperscalers). Unveiled today at Google Cloud Next, you’ll find Titanium technology in many of Google Cloud’s recent infrastructure offerings.

10x demands of tomorrow 

Meeting the growing performance, reliability, and security demands of both legacy and emerging workloads is a constant challenge for cloud infrastructure providers. And now, these demands are multiplying with the heightened adoption of generative AI across almost every industry. Meanwhile, the benefits of Moore’s law have been declining in recent years. We can’t rely on silicon advances alone to meet tomorrow’s needs.

As just one example, this chart shows the exponential computing demands of large language models.

It was clear to us a long time ago that we needed to rethink our infrastructure designs to meet these demands. This is why, for several years, we’ve adopted workload-optimization and intentional design as central principles for our infrastructure platform. We engineer golden paths from silicon to the customer workload, using a combination of purpose-built infrastructure, prescriptive architectures, and an open ecosystem to deliver workload-optimized infrastructure. 

Offloads play a pivotal role

Central to this strategy are offload technologies. Traditionally, the CPU wears many hats: It runs the hypervisor, the virtualization stack to enable your workloads, and manages storage and networking I/O; it’s responsible for security isolation for virtual interfaces and physical hardware, etc. In this model, customer workloads running on the CPU contend for resources with these platform tasks.

Offloads on dedicated hardware perform behind-the-scenes security, networking, and storage functions that were previously performed by the host CPU, allowing the CPU to focus on maximizing performance for customer workloads.

A recent example of an on-host offload or accelerator is the Infrastructure Processing Unit (IPU), a system-on-chip that we co-designed with Intel to enable better security isolation and performance on our 3rd gen compute instances. The IPU enables:

• Predictable and efficient compute
• Programmable packet processing for low latency, 200 Gbps networking with 3x the packets per second compared to our previous-generation compute instances
• In-transit encryption with the PSP protocol

Another important example of Google’s on-host hardware is Titan, a secure, low-power microcontroller that helps ensure that every machine in Google Cloud boots from a trusted state.

But we did not stop there. To meet tomorrow’s demands, we knew we needed to go past the performance that could be achieved using the host’s dedicated offload hardware.

A tiered system of offloads

A key component of Titanium is its modern offload architecture, which combines capabilities whose scale and performance are well-established within Google, as well as new capabilities tailored for cloud use cases. 

Just as modern workloads scale out horizontally in the cloud, with Titanium, we’ve extended the architecture to augment on-host offloads with an additional tier of scale-out offloads that run outside the host. This system of offloads is deployed fleet-wide and dynamically adjusts to changing workload needs to continually deliver the best performance.

Example 1: Block storage
Titanium scale-out offload enables Hyperdisk block storage to deliver stellar I/O performance. Hyperdisk’s Titanium offload on the host IPU works in tandem with the Titanium scale-out offload tier that distributes I/O across Google’s massive cluster-level filesystem, Colossus.

With traditional offload architectures, higher block storage IOPS requires purchasing larger compute instances. For example, you may need to deploy a data-intensive workload on a compute instance with many more vCPUs than the workload needs just to get sufficient storage performance. This tight coupling results in wasted resources and higher costs for customers. Further, even with large instances, storage performance in the cloud may be inadequate relative to what customers are used to with on-prem storage systems.     

With our new block storage, Hyperdisk powered by Titanium, we have decoupled compute-instance size from storage performance. Hyperdisk uses a tier of offloads in our cloud fabric to offload storage I/O from the customer hosts to achieve higher storage performance even with a general-purpose VM.   

In fact, today we are announcing that Titanium-powered C3 VMs with Hyperdisk Extreme now support 500K IOPS per compute instance in preview to meet the needs of the most demanding workloads. This is 25% faster IOPS/instance compared to the other two leading hyperscalers, courtesy of the Titanium system. 

Example 2: Network routing
Virtual network routing is another example of using a second tier of scale-out offloads (“hoverboards”). With Titanium, Google’s Andromeda virtual networking stack on the IPU offload device sends all packets for which it does not have a route to Hoverboard gateways, which have forwarding information for all virtual networks. Hoverboards are standalone software switches that act as default routers for some flows.

Unlike the traditional gateway model, the control plane dynamically detects flows that exceed a specified usage threshold and programs them to be direct host-to-host flows, bypassing the hoverboards allowing hoverboards to focus on the long tail of less frequent flows. Typically, only a small subset of possible VM pairs in a network communicate with one another, so the VMs only have to store and process a small fraction of the usual network configuration on an individual VM host, improving per-server memory utilization and control-plane CPU scalability.

Titanium already powers your workloads

The Titanium journey began years ago with the component technologies described above. Many of our products already benefit from this architecture, and the newest elements of this architecture are now available with our 3rd gen Compute Engine instances such as C3 and the new Hyperdisk block storage. 

Going forward, look for the Titanium architecture to underpin all future generations of our infrastructure offerings, in the process enabling new classes of infrastructure capabilities that move well beyond the confines of a single server.