The COVID-19 pandemic brought dramatic changes to the financial services industry. Already under pressure from nimble young fintechs to modernize, established banks and insurers were undergoing incremental digital transformation. But in 2020, they hit the gas pedal. Branches closed and remote work became the norm. Almost overnight, employees needed secure remote access to corporate systems, and customers expected to be able to complete even complex transactions whenever they wanted, on whatever device. Even as things return to normal, many of these shifts are likely to be permanent. According to Forrester Research, nearly 90% of global financial services CIOs and SVPs believe that improving their application portfolio is key to improving customer experience and driving revenue.¹ The problem? Replacing legacy systems with cloud-based SaaS enterprise software is a massive, time- and resource-intensive process. 

IDG’s recently completed white paper, Financial Services Spotlight: Elevating agility and security in the cloud, highlights an alternative to the all-or-nothing approach to replatforming: “lifting and shifting” on-premises applications and workloads to the cloud without rewriting them. In this way, you keep your organization’s familiar architecture, but give it the scalability and cutting-edge technology of a modern cloud environment. That’s the promise of Google Cloud VMware Engine brings to the financial services industry.

Here’s a quick overview of the insights that the IDG study uncovers. Download the complete white paper.

Simpler migration, rich rewards

Google Cloud VMware Engine helps financial services companies seamlessly migrate and run 

VMware workloads natively on Google Cloud. Once in the cloud, firms can take advantage of Google Cloud services, access a robust third-party cloud ecosystem, and use the same VMware tools, processes, and policies their teams already know. The IDG study found that migrating to Google Cloud with Google Cloud VMware Engine offers multiple benefits:

1. Create new customer experiences. Migrating to Google Cloud puts modern, cloud-native architectures and technologies — such as containers and microservices — easily within reach. These make it possible for financial institutions to quickly and securely launch new applications and update them on a continuous basis using DevOps pipelines. They also allow firms to craft more personalized customer experiences across channels using Google Cloud’s native AI and data analytics.
2. Deliver new services. After migrating, financial services organizations can connect to multiple third-party service providers via cloud-based APIs to bring new, diverse services to their customers — without having to build from scratch. 
3. Make the best use of IT resources. When your data and applications reside in Google Cloud, you’re no longer constrained by the physical storage and compute limits of on-premises infrastructure. This means your company can match capacity to demand — even during unexpected peaks. You also gain more visibility into your hybrid cloud environment with Google Cloud’s operations suite, which offers intelligent analysis and easier troubleshooting for your platform and applications.
4. Gain fresh insights. The key to understanding what customers need and when they need it resides within your data, and data analytics in the cloud help you uncover those insights. Your company can connect to Google Cloud’s serverless data warehouse, BigQuery, which leverages data to deliver valuable insights for personalized customer experiences, rich compliance reporting, new product development, intelligent fraud detection, and more. 
5. Choose what to move. Data governance regulations and requirements specific to the financial services industry mean that some data must remain on premises. Google Cloud VMware Engine lets you easily manage a hybrid cloud/on-premises environment to keep sensitive data fully under your control.
6. Become more resilient. Google Cloud VMware Engine gives financial services firms a distributed architecture and centralized control for their applications to support vital business continuity functions, such as backup and disaster recovery. This is on top of the performance and availability of Google Cloud’s global infrastructure.
7. Improve security. Using cloud-native application frameworks, administrators can issue patches and software updates centrally and automatically across their organizations. This reduces the risk of errors and security vulnerabilities. Firms also tap into the security features and capabilities of Google Cloud, including always-on encryption and AI-powered threat detection.
8. Redirect IT resources. Migrating virtualized workloads to the cloud can free up talent and budget to develop new products and services — time that was previously spent on maintaining complex on-premises infrastructure. That means less effort spent keeping the lights on, and more resources directed toward creating innovative and differentiating customer experiences.

IDG research concluded that migrating business applications to Google Cloud with Google Cloud VMware Engine can help financial services companies stay ahead of change without incurring further technical debt from their legacy IT systems. Working with cloud-based systems can give your financial services company much of the scale, speed, and agility of a startup while still enjoying the benefits of being an established organization.

Read the complete white paper to learn more about the ways in which Google and VMware work together to accelerate digital transformation for financial services firms.

^{1. Vmware-forrester-financial-services-modern-app-report.pdf, A commissioned study conducted by Forrester Consulting on behalf of VMware, 2020}

Over the past year, RISE with SAP has emerged as a valuable solution for SAP customers seeking a faster, simpler, and more affordable path to the cloud. RISE with SAP is a subscription-based offering that typically includes a number of fully managed cloud application options, including SAP S/4HANA Cloud and elements of the SAP Business Technology Platform. It’s a great way to migrate your business to modern cloud ERP applications, while handing off the implementation and management to SAP and freeing your own IT staff to focus on other projects.

As a strategic partner for RISE with SAP, Google Cloud works closely with SAP to ensure reliable, secure, high-performance connectivity between your SAP managed applications and your other Google Cloud applications and services. Today, we’re focusing on a Google Cloud capability that plays a big part in achieving this goal: VPC network peering. If your company uses Google Cloud to host its RISE with SAP managed applications (or any other SAP-managed offering, such as SAP Enterprise Cloud Services), it’s worth learning more about why VPC network peering is an important capability and how your network admin can implement it.

VPC network peering: The critical link for your SAP managed applications

We recently co-authored a white paper with SAP that goes into technical detail about how VPC network peering works and includes step-by-step configuration instructions. But it is useful to understand, at a higher level, why it matters for RISE with SAP subscribers.

When SAP implements your RISE with SAP managed applications on Google Cloud, it also provisions a virtual private cloud (VPC) — a virtualized network that provides the same functionality, performance, and security benefits as a dedicated physical network — for this SAP environment. In fact, a VPC actually gives you some capabilities that a physical network can’t match, such as the ability to increase IP space without downtime.

Using VPC network peering to connect your SAP managed environment with your Google Cloud applications and services gives you three key benefits: 

• Network latency: Traffic that remains inside Google’s network enjoys lower latency than connectivity that uses external addresses.
• Network security: Service owners do not need to have their services exposed to the public internet and deal with its associated risks.
• Network cost: Rather than pay egress bandwidth costs for networks using external IPs to communicate, peered networks can use internal IPs to communicate, saving you money on those egress costs. Regular network pricing still applies to all traffic.

Many customers also appreciate the flexibility they get from VPC network peering: It supports the ability to peer your own VPC networks with other VPC networks that reside in different projects and even in different organizations.  

Using VPC network peering to strengthen your SAP security posture

Most Google Cloud customers find VPC network peering most useful to ensure seamless connectivity between their SAP managed applications and the rest of their Google Cloud environment. But some companies also rely on VPC network peering to gain greater control over the security of their cloud environments. This can include:

• Implementing additional network security capabilities, such as advanced firewalls, intrusion detection, and network package inspection, that go above and beyond standard SAP security measures.
• Leveraging Google Cloud Interconnect to link your on-premises and Google Cloud environments, including your RISE with SAP managed applications, without sending traffic across the public internet.

Once your company has configured VPC network peering, things get even more interesting. Google Cloud offers plenty of ways to complement and enhance the value of your SAP applications: using Google BigQuery to consolidate and enrich your SAP application data; relying on Google AI/ML capabilities to sharpen your predictive analytics and real-time decision-making; or leveraging Google Kubernetes Engine to jump-start your own cloud-native application development efforts, among many other examples. 

Some of the world’s biggest SAP customers, including The Home Depot, and Cardinal Health,  have chosen Google Cloud to migrate their business-critical SAP applications. And we’ve seen how useful VPC network peering can be for SAP customers to unlock the full value and potential of Google Cloud. Be sure to download our white paper so you can get VPC network peering configured for your RISE with SAP managed applications, and discover for yourself just what’s possible when you run SAP applications on Google Cloud.

Traditionally, dedicated game servers for real time multiplayer games have used bespoke UDP protocols for communication and synchronization of gameplay among the players within a game. This communication is most often bundled into monolithic game servers and clients, pairing the technical functionality of communication protocols, such as custom network physics synchronisation, security, access control, telemetry and metrics, with the extremely high computational requirements of physics simulations, AI computation and more.

Developed in collaboration with Embark Studios, Quilkin is a UDP proxy, tailor-made for high performance real-time multiplayer games. Its aim is twofold:

1. Pull common functionality, such as security, access control, telemetry and metrics out of monolithic dedicated game servers and clients.
2. Provide this common functionality in a composable and configurable way, such that it can be reused across a wide set of multiplayer games.

This reusable foundation then allows game developers to spend more of their time focusing on building the game-specific aspects of building their multiplayer communication protocols, rather than these common aspects.

Challenges with multiplayer Game Server communication

In fast-paced, multiplayer games, the full simulation of a session of gameplay generally occurs within the memory of a monolithic dedicated game server, whose responsibility covers everything from network physics and AI simulation to communications from client back to server and more.

Since the entire state of the game is memory resident, each client connects directly to the dedicated game server the player is playing on, which presents several challenges:

• Each dedicated game server is a single point of failure. If it goes down, then the whole game session (or sometimes multiple sessions) fails. This makes it a target for malicious actors.
• The IP and port of connection to the game server is public, and exposed to the game client, making it easy to discover and target.
• Multiple aspects of game server simulation and network communication are tightly coupled in the same process, making reuse and modularity more difficult, and expanding risk of performance issues.

If we look at both web and mobile technologies over the past several years, some of these challenges start to look very familiar. Thankfully, one of the solutions to help drive dedicated server workloads to more redundant and distributed orchestration is the utilisation of traffic proxies!

By using a proxy for multiplayer UDP traffic, in front of our dedicated games servers within a low latency network such as what is available on Google Cloud, we can address these key challenges as follows:

• Greater reliability. Proxies provide redundant points of communication entry. UDP packets can be sent to any number of proxies and routed to the dedicated game server. While a dedicated game server will still generally be a single point of failure, proxies improve redundancy and potential failover at the communication layer.
• Greater security. The IP and port of the dedicated game server is no longer public. Game clients may only have visibility into a subset of the proxy pool, limiting a potential attack surface.
• Greater scalability. We start to break apart the single process, as we can move aspects of the communication protocol, metrics, communication security and access control into the proxy. This removes the non-game specific computation out of your game server’s processing loop.

As a result, the entire system is now more resilient as proxies can be scaled independently, not only for performance reasons but also to distribute load in case of malicious actors.

Introducing Quilkin: The UDP proxy for Game Servers

Embark Studios and Google Cloud came together and built Quilkin, to provide a standard, open source solution.  Based out of Stockholm, Embark Studios is a (relatively) new studio made up of seasoned industry veterans.  They were the perfect collaboration partner to create Quilkin with, given their team’s experience with large scale real time multiplayer games.  

Quilkin is an open-source, non-transparent UDP proxy specifically designed for use with large scale multiplayer dedicated game server deployments, to ensure security, access control, telemetry data, metrics and more.

Quilkin is designed to be used behind game clients as well as in front of dedicated game servers, and offers the following major benefits:

• Obfuscation. Non-transparent proxying of UDP data, making the internal state of your game architecture less visible to bad actors.
• Out of the box metrics. For UDP packet traffic and communication.
• Visibility. A composable set of processing filters that can be applied for routing, access control, rate limiting, and more.
• Flexibility. Ability to to be utilised as a standalone binary, with no client/server changes required or as a Rust library, depending on how deep an integration you wish for your system and/or custom processing Filters you wish to build.
• Compatibility. Can be integrated with existing C/C++ code bases via Rust FFI, if required.
• Onboarding. Multiple integration patterns, allowing you to choose the level of integration that makes sense for your architecture and existing platform.

Until now, these sorts of capabilities are only available to large game studios with resources to build their own proprietary technology. 

We think leveling the playing field for everyone in the games industry is an important and worthy endeavor. That’s why we collaborated with Google Cloud and initiated this project together.

At Embark, we believe open source is the future of the games industry and that open, cross-company collaboration is the way forward, so that all studios, regardless of size, are able to achieve the same level of technical capabilities. —Luna Duclos, Tech Lead, Embark Studios

Google Cloud is excited to announce Quilkin as the latest entry in our portfolio of open-source solutions for gaming.  Quilkin complements our existing OSS solutions including Agones for game servers, Open Match for matchmaking, and Open Saves for persistence.  These are designed to work together as an open and integrated ecosystem for gaming.  We’re proud to include Embark Studios as our latest open source collaborator for gaming along with Ubisoft, Unity, and 2K Games.  Google Cloud will continue to work closely with our partners in industry and the community to offer planet-scale solutions to power the world’s largest games. —Rob Martin, Chief Architect, Google Cloud for Games

Getting started with Quilkin

While Quilkin can support more advanced deployment scenarios like above, the easiest way to get started with Quilkin is to deploy it as a sidecar to your existing dedicated game server. This may initially limit some of the benefits, but it’s an easy path to getting metrics and telemetry data about your UDP communication, with a very low barrier to entry and the ability to expand over time.

While Quilkin is released as both binaries and container images, and is not tied to any specific hosting platform, we’ll use Agones and Google Cloud Game Servers as our game server hosting platform for this example.

First we will create a ConfigMap to store the yaml for a static configuration for Quilkin that will accept connections on port 26001 and route then to the Xonotic (an open source, multiplayer FPS game) dedicated game server on port 26000:

  apiVersion: v1
kind: ConfigMap
metadata:
  name: quilkin-config
data:
  quilkin.yaml: |  # quilkin configuration
    version: v1alpha1
    proxy:
      port: 26001
    static:
      endpoints:
        - address: 127.0.0.1:26000

Second, we’ll take the example container that Agones provides for the Xonotic dedicated game server, and  run Quilkin alongside each dedicated game server as a sidecar, in an Agones Fleet of game servers like so:

  apiVersion: "agones.dev/v1"
kind: Fleet
metadata:
  name: xonotic-sidecar
spec:
  replicas: 2
  template:
    spec:
      container: xonotic
      ports:
        - name: default
          containerPort: 26001
          container: quilkin
      health:
        initialDelaySeconds: 30
        periodSeconds: 60
      template:
        spec:
          containers:
            - name: xonotic
              image: gcr.io/agones-images/xonotic-example:0.8
            - name: quilkin  # quilkin sidecar
              image: us-docker.pkg.dev/quilkin/release/quilkin:0.1.0
              volumeMounts:
                - name: config
                  mountPath: "/etc/quilkin"
              livenessProbe:
                httpGet:
                  path: /live
                  port: 9091
                initialDelaySeconds: 3
                periodSeconds: 2
          volumes:
            - name: config
              configMap:
                name: quilkin-config

Once applied, when we query the cluster for the running GameServers, everything looks the same as it would without Quilkin! Nothing else in our system needs to be aware that the traffic is being intercepted, and we can freely take advantage of the functionality of Quilkin without adjusting either client or server code.

  $ kubectl get gameservers
NAME                          STATE   ADDRESS         PORT   NODE           AGE
xonotic-sidecar-gdpgn-2pfkc   Ready   34.95.106.201   7929   gke-0f7d8adc   25m
xonotic-sidecar-gdpgn-c8bds   Ready   34.95.106.201   7028   gke-0f7d8adc   25m

If this has piqued your interest, make sure to have a look at the walkthrough, where we step through this same scenario and then extend it to compress UDP packets from the game client to server, without having to change either programs.

This just scratches the surface, however: there’s even more to Quilkin, including an xDS compliant admin API, a variety of existing Filters to manipulate and route UDP packets and more.

What’s next for Quilkin

Quilkin is still in its early stages, with this 0.1.0 alpha release, but we’re very happy with the foundation that has been laid.

There are a variety of features in the roadmap, from enhanced metrics and telemetry, new filters and filter types, and more.

If you would like to try out this release, you can grab the binaries or container images from our releases page, step through our quickstarts and review different integration options with your dedicated game servers.

To get involved with the project, please:

• Check out our Github repository
• Join our Discord community
• Join the quilkin-discuss mailing list
• Follow us on Twitter

Embark Studios has also released their own announcement blog post, going deeper into the plans they have for their own production game backend infrastructure, and where Quilkin fits in.

^{Thanks to everyone who has been involved with this project across Google Cloud and Embark Studios, and we look forward to the future for Quilkin!}

Working to put food on all of our tables, today’s farmers are facing a higher amount of instability from input supply chain issues to weather patterns. Adding to this challenge are problems farmers face when trying to correctly time grain purchases, sales and transport. Farmers have always been stewards of the land, but now the demand for sustainable products has them needing to better prove their regenerative practices.

At Bushel, we understand these problems can’t be solved overnight or by a single company. We focus on empowering agribusinesses and farmers to work even more closely together to build a more sustainable agricultural supply chain by rapidly responding to market changes. With Bushel, farmers can track market prices in real time, instantly buy and sell grain, analyze inventory and transactions, and securely share verified information with grain operators and other producers. We provide the digital tools to streamline how farmers buy and sell commodities throughout the agricultural industry’s supply chain to help address market inefficiencies that can lead to waste, and have the information and resources to help them flex and adapt as complexity increases in farming operations.

Approximately 40% to 50% of all U.S. grain transactions now pass through the Bushel platform. As we continue to grow, Bushel continues to focus on what digital tEmpowering Farmers: Bushel Drives 40-50% of US Grain Transactions, Fueling Sustainable Agricultureools can support each point in the supply chain. Many focus on the first mile at the farm or last mile at the store. But Bushel is focused on modernizing the middle where grain purchasing and processing sit. We aim to help local grain industries and stabilize regional agricultural supply chains.

Starting with a simple mobile app; now scaling into an agricultural ecosystem

Bushel began its journey in 2017 as a small-scale platform for farmers that delivered grain contracts, cash bids, and receipts. As Bushel evolved into a comprehensive agricultural ecosystem, we realized we needed knowledgeable technology partners to help us rapidly scale while saving time and administrative costs. That’s why we started partnering with the Google for Startups Cloud Program to get support from Google and work with Google Cloud Managed Services partner, DoiT International to help support our use of GKE and create a multi-regional deployment as well as migrate our CUDs to new Compute Engine families and continue to optimize our footprint. We’ll also use DoiT’s Flexsave technology to reduce the management overhead of CUDs in the future.

In just one year, we expanded to over 1,200 live grain receiving locations and quickly grew our services portfolio with electronic signature capabilities, commodity balances, and web development. Because that relationship between farmer and agribusiness is so important, we provide more than 200 grain companies with white-labled digital experiences so each farmer sees their local grain facility they do business with on both desktop and mobile. To further our extension into the digital infrastructure of agriculture, we subsequently acquired GrainBridge and FarmLogs to help farmers handle specific jobs and tasks, and provide the needed insights to improve their business operations. Over 2,000 grain receiving locations across the United States and Canada now use Bushel products. We accomplished all this on Google Cloud.

We leverage the secure-by-design infrastructure to protect millions of financial transactions and keep sensitive customer data safe. Our data is processed and stored in Google’s secure data centers, which maintain adherence to a number of compliance frameworks. We utilize Google Kubernetes Engine extensively as it reduces operational overhead and offers auto scaling up to 15,000 nodes.

Database provisioning, storage capacity management, and other time-consuming tasks are automated with our Cloud SQL usage. Query Insights for Cloud SQL streamlines database observability and seamlessly integrates with existing apps and Google Cloud services such as GKE and BigQuery.

Empowering farmers and agribusinesses in North America

The Google Cloud Account Team had been instrumental in helping Bushel build an expansive agricultural platform that powers APIs, apps, websites, and digital solutions. Google’s startup experts are incredibly responsive, with deep technical knowledge that can’t be found elsewhere. Google Cloud also has provided us credits to explore new ways of analyzing the vast amounts of data we generate, verify, and transfer with solutions such as BigQuery and Pub/Sub.

With BigQuery, we can run analytics at scale with 26%–34% lower three-year TCO than cloud data warehouse alternatives. BigQuery delivers actionable insights on a highly secure and scalable platform, includes built-in machine learning capabilities, and integrates with Pub/Sub to ingest and stream analytic events via Dataflow.

With Bushel, farmers across North America are rapidly responding to sudden market changes by tracking grain prices in real time and instantly buying and selling crops. We see a future where this business information becomes insights – where a farmer can not just know where to sell their grain, but when to sell. The burden right now to engage with carbon markets is high, full of paper-based binders and verification forms. We see a world where farming practices recorded digitally can be permissioned along the supply chain for a better picture of how our food is grown.

With the Bushel platform, millions of farmers around the world will have the digital tools to modernize local grain industries, build more sustainable agricultural supply chains, and help to address global food inequity.

If you want to learn more about how Google Cloud can help your startup, visit our page here to get more information about our program, and sign up for our communications to get a look at our community activities, digital events, special offers, and more.