Getting started with Kubernetes is often harder than it needs to be. While working with a cluster “from scratch” can be a great learning exercise or a good solution for some highly specialized workloads, often the details of cluster management can be made easier by utilizing a managed service offering. Google Kubernetes Engine (GKE) allows for an easier end-to-end developer experience with convenient tooling and built-in integrations along with the convenience of offering Kubernetes clusters as a managed service.

GKE is the most mature container orchestration service available today, delivering a fully-managed service and hands-off experience with the GKE Autopilot mode of operation. GKE provides industry-first capabilities such as release channels, multi-cluster support, unique four-way auto scaling, node auto repair, and can support up to 15K nodes in a single cluster. 

Our modern, end-to-end platform is built on cloud-native principles you are already familiar with and prioritizes speed, security, and flexibility, in ways that are highly differentiated from other cloud platforms. 

We have put together a new reference guide for you as you begin your journey developing on GKE. It covers every step of your journey from writing, running, operating, to managing code. Even if it isn’t your first time using GKE, this e-book will be a valuable resource highlighting important considerations and best practices. By implementing the technical recommendations, following the steps, and utilizing the tools described, you can reach the following goals:

• Write, deploy, and debug code faster with Cloud Code and Cloud Shell
• Continuously integrate and deliver updates with Cloud Build
• Run easily, securly, cost effectively at scale with GKE
• Monitor and troubleshoot with Google Cloud’s operations suite 

Kick-start your journey by downloading the e-book and join us live June 22 at 9am PDT for our half-day Cloud OnBoard event: Getting Started with Google Kubernetes Engine. 

At Google I/O 2021, we announced the beta release of Tilt and Rotation, and Webgl Overlay View, which give you a fundamentally new way to build mapping experiences. You may be familiar with the existing Overlay View feature of the Maps JavaScript API that lets you render in a transparent layer that sits on top of the map. For years, developers have been using Overlay View to draw in two dimensions over the top of the map, but for as much as you can do with Overlay View, it only allows you to render on a transparent layer that effectively floats above the map.

In contrast, WebGL Overlay View gives you direct hooks into the lifecycle of the exact same WebGL rendering context we use to render the vector basemap. This means that for the first time ever, you can performantly render two and three dimensional objects directly on the map, enabling you to build experiences that were previously impossible with the Maps JavaScript API.https://www.youtube.com/embed/9eycQLef6iU?enablejsapi=1&

Today, we’re going to give you a quick overview of the new WebGL-powered features of the Maps JavaScript API, so that you have all the knowledge you need to get started creating next generation mapping experiences.

What is WebGL?

WebGL is a low-level browser API, originally authored by the Mozilla Foundation, that gives you access to the rendering and processing power of the graphics processing unit (GPU) on client devices, such as mobile phones and computers, in your web apps. On its own, the browser is not able to handle the heavy computation needed to render objects in 3D space, but using WebGL it is able to pass those processes off to be handled by the GPU, which is purpose built to handle such computations.

To learn more about WebGL, check out the documentation from the Khronos Group, the designers and maintainers of WebGL.

Requirements

To use WebGL Overlay View, you’ll need a Map ID with the vector map enabled. It’s also strongly recommended that you enable Tilt and Rotation when you create your Map ID, otherwise your map will be constrained to the default top-down view – in short, you won’t be able to move your map in three-dimensions. 

To learn more about using Map IDs and the vector map, see the documentation.

Setting Tilt and Rotation

To load your map with a set tilt and rotation, you can provide a value for the `tilt` and `heading` properties when you create the map:

  const mapOptions = {
  mapId: "15431d2b469f209e",
  tilt: 0,
  heading: 0,
  zoom: 17,
  center: {
    lat: -33.86957547870852, 
    lng: 151.20832318199652
  }
}
const mapDiv = document.getElementById("map");
const map = new google.maps.Map(mapDiv, mapOptions);

Tilt is specified as a number or float in degrees between 0 and 67.5, with 0 degrees being the default straight down view and 67.5 being the maximum tilt. The available  maximum tilt also varies by zoom level. 

The rotation is set in the heading property as a number or float between 0 and 360 degrees, where 0 is true north.

You can also change the tilt and rotation programmatically at runtime whenever you want by calling `setTilt` and `setHeading` directly on the map object. This is useful if you want to change the orientation of the map in response to events like user interactions.

  map.setTilt(45);
map.setHeading(180);

In addition, your users can manually control the tilt and rotation of the map by holding the <shift> key and dragging with the mouse or using the arrow keys.

For more information on Tilt and Rotation, see the documentation.

Adding WebGL Overlay View to the Map

WebGL Overlay View is made available in the Maps JavaScript API by creating an instance of `google.maps.WebglOverlayView`. Once an instance of the overlay is created, you simply need to call `setMap` on the instance to apply it to the map.

  const webglOverlayView = new google.maps.WebglOverlayView;
webglOverlayView.setMap(map);

To give you access to the WebGL rendering context of the map and handle any objects you want to render there, WebGL Overlay View exposes a set of five hooks into the lifecycle of the WebGL rendering context of the vector basemap.

Here’s a quick rundown:

• `onAdd` is where most of your pre-processing should be done, like fetching and creating intermediate data structures to eventually pass to the overlay. The reason to do all of that here is to ensure you don’t bog down the rendering of the map.
• `onRemove` is where you’ll want to destroy all intermediate objects, though it would be nice if you did it sooner.
• `onContextRestored` is called before the map is rendered and is where you should initialize, bind, reinitialize or rebind any WebGL state, such as shaders, GL buffer objects, etc.
• `onDraw` is where we actually render the map, as well as anything that you specify in this hook. You should try to execute the minimal set of draw calls to render your scene. If you try to do too much here you’ll bog down both the rendering of the basemap and anything you’re trying to do with WebGL, and trust me, no one wants that.
• `onContextLost` is where you’ll want to clean up any state associated with pre-existing GL state, since at this point the WebGL context will have been destroyed, so it’ll be garbage.

To implement these hooks, set them to a function, which the Maps JavaScript API will execute at the appropriate time in the WebGL rendering context lifecycle. For example:

  webglOverlayView.onDraw = (gl,
coordinateTransformer) => { //do some
rendering }

For more information on using WebGL Overlay View and its lifecycle hooks, check out the documentation.

Creating Camera Animations

As part of the beta release of WebGL Overlay View, we’re also introducing `moveCamera`, a new integrated camera control that you can use to set the position, tilt, rotation, and zoom of the camera position simultaneously. Like `setTilt` and `setHeading`, `moveCamera` is called directly on the `Map` object.

By making successive calls to `moveCamera` in an animation loop you can also create smooth animations between camera positions. For example, here we are using the browser’s `requestAnimationFrame` API to change the tilt and rotation each frame:

  const cameraOptions = {
  tilt: 0,
  heading: 0
}
function animateCamera () {
  cameraOptions.tilt += 1;
  cameraOptions.heading += 1;
  map.moveCamera(cameraOptions);
}
requestAnimationFrame(animateCamera);

Plus, all of these adjustments, including zoom, support floats, which means not only can you control the camera like never before, you can also do it with a high degree of precision.

For more information on `moveCamera`, see the documentation.

Give it a tryYou can try the new WebGL-powered features of the Maps JavaScript API right now by loading the API from the beta channel. We’ve got a new codelab, and documentation with all the details, as well as sample code and end-to-end example apps to help you get started. Also, be sure to check out our feature tour and travel demos to learn more and play with a real implementation of these features.

And let us know what you think by reporting through our issue tracker. We need your bug reports, your feature requests, and your feedback to help us test and improve the new WebGL-based map features. 

Have fun building with the map in 3D—we can’t wait to see the amazing things you’ll build.
For more information on Google Maps Platform, visit our website.

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.

Editor’s note: Today we hear from the Lowe’s SRE team. They share about how they have been able to increase the number of releases they can support by adopting Google’s Site Reliability Engineering (SRE) framework and leveraging their partnership with Google Cloud. 

At Lowe’s, we’ve made significant progress in our multiyear technology transformation. To modernize our systems and build new capabilities for our customers and associates, we leverage Google’s SRE framework and Google Cloud, which helps us meet their needs faster and more effectively. With these efforts, we’ve been able to go from one release every two weeks to 20+ releases daily—about 20X more releases per month. 

Our SRE transformation didn’t happen overnight, though. Every step along the way brought some challenges. But looking back, we are excited to see how much we have accomplished for our customers as a result. 

Back in 2018, before adopting SRE practices, we were more reactive than proactive, following an “eyes on glass” approach. On-call structures and incident management efficiency were not at optimal levels with too many repetitive and manual tasks, resulting in operational toil. Production concerns were not surfaced into the product roadmap, which resulted in delays in making fixes.

Bootstrapping SRE at Lowe’s

As we moved from on-prem to Google Cloud, we decided to move from a monolithic- to microservices-based architecture. And to better manage this new architecture, we embarked on an SRE journey. 

Then as COVID-19 hit, we really had to accelerate this journey as customers increasingly moved to online ordering and delivery to meet their Total Home Improvement needs. To do so, we followed four key principles that allowed us to meet changing customer needs quickly and release fast and reliably.

1. Automate away toil 
   As we moved from traditional Ops to an SRE ecosystem, our biggest opportunity was reducing toil, so that engineers can spend time on activities that drive business impact and customer outcomes. We think of toil as work that is manual, repetitive,  tactical, devoid of enduring value—but automatable. So, to tackle toil, we focused on automating away the need for manual intervention. As an example, we made sure engineers were not the first point of contact for any alert. Any triage or resolution that an engineer can perform, a machine can be trained to do the same. We used supervised and unsupervised learning techniques to automate our toil. With a long-term goal of “no toil,” our SREs work on identifying and reducing toil to a manageable level across the organization.
2. Engineer alignment through roadmaps
   Our goal is to maximize the engineering velocity of developer teams while keeping products reliable. We want an engagement model where product, SRE and development teams are closely aligned. A key way we’ve been able to create this alignment is by having our SREs embedded into domain and product teams. Each domain has an SRE, who is  involved at the beginning stages of product development to ensure that the domain stakeholders are in alignment with the SRE initiatives. As such, SREs are able to improve the reliability, performance, scalability and launch velocity of the services throughout all phases of the service lifecycle. 
3. Adopt one-touch releases
   Our path to production used to contain many manual steps and validations, slowing the rate at which we released features. Additionally, we used to bulk all our releases together to deploy at once, which increased the risk of failure and created a longer feedback loop from production. To tackle this with an SRE mindset, we created a one-touch release process in which SREs review the product team’s pull requests. When approved, this triggers a DevSecOps pipeline that deploys the approved changes to production securely. This process created a safe, reliable and sustainable continuous delivery pipeline with quick feedback loops. Striking the right balance between speed, innovation and stability, we were able to increase our releases exponentially for the year, taking less than 30 minutes per release to deliver quality code, including various automated quality checks and processes, all in just one click. 
4. Embrace capacity planning
   To ensure our services have enough spare capacity to handle any surge in traffic patterns, our SREs emphasize capacity planning, making recommended capacity changes in the continuous delivery (CD) pipeline. They constantly monitor performance to make sure the service is robust, stable and available. And when there’s a sudden surge beyond the forecasted volume, SREs change the capacity on demand and document changes for the performance and domain teams. 

Capacity planning is especially important for us during peak holiday times such as Black Friday and Cyber Monday (BFCM). We lay out our SRE stability plan three months in advance and surface into the domain team’s product roadmap. This way development teams are able to allocate sufficient engineering time to reliability. We do performance testing to ensure the environment is able to sustain increased load over long periods of time and also handle sudden surges in traffic. We also do region failover testing at a global scale to validate the automatic failover duration of service level agreements  (SLAs), SRE and domain readiness. Additionally, we conduct Black Friday and Cyber Monday-specific destructive testing to validate customer experience, reliability and more.

Google Cloud’s Black Friday and Cyber Monday white-glove service played a key role in ensuring our success in both BFCM 2019 and BFCM 2020. This service included on-site visits from Google’s Customer Reliability Engineering (CRE) team who reviewed Lowe’s web architecture, capacity planning, operations practices for event risks, and presented workshops on topics such as incident response best practices. 

Looking ahead

There is always room for improvement, and at Lowe’s we aim to continuously improve our SRE practices. One thing that has worked well for us, which we plan to continue, has been our road shows, where senior SRE leads present to other SREs and application domain teams on the latest SRE principles and best practices, and to get input in real-time from them. 

Google’s tools and methodology have played an instrumental role in helping reshape our SRE practices and better serve our customers. We look forward to building on the momentum and partnership as we continue our SRE journey at Lowe’s. 

If you want to learn more about how to adopt SRE best practices on Google Cloud, check out our documentation. If you want to learn more about Google SRE, visit our website. Stay tuned for the next blogs with Lowe’s discussing how they trained their engineering talent to adopt SRE practices and tooling, and how they improved MTTR using SRE principles.