Over the past few years, Google Cloud has become the platform of choice for a growing number of SAP enterprise customers. That’s especially true for companies looking to migrate large and challenging SAP workloads, including those moving to S/4HANA systems as part of a cloud modernization strategy.

 Google Cloud’s Bare Metal Solution (BMS) for SAP systems plays an important role in our success with these customers. Our BMS offerings are dedicated, single-tenant systems that combine uncompromising performance with the advantages of fully managed cloud infrastructure solutions. With SAP-certified BMS offerings available in North America and Europe, we’re offering SAP customers a set of high-end infrastructure capabilities.

Cardinal Health: Building for the future

Cardinal Health, Inc. is a distributor of pharmaceuticals, a global manufacturer and distributor of medical and laboratory products, and a provider of performance and data solutions for healthcare facilities. With operations in more than 30 countries and approximately 46,500 employees, Cardinal Health is a crucial link between the clinical and operational sides of healthcare. The company serves 90% of U.S. hospitals, more than 60,000 U.S. pharmacies and more than 10,000 specialty physician offices and clinics.

Over the past several years, a series of acquisitions drove a major expansion of Cardinal Health’s business. These acquisitions also created an increasingly complex and unwieldy IT environment that included a variety of ERP systems and dozens of other legacy applications, in addition to multiple ERP instances.

Cardinal Health’s technology modernization strategy will migrate its business away from these legacy systems to a single, modern digital platform. This includes leveraging the Google Cloud Large Memory Bare Metal Solution to modernize and consolidate its SAP application architecture within its Pharma segment with a single, massively scalable SAP S/4HANA system and BigQuery to unify SAP data with a fully managed enterprise data warehouse.

Scaling up to support SAP consolidation goals

Cardinal Health’s SAP modernization effort presented significant challenges. The migration process had to take place within a very narrow window and at 100% accuracy to avoid significant financial and operational impacts. Additionally, Cardinal Health’s strategy of consolidating its pharma business onto a single SAP HANA scale-up instance, with no performance or capacity issues, would require Google Cloud to scale its SAP-certified server systems beyond their previous 12TB upper limit.

Google Cloud raised the bar with its  SAP-certified Bare Metal Solution server options—one that supports up to 672 vCPUs and 18TB of memory, and another with up to 896 vCPUs and 24TB of memory. Additionally, customers have multiple storage options, offering up to a maximum of 96TB and 400,000 IOPS per system. Both offerings, along with a high-performance storage SKU, are certified for SAP HANA online transaction processing (OLTP) and meet SAP standard sizing requirements.

Our work with Cardinal Health involved some of the first production deployments of Google Cloud Large Memory Bare Metal Solution 24TB VMs to run the company’s SAP HANA in-memory database. Cardinal Health got what it needed: modern, fully managed, and SAP-certified cloud infrastructure that can support a single, consolidated scale-up SAP HANA instance for the company’s pharma operations. Google Cloud BMS also ensures that Cardinal Health’s SAP environment can scale effortlessly to support its goals, including plans to transform and migrate 200+ million business records onto its HANA system.

In addition, Cardinal Health leveraged Google Cloud’s ability to run SAP application servers on virtualized systems alongside its SAP HANA instance running on a 24TB BMS server. This hybrid approach to SAP cloud infrastructure offered significant advantages in terms of efficiency and cost-effectiveness: Cardinal Health’s use of the BMS server played a big role in achieving significant improvements in reporting and decision-making efficiency, as well as millions in cost savings over the first five years of the effort.

On top of these quantitative improvements, Google Cloud delivered the SAP migration for Cardinal Health in a single weekend—without user impacts or business disruptions.

An even bigger future for bare metal on Google Cloud

Based on raw performance, the Google Cloud server offerings define the cutting edge for our SAP customers. In fact, SAP’s certification of our 24TB Bare Metal Solution configuration earned us a world-record SAP HANA benchmark for Intel-based servers of 892,270 SAPS. And customers that combine our BMS server and high-performance storage offerings can expect to reload even the biggest SAP HANA datasets, following a full system restart, in as little as 30 minutes—a fraction of the time required in the past for an SAP HANA “rehydration” procedure.

More SAP customers are facing the same challenges that drove Cardinal Health to embark upon its modernization efforts: rapid business growth, pressure to consolidate sprawling and often chaotic SAP environments, and SAP HANA systems that now routinely require multi-TB memory capacities to run efficiently. For Google Cloud Bare Metal Solution customers, these industry-leading benchmarks translate directly into success with real-world SAP cloud modernization and growth initiatives.

It probably won’t take long for today’s boundary-pushing 24TB Bare Metal Solution systems to become tomorrow’s mainstream SAP HANA infrastructure. What we know for sure is that Google Cloud will be ready with cutting-edge solutions for our biggest and most demanding SAP customers.

Vodafone India had a manual, labor-intensive process for determining network capabilities and reach. The company sent field operatives to every customer location to conduct a feasibility study. These feasibility studies help Vodafone determine whether they can provide connectivity and services to customers based on the infrastructure at that location.

Everyone from the IT team and end users to the field operatives doing the work recognized the need to adopt a new solution to automate the measurements. They needed a technology that was easy to use and maintain.

“Vodafone used to manually perform physical surveys for each feasibility, which is a time-consuming and labor-intensive process. Often, feasibility studies were delayed, and we missed out on opportunities to serve additional customers. With SmartFeasibility, we’ve increased our capacity 15 fold, which positively impacts our bottom line and allows us to provide better and smarter customer service.”

—Rajneesh Asthana, IT Planning and Delivery, Vodafone India

Partnering with Lepton Software (a leading global provider of location-based analytics solution) Vodafone introduced SmartFeasibility—a solution that changed the feasibility testing from a manual to an automated process. This involved a full Google geo platform solution – leveraging world class technology like maps, roads and directions.

Google Maps Platform Results

• Employees are able to access information faster with SmartFeasibility—they have data at their fingertips, rather than waiting for an employee to collect it
• Field operatives have increased their conversion rates by providing more accurate readings on feasibilities and closing more customer business
• Addresses are now easy to find with a click of a button. The Vodafone India team can search feasibilities that have been loaded into the database, so if there’s an issue or if they need to reference a past action, they have that information at their fingertips
• 2 day turnaround versus 5 before the solution was implemented
• 400+ new customers added per day

With the new solution, Vodafone India no longer needs field operatives to manually calculate these measurements. With Google Maps, users can search customers’ addresses, calculate the distance between Vodafone’s location and the customer’s location and research building data such as height.

The old system of having field operatives collect data was unreliable. With Google Maps Platform, the Vodafone India team knows that the measurements are accurate and reliable.

The concept of “shifting left” has been widely promoted in the software development lifecycle. The concept is that introducing security earlier, or leftwards, in the development process will lead to fewer software-related security defects later, or rightwards, in production.

Shifting cloud security left can help identify potential misconfigurations earlier in the development cycle, which if unresolved can lead to security defects. Catching those misconfigurations early can improve the security posture of production deployments.

Why shifting security left matters

Google’s DevOps Research and Assessment (DORA) highlights the importance of integrating security into DevOps in the 2016 State of DevOps Report. The report discussed the placement of security testing in the software development lifecycle. The survey found that most security testing and tool usage happened after the development of a release, rather than continuously throughout the development lifecycle. This led to increased costs and friction because remediating problems found in testing may involve big architectural changes and additional integration testing, as shown in Figure 1. For example, security defects in production can lead to GDPR violations, which can carry fines up to 4% of global annual revenue.

By inserting security testing into the development phase, we can identify security defects earlier and perform the appropriate remediation sooner. This results in fewer defects post-production and reduces remediation efforts and architectural changes. Figure 2 shows us that integrating security earlier in the SDLC results in overall decreases in security defects and associated remediation costs.

The 2021 State of DevOps Report expands the work of the 2016 report and advocates for integrating automated testing throughout the software development lifecycle. Automated testing is useful for continuously testing development code without the need for additional skills or intervention by the developer. Developers can continue to iterate quickly while other stakeholders can be confident that common defects are being identified and remediated.

From code to cloud

The DORA findings with regard to code security can also be applied to cloud infrastructure security. As more organizations deploy their workloads to the cloud, it’s important to test the security and configurations of cloud infrastructure. Misconfigurations in cloud resources can lead toward security incidents that could lead to data theft. Examples of such misconfigurations include overly permissive firewall rules, public IP addresses for VMs, or excessive Identity and Access Management (IAM) permissions on service accounts and storage buckets.

We can and should leverage different Google Cloud services to identify these misconfigurations early in the development process and prevent such errors from emerging in production to reduce the costs of future remediation, potential legal fines, and compromised customer trust.

The key tools in our toolshed are Security Command Center and Cloud Build. Security Command Center provides visibility into misconfigurations, vulnerabilities, and threats within a Google Cloud organization. This information is critical when protecting your cloud infrastructure (such as virtual machines, containers, web applications) against threats, or identifying potential gaps from compliance frameworks (such as CIS Benchmarks, PCI-DSS, NIST 800-53, or ISO 27001.

Security Command Center further supports shifting security left by allowing visibility of security findings at the cloud project level for individual developers, while still allowing global visibility for Security Operations. Cloud Build provides for the creation of cloud-native CI/CD pipelines. You can insert custom health checks into a pipeline to evaluate certain conditions (such as security metrics) and fail the pipeline when irregularities are detected. We will now explore two use cases that take advantage of these tools.

Security Health Checker

Security Health Checker continuously monitors the security health of a Google Cloud project and promptly notifies project members of security findings. Figure 3 shows developers interacting with a Google Cloud environment with network, compute, and database components. Security Command Center is configured to monitor the health of the project.

When Security Command Center identifies findings, it sends them to a Cloud Pub/Sub topic. A Cloud Function then takes the findings published to that topic and sends them to a Slack channel monitored by infrastructure developers. Just like a spell checker providing quick feedback on misspellings, Security Health Checker provides prompt feedback on security misconfigurations in a Google Cloud project that could lead to deployment failures or post-production compromises. No additional effort is required on the part of developers.

Security Pipeline Checker

In addition to using Security Command Center for timely notification of security concerns during the development process, we can also integrate security checks into the CI/CD pipeline by using Security Command Center along with Cloud Build as shown in Figure 4.

The pipeline begins with a developer checking code into a git repository. This repository is mirrored to Cloud Source Repositories. A build trigger will begin the build process. The build pipeline will include a short waiting period of a few minutes to give Security Command Center a chance to identify security vulnerabilities. A brief delay may appear undesirable at first, but the analysis that takes place during that interval can result in the reduction of security defects post-production.

At the end of the waiting period, a Cloud Function serving as a Security Health Checker will evaluate the findings from Security Command Center (Connector 1 in Figure 4). If the validator determines that unacceptable security findings exist, the validator will inject a failure indication into the pipeline to terminate the build process (Connector 2 in Figure 4). Developers have visibility into the failure triggers and remediate them before successfully deploying code to production. This is in contrast to the findings in the 2016 State of DevOps Report wherein organizations that didn’t integrate security into their DevOps processes spent 50% more time remediating security issues than those who “shifted left” on security.

Closing thoughts

DORA’s 2016 State of DevOps report called out the need for “shifting left” with security, introducing security earlier in the development process to identify security vulnerabilities early to reduce mitigation efforts post-production. The report also advocated for automated testing throughout the software development lifecycle.

We looked at two ways of achieving these objectives in Google Cloud. The Security Health Checker provides feedback to developers using Security Command Center and Slack to notify developers of security findings as they pursue their development activities. The Security Pipeline Checker uses Security Command Center as part of a Cloud Build pipeline to terminate a build pipeline if vulnerabilities are identified during the build process. To implement the Security Heath Checker and the Security Pipeline Checker, check out the GitHub repository. We hope these examples will help you to “shift left” using Google Cloud services. Happy coding!

This article was co-authored with Jason Bisson, Bakh Inamov, Jeff Levne, Lanre Ogunmola, Luis Urena, and Holly Willey, Security & Compliance Specialists at Google Cloud.