Hackensack Meridian Health (HMH) executive Mark Eimer explains how an ambitiously-timed rollout of a comprehensive suite of Google products helped the entire organization—from doctors to IT staff—achieve better security, cultivate a more equitable work environment, and ultimately, improve patient outcomes.

How does a recently merged, 17-hospital healthcare system fast-track a platform migration and hardware rollout securely and in a way that improves work for everyone, regardless of location or role? These are the questions that kept me up at night in early 2020, when the pandemic demanded a “big bang”—something our legacy laptops and operating systems couldn’t handle.

We began our work with Google in 2020 with the adoption of Chrome as our default browser. As we migrated platforms, keeping patient data safe was of the utmost importance to us, along with providing every staff member with the tools they needed to work virtually. Our staff often experienced issues accessing our web-based applications using Internet Explorer or Edge Browser, a problem that went away when we switched to Chrome. Chrome’s versatile compatibility also made it easier for my team to migrate all of our web-based operations, and Chrome’s security and manageability were key components to making this switch a huge win for the organization.

The success of this migration led us to extend our Google partnership to patient care applications—where Google’s expertise in AI and ML helps scale the use of diagnostics tools and improve other aspects of the patient journey.

Achieving security at every step 

Like so many other healthcare organizations, we’ve been concerned about ransomware attacks. This is part of why we moved to Google Workspace and distributed over 3,000 Chrome OS devices in kiosk mode in March of 2020, when many of us went remote due to the pandemic. We were very concerned about team members accessing corporate applications through home devices that were running EOL operating systems (WIN7), as well as a general lack of antivirus and encryption measures.

We were protected by the fact that Google’s software and hardware both had built-in security features that we needed to stave off sophisticated attackers. For example, Chrome OS automatically updates to the latest security update and encrypts data living outside the cloud on the hardware. These features protected us from security-related disruptions, letting us securely move a huge library of file shares and emails across thousands of accounts to Google Chrome OS in just four months.

A year later, in March 2021, we migrated the enterprise over to Google Workspace and saw an immediate reduction in spam by 30% from the inherent built-in AI/ML. This meant staff were less likely to receive (and click through) phishing attempts. My team could connect, create, and collaborate easily and securely—even as more of us were working from home and needed to access sensitive data remotely. 

Leveling the playing field

As an organization, we were surprised by how many team members didn’t have personal computers at home. We quickly decided that if we needed team members to work from home, the health network would have to supply hardware. Chromebooks’ lower price tag compared to PCs—on top of their built-in security controls—allowed us to purchase, deploy, and support that initial distribution of 3,000 Chromebooks to team members in less than three weeks, providing devices to every eligible remote employee instead of just a select few. This was vital to reaching our equitable technology goal as part of our diversity and inclusion initiative: everybody has the same tools to do good work.

When all employees have what they need to do their jobs well, we get better patient outcomes. Before we began this cloud adoption journey, patient and staff experiences were different within the hospitals and outside of them. 

Now it’s the same wherever our staff is, and we’ve seen efficiency and accessibility benefits extend to the patient side. For example, we built a web-based contact center that supports 80 locations that use Workspace and Chrome OS devices. Since customer service, admin, and providers are all on the same system, it has become a one-stop shop for patients.

Furthermore, through the Grow with Google program, we were able to provide another benefit to employees that drove our equity goals. Google trained 50 non-IT staff members—from environmental services, food and nutrition, and other non-tech areas who were interested in making a career change to IT—on the Google products we were using. They may not have thought about switching to a career in IT before the Grow with Google program came to our organization, but through this partnership, they now have that opportunity.

A strategic, long-term partner

With any large-scale rollout, the work doesn’t end once laptops are in employee hands. Google has shown their commitment to long-term collaboration as they continuously optimize their products for the unique needs of healthcare providers and go the extra mile in tailoring tools to our staff’s workflows. 

For example, on the Chrome OS side, the Google team has helped our registration desks and document centers with device integration for hardware like credit card readers and e-signature pads. They’ve also helped us meet security and privacy requirements mandated by state and federal governments around HIPAA, Medicaid, and Medicare reimbursements. Over this next year, we’ll look at a feature roadmap with Google Cloud to deliver further enhancements, iterating on the product itself to meet our needs for the present and the future.

Delivering the future of healthcare

The benefits we’ve seen around security and usability—and the ability to provide all staff with equal access to Google’s technology—are why we’re expanding our partnership with Google to both the administrative and clinical sides of HMH. In addition to further Google rollouts with corporate, next year we’re distributing Chromebooks to all 350 of our ambulatory clinics.

We’re also working with the Google professional services team to create a custom AI model that analyzes 3D mammogram images. This AI model will enable two providers to read mammograms—which adheres to international best practices but is currently rare in the US—without requiring additional time. Conducting double readings of mammograms will yield better health outcomes for our patients, such as a lower patient recall rate and an increased accuracy in detecting breast cancer.

We’re currently building the model using a variety of Google Cloud products, including Cloud Healthcare API. Once complete, this model is expected to be trained, deployed, and maintained in Google’s Vertex AI, allowing our providers to be more productive as they make clinical decisions with AI support. As the model is proven over time, we plan to make the predictive services accessible to other healthcare organizations.

With Google, we’re able to achieve a unified architecture for storing data as well as training and deploying AI models, which enable our staff to work more efficiently and securely from anywhere. While I may not be able to predict the future as accurately as AI can, I foresee our continued partnership with Google as a key part of HMH’s improved provider and patient outcomes.

Many of the world’s leading companies run on SAP—and deploying it on Google Cloud extends the benefits of SAP even further. Migrating your current SAP S/4HANA deployment to Google Cloud—whether it resides on your company’s on-premises servers or another cloud service—provides your organization with a flexible virtualized architecture that lets you scale your environment to match your workloads, so you pay only for the compute and storage capacity you need at any given moment. Google Cloud includes built-in features, such as Compute Engine live migration and automatic restart, that minimize downtime for infrastructure maintenance. And it allows you to integrate your SAP data with multiple data sources and process it using Google Cloud technology such as BigQuery to drive data analytics.

SAP server-side architecture consists of two layers: the SAP HANA database, and the Netweaver application layer. In this blog post, we’ll look at the options and steps for moving the database layer to Google Cloud as a lift and shift or rehost, a straightforward approach that entails moving your current SAP environment unchanged onto Google Cloud.

Deploying an SAP HANA system on Google Cloud

Google Cloud offers SAP-certified virtual machines (VMs) optimized for SAP products, including SAP HANA and SAP HANA Enterprise Cloud, as well as dedicated servers for SAP HANA for environments greater than 12TB. (For a complete list of VM and hardware options, visit the Certified and Supported SAP HANA Hardware Directory.)

Before proceeding with a rehost migration to Google Cloud, your current (source) environment and Google Cloud (target) environments should meet these specifications:

Prerequisites:  

• The configuration of the Google Cloud environment (i.e., VM  resources, SSD storage capacity) should be identical to that of the source environment. If the underlying hardware is different, however, you must use Option 2 for your migration, detailed below.
• Both environments should be running the same operating system (SUSE or RHEL Linux).
• The HANA version, instance number, and system ID (SID) should be identical.

• Schema names must remain the same.
• Establishing the network connection between the on-premises environment and Google Cloud will be required in this phase to support rehost of the SAP application.you can use Cloud VPN or Dedicated Interconnect. Learn more about Dedicated Interconnect and Cloud VPN.

Note: Depending on your internet connection and bandwidth requirements, we recommend using a Dedicated Interconnect over Cloud VPN for production environments. 

We offer a number of automated processes to accelerate your cloud journey. To deploy the SAP HANA system on Google Cloud, you can use the Google Cloud Deployment manager or Terraform and Ansible scripts available on GitHub with configuration file templates to define your installation. For more details, see the Google Cloud SAP HANA Planning Guide.

Note: To deploy SAP HANA on Google Cloud machine types that are certified by SAP for production, please review the Certification for SAP HANA on Google Cloud page. 

Moving an SAP HANA Database to Google Cloud

There are two different options you can use to rehost your SAP HANA database to Google Cloud, and each has pros and cons that you should consider when deciding on your approach.

Option 1: Asynchronous replication uses SAP’s built-in replication tool to provide continuous data replication from the source system (also known as the primary system) to the destination or secondary system—in this case residing on Google Cloud. It’s best for mission-critical applications for which minimum downtime is a high priority, and for large databases. In addition, the high level of automation means that the process requires less manual intervention. Here’s where you can learn more on HANA Asynchronous Replication.

Option 2: Backup and restore relies on SAP’s backup utility to create an image of the database that is then transferred to Google Cloud, where it is restored in the new environment. Downtime for this method varies by database size, so large databases may require more downtime via this method vs. asynchronous replication. It also involves more manual tasks. However, it requires fewer resources to perform, making it an attractive option for less urgent use cases. Here’s where you can learn more on SAP HANA database Backup and restore.

How to migrate the SAP HANA database to Google Cloud using Asynchronous Replication

1. Create and configure Dedicated Interconnect or Cloud VPN between the current environment and Google Cloud.
2. Set up SAP HANA asynchronous replication. You can configure system replication using SAP HANA Cockpit, SAP HANA Studio, or hdbnsutil. See Setting Up SAP HANA System Replication in the SAP HANA Administration Guide.
3. Be sure to use the same instance number and HANA SID in the template as the primary instance.
4. Configure the Google Cloud instance as the secondary node for using HANA Asynchronous replication.
5. Perform data validation once full data replication is completed to the SAP HANA database in Google Cloud. To learn more: HANA System Replication overview.  
6. Perform an SAP HANA takeover on your standby database. This switches your active system from the current primary system onto the secondary system on Google Cloud. Once the takeover command runs, the system on Google Cloud becomes the new primary system.To learn more: HANA Takeover. 

How to migrate the SAP HANA database to Google Cloud using Backup and Restore

1. Create a full backup of your SAP HANA database in your current environment.
2. Create a new storage bucket in your Google Cloud environment. Visit Creating Storage Buckets in the Google Cloud Storage documentation. 
3. Download and install gsutil onto the source environment and run it to upload the HANA backup to the Google Cloud storage bucket. To install gsutil utility on any computer or server, visit Install gsutil in the Google Cloud Storage documentation.
   Note: You can run parallel multi thread/multi processing in gsutil to copy large files more quickly.
4. Recover the HANA database on Google Cloud using SAP’s RECOVER DATABASE statement. See RECOVER DATABASE Statement (Backup and Recovery) in the SAP HANA SQL Reference Guide for SAP HANA Platform.

Note: BackInt agent is an integrated SAP interface tool used for HANA database on Google Cloud.Backint agent for SAP HANA can be used to store and retrieve backups directly from Google Cloud Storage. It is supported and certified by SAP on Google Cloud. To learn more:  SAP HANA Backint Agent on Google Cloud. 

In summary, we recommend using Asynchronous Replication (Option 1) for mission-critical applications that require the lowest downtime window. For all other applications, we recommend Backup and Restore (Option 2), as this approach requires fewer resources. It’s also a great way to implement the backup and restore functionality on Google Cloud.

A rehost migration is the most straightforward path to getting your SAP on HANA system up and running on Google Cloud. And the sooner you migrate, the sooner you can take advantage of the many benefits Google Cloud brings to your SAP solution. For more information on the different migration options please review: SAP on Google Cloud: Migration strategies. 

Learn more about deploying SAP on Google Cloud. Technical resources can be found here.

VMs and their relevance to a cloud-native future: A conversation

Last week, we published the first episode of VM End-to-End, a series of curated conversations between a “VM skeptic” and a “VM enthusiast”. Join Brian and Carter as they explore why VMs are some of Google’s most trusted and reliable offerings, and how VMs benefit companies operating at scale in the cloud. Here’s a transcript of the first episode:

Carter Morgan (VM skeptic): My team asked me to research VMs and see how they compare to other cloud-native approaches, like microservices, containers, and serverless. And to be honest with you, I am not excited about it at all. So I’ve brought in someone who is, Brian, resident VM expert. Welcome, Brian!

Brian Dorsey (VM enthusiast): Hello. I’m super happy to be here, because I am really excited about VMs.

Carter: How? See this is why I wanted to bring you here. I don’t understand how you can be so excited about VMs, already?

Brian: How can you not? It is like the best of both worlds. You’ve got a stable, reliable system you can run anything on, and you’re in the cloud, close to all of the new features, and you get new automation tooling.

Carter: See, that’s what I’m kind of skeptical about. When I think about the features of a modern system, I’m not sure that a VM can provide me with those.

Brian: Okay. Well, let’s be kind of specific there. What do you mean by a modern system?

Carter: When I think about a modern system, I think about things like modularity. I think about scalability and reliability. I want automation. I don’t want to have to do everything manually. I even think about portability and being able to move my workloads wherever they need to go. I also don’t want to implement everything by hand. I don’t want to have to do everything myself. Is that something I can get with a VM?

Brian: Yeah. Great, because I actually think we can get most of that, and I wonder, why not? Let’s go one level deeper and then we’ll come back out. In your mind, what is a VM?

Carter: Oh, you’re putting me on the spot, Brian?!

Brian: Yep.

Carter: Okay. A VM, it’s a computer, but it’s a virtualization. It’s a slice of a computer. And so, what it lets you do is it lets you run multiple operating systems on one machine, so it looks like you have multiple machines running on one physical machine.

Brian: Yep. Absolutely. And in the cloud kind of not.

Carter: Oh, what?

Brian: Yeah. So here’s why I say not. The obstructions are all there, so you’ve got memory CPU, disk, networking. And instead of from one computer, in the cloud, that’s coming from all of the computers in a data center. So the CPU is coming from a lot of machines. The networking is from the whole data center. And so, I like to think about it as instead of a slice of a computer, it’s a slice of the data center

Carter: Instead of a slice of a computer, it’s a slice of a data center. That sounds interesting. Impressive, even. But also abstract. Do you have some examples of features that you can get from a cloud VM that you can’t get from a traditional VM on one machine?

Brian: My turn to be specific. Yeah. I think one example is like bin packing. You talk about these VMs, and their different shapes. So you have one that needs a lot of CPU and another that needs a lot of memory. Maybe you’ve got a bunch of them that need a lot of CPU and they don’t fit so well in the same box without orphaning some of the memory or CPU. And if you’re running those in a whole data center, or you can basically just leave it to Google to solve that problem, you can just have whatever shape machine you want and we’ll figure out where to put it. Basically, that lets you customize your machines to exactly what you need.

Carter: Okay. That’s very interesting, because that’s a hard problem. And so, if you can just let Google handle where your workloads are going to go, that’s a good benefit. If that’s the only benefit of cloud VMs though, I’m not sure I’m sold on them over other approaches. Is there anything else we got?

Brian: Absolutely. There’s a ton of stuff we could talk about in terms of automation and other things. But I think another really concrete example is disks, and it’s kind of my favorite there, because you think about a physical disk and you read and write blocks from it, right? It’s a block device. In the data center level, those blocks could be on hundreds or thousands of different machines, and so all of them are working together to give you more reliability and make things smoother, more predictable in terms of performance. So what you get out of it is something that looks a lot like a SAN, you can take backups of disks that are running even, or if you’ve run out of space, like I think almost all of us have, you can just make the disk bigger. So, things like that.

Carter: That’s impressive, especially like you’re saying being able to run and just scale up, scale down or resize. Okay. Then another very targeted question. It’s going to sound like a dig. I don’t mean it to you. Google’s putting a lot of effort and resources into Google Kubernetes Engine (GKE). And so, is Google even still investing in VMs?

Brian: Absolutely. Where do you think these containers run? Every Kubernetes cluster is running on top of a whole bunch of VMs. And so, everything you learned about VMs applies to those clusters that you’re running. Also, another example is our managed databases, so Cloud SQL. So if you’re running Postgres or MySQL on a Cloud SQL, that’s running on VMs. And there’s a bunch of other examples, too.

Carter: I can’t get away from VMs, even if I tried, it sounds like.

Brian: Nope.

Carter: Okay. The way you’re saying that is making me think that maybe I need to rethink my idea that VMs are just old, dusty pieces of technology. So I want to be clear, definitively, are you saying that VMs have a place in a cloud-native future?

Brian: Absolutely. I want to take old and dusty and turn that into mature and reliable. Then the future part, all these things are built on top of it and we’re building new things over time. So we’ve got tools for scaling clusters of machines up and down. That’s using Kubernetes, but you can use it directly. And we keep investing and doing more and more things there. So, absolutely, part of the future as well.

Carter: Okay. Then what about if I wanted to switch to them? I’m pretty familiar with Kubernetes. It’s fairly easy to get started. What about with VM? Is it going to take me years to get started on these?

Brian: No. It’s just a computer. Basically, anything that’s already running on a computer somewhere, even if you don’t have the team who built it nearby, you can run that on a VM and in turn you can run it on a cloud VM and get a bunch of the cloud benefits as well.

Carter: All right. I must admit that you’ve swayed me a little bit. I’m still skeptical, but what you said made a lot of sense. I still have a lot of questions. I want to know about keeping costs down. I want to know how to update VMs. I have this idea in my head that they’re really slow to start and stop. Stateful data, I’m curious about that.

Brian: Awesome. How much time do you have?

Carter: All right. You know what, let’s have this convo another day, and maybe, just maybe we can agree that VMs do matter in a cloud-native future.