Cloud infrastructure offers so many advantages: on-demand scalability, built-in security, and a bevy of tooling to scale your business at the speed of the Internet.

It enables companies to pursue “blitzscaling,” as Reid Hoffman calls it. Capital expenses that take years or decades to pay off are no longer required to establish global networking, compute capacity, storage resources, and application enablement tooling. By renting these assets from cloud providers, you can translate capital costs to operational costs, help your company to manage resources efficiently, keep expenses aligned with growth trajectory, and develop a portfolio of business-driving technology assets faster than would have previously been possible.

Certainly, this is the message from many founders and venture capitalists: move to the cloud, build a ton of software, scale like crazy, and win. Sounds great, right?

But history has shown us that the process is not quite this simple. Scale can be great and is a prerequisite to many of today’s most exciting business opportunities — but scale also frequently produces unintended consequences. You need to be able not only to achieve scale but also to manage it.

When scale produces bloat

To understand how unforeseen impacts can ripple out from a rapidly-scaled technology, consider the first mass-produced vehicle, the Model T. The first production model was produced in 1908, and less than two decades later, Ford had produced 15 million. This rapid growth profoundly affected urban living for decades.

Thanks to cars, fewer workers needed to live near cities or along major public transportation lines. The ease-of-access to personal transportation led to suburban population centers and, ultimately, urban sprawl. “Sub-cities” extricated homeowners from the density of urban population centers but also created a complex web of unintended consequences: new and often duplicative administrative bodies, new taxes, new zoning laws, and more intricate infrastructure projects. We are arguably still dealing with this fallout today as communities grapple with antiquated zoning laws and, in their attempts to find ways forward, often produce only more sprawl.

If your technology is in the cloud, you may be challenged with similar issues. For example, when developers build software in the cloud, many of the barriers to building software are removed. As a result, developers build a lot of software — but often without a lot of intentional design. This in turn results in companies building a large number of disparate systems and overwhelming app sprawl.

The cloud can help you proliferate technologies so quickly, in other words, that effective management and re-use of resources becomes incredibly tough.

Managing scale

Software assets are often seen as comprising the “brains” of a company — but to effectively grow, you should consider not only brains but also the digital nervous system. You need systems that connect the brains to all of the other important limbs that have to coordinate in order for your company to drive value.

One way of creating this nervous system and managing this complexity is to leverage the facade design pattern: applying an API layer that abstracts the underlying complexity of multiple systems into an elegant, reliable interface that encourages discovery and re-use of applications, functions, and other technology artifacts such as build and deployment pipelines.

For example, too many enterprises build a new digital “road” for each application that needs to authenticate or authorize users. Instead, you can leverage a facade pattern to help establish one “main road” for these purposes, encourage reuse of the road for new projects, and — with API management — monitor and control all traffic along the road. For tasks such as aligning risk and compliance operations or unifying developer onboarding functions, the distinction between reusing elegant roads and continually building new complicated ones could not be more important.

API management tools mean you can establish a single-pane-of-glass view into your network of digital roads and destinations or, if you prefer the biology metaphor, into the nervous system routes connecting your company’s software brains. This view becomes a point at which suspicious API usage patterns can be detected, reported, and handled and through which business-driving insights from legitimate traffic can be gleaned. Rather than dealing with IT sprawl, you can maintain visibility over your assets, control how they are used, roll out experimental digital products and get immediate feedback on adoption, and generate analytics to help you effectively divest from and invest in opportunities as the market demands.

More is not always better

More is not always better, and, in fact, it is sometimes worse.

It’s a time-worn sales axiom that would-be customers are more likely to make a choice when presented with two or three options rather than fifty, for example, and virtually all of us can relate to moments of “analysis paralysis” triggered by too many choices. These dynamics of choice are such that the diminishing marginal utility of each choice can detract from each option: with each choice comes a little stress, and as these stresses accumulate, customer satisfaction suffers. IT systems are no different; if developers building new connected experiences are left to their own designs, rather than encouraged with standardized resources and best practices, their work may add to complexity and customer dissatisfaction.

One need look only at the various open air markets around the world to see this point in action. They may offer many things to see but the experience is anything but efficient. The multitude of shops selling similar and duplicate items, the zigzag layout, and the expected friction from bargaining with each vendor all mean concepts such as market-wide product discovery and product inventory go out the window. If your developer experience mirrors these marketplaces, your efforts to scale are more likely to tangle up your operations than to satisfy customers.

Contrast this experience with luxury retail experiences where product areas are clearly demarcated in different retail spaces, product explanations accompany showcase items, inventory is available locally or ready to ship, clear pricing is readily available, and similar stores are intentionally anchored to strategic physical areas to encourage customer flow among them. The developer programs that cloud efforts are often meant to enable require a similar focus on luxurious experiences.

If your growth strategy creates bloat, internal developers will not use resources efficiently and your ability to share resources with external partners will likely be hamstrung. Applying API facades helps to ensure that your growing software portfolio is not a complicated maze to be navigated but rather a series of technology products for developers to leverage.

Indeed, you should think of the API itself as a product, not just a way of surfacing or connecting technology. The better the product, the more easily it can be managed, the better the experience developers will have using it, and the more control you’ll have harnessing the cloud to extend your business’s footprint.

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.

As CentOS 7 reaches end of life, many enterprises are considering their options for an enterprise-grade, downstream Linux distribution on which to run their production applications. Rocky Linux has emerged as a strong alternative that, like CentOS, is 100% compatible with Red Hat Enterprise Linux.

In April 2022, we announced a customer support partnership with CIQ, the official support and services partner and sponsor of Rocky Linux, as the first step in providing a best-in-class enterprise-grade supported experience for Rocky Linux on Google Cloud. Today we’re excited to announce the general availability of Rocky Linux Optimized for Google Cloud. We developed this collection of Compute Engine virtual machine images in close collaboration with CIQ so that you get optimal performance when using Rocky Linux on Compute Engine to run your CentOS workloads.

These new images contain customized variants of the Rocky Linux kernel and modules that optimize networking performance on Compute Engine infrastructure, while retaining bug-for-bug compatibility with Community Rocky Linux and Red Hat Enterprise Linux. The high bandwidth networking enabled by these customizations will be beneficial to virtually any workload, and are especially valuable for clustered workloads such as HPC (see this page for more details on configuring a VM with high bandwidth).

Going forward, we’ll collaborate with CIQ to publish both the community and Optimized for Google Cloud editions of Rocky Linux for every major release, and both sets of images will receive the latest kernel and security updates provided by CIQ and the Rocky Linux community. And of course, we’ll offer support with CIQ for both these images, per our partnership.

Rocky Linux Optimized for Google Cloud lets you take advantage of everything Compute Engine has to offer, including day-one support for our latest VM families, GPUs, and high-bandwidth networking. And for customers building for a multi-cloud deployment environment, the community Rocky images have you covered.

Starting today, Rocky Linux 8 Optimized for Google Cloud is available for all x86-based Compute Engine VM families (and soon for the new Arm-based Tau T2A), with version 9 soon to follow. Give it a try and let us know what you think.

Over the last decade, financial service organizations have been adopting a cloud-first mindset. According to InformationWeek, lower costs and enhanced scalability were the biggest drivers for cloud adoption in financial services, and cloud-native applications allow access to the latest technology and talent, enabling adopters to rebuild transaction processing systems capable of supporting very high volumes and low latency.

Both Neo4j and Google Cloud have been using relationship-based data representations since the beginning, and we’re dedicated to using this technology to help financial services customers drive business transformation. We are excited about the prospects of financial services (FinServ) cloud systems and believe that graph data in the cloud can help solve significant challenges in the industry.

Data Challenge #1: Risk Management and Compliance

First among the top concerns for any CIO moving to the cloud is risk management and compliance. Disconnected, uncontextualized, or stale data create opportunities for fraud and financial crimes to occur. The fact is when it comes to FinServ, the question is not “if” but rather how often an attack will occur.  Unfortunately, incidents have been trending upward over the last decade, and COVID has only exacerbated this reality. Financial crimes affect the bottom line both in the remediation of these crimes and in intangibles like brand value.  

Add to this the complexity of international banking, which makes “compliance” a moving target. Penalties due to noncompliance are a constant concern to any FinServ organization.

The tabular representation of information with a fixed number of columns that never change prevents a description of an ever changing world with changing characteristics. Relational databases are great if the world you describe does not move fast but have limitations when data structures are highly interlinked and not homogeneous.

Neo4j Aura on Google Cloud provides a foundation for creating dynamic, futureproof, scalable applications that adhere to the security standards and protocols today’s financial services organizations require to meet the challenges of finding and preventing bad actors. This also includes enterprise scalability; reaching over 1 Billion nodes and relationships to streamline queries and provide solutions that meet regulatory and privacy compliance across geographies. Neo4j has helped some organizations save billions of USD in fraud in the first year of deployment alone.  

What makes graph technology the best choice for fraud detection use cases is that the relationships between the data-points are as important as the data-points themselves. Let’s take as an example, one John Smith approaches a multi-national banking institution to manage the primary account for his new holding corporation.  

While no one has any record of John R Smith Holdings LLC, the bank’s application built on graph technology understands that there are several well-known entities owned by John Smith Holdings. The application also identifies several well-known board members who bank with this institution. Due to this relationship-driven approach, the bank now understands John R Smith is not “John Smith,” who previously attempted to open an account for his holding corporation, which had no information associated with it prior to two months ago.

Data Challenge #2 Manual Processes and Inefficiencies 

The ubiquity of the cloud offers an opportunity to deploy automation at unprecedented levels to tackle the errors and inefficiencies that manual processing allows to creep into processes. When data comes from disparate, perhaps legacy systems – which may have become siloed and “untouchable” over the years – further complexity arises. As an example, if someone in sales types “John Smith” into a CRM system not knowing that John R Smith is the spelling in the customer data master, it may result in two separate and potentially conflicting records. Being able to join those records together in a mastered view helps to solve this problem. In addition, low data quality equates to an increase in risk, costs, and implementation times for new systems. 

Neo4j Aura on Google Cloud provides automation and artificial intelligence (AI) that reduces manual processes and the errors that accompany them. In this graph architecture each node, which can represent a person, will have labels, relationships, and properties associated with it. This allows for the use of AI which can easily understand that John Smith in the CRM is the same John R Smith in the customer master. The information contained in Neo4j can be connected bi-directionally to ensure consistency across applications and data sources. 

One of the benefits of this approach is that linking information allows organizations to keep the full value of the data, rather than forcing the data into predetermined tabular representations, with the risk of losing valuable information and insights.

Data Challenge #3: Customer Engagement and Insight

Another significant concern is the high expectations today’s customers have for every interaction. End users are accustomed to predictable experiences on their digital devices, and FinServ apps are no exception. Added to this, the “Covid economy” has driven digital adoption significantly across demographics; even among customers who might traditionally have used in-person services. This also equates to increased expectations for personalized, predictable experiences with every digital interaction. We know that latency has always been a key consideration for financial trading, but a recent ComputerWeekly study showed that every financial organization should ensure their visible latency is at 10 milliseconds or less. Customers no longer accept their broadband is at fault.

Finally, blind spots in the customer journey often result in dissatisfaction, which ultimately leads to increased churn. Without gaining actionable insights from your customers, there is no room to innovate and iterate on what they are looking for in your products and services. And this translates to losing market share and competitive advantage.

The NoSQL architecture, specifically the dynamic schema and structure of Neo4j Aura gives you the ability to take charge of your data and make changes according to your development cycles or newer data models. This equates to faster builds, more comprehensive releases and a wider, richer data-set that can be contextualized and understood instantly. Graph technology is the logical choice for building a Customer 360 application. Under this approach organizations not only get valuable insight into the individual client’s behavior and patterns, but also those of their family, friends and colleagues. This allows for stronger personalization, targeted campaigns and successful execution, resulting in increased customer satisfaction and retention levels.

Graph Technology on Google Cloud

Neo4j is a recognized leader in graph database technology and the only fully integrated graph solution on Google Cloud, helping to fill a common need for Google Cloud customers. Both Neo4j and Google Cloud are invested in continuing to grow our partnership and mutual product direction.  

You can find and deploy the Neo4j graph database straight from the Google Cloud marketplace, whether you want to download the software for an on-premises deployment, use the virtual machine image, or use the hosted solution, Aura on Google Cloud, the graph database-as-a-service. In any deployment, you get the same enterprise-grade scalability, reliability, and connectivity along with successful, repeatable use cases you can rely on to resolve your particular challenges and integrated billing. 

For a real-world example of how graph technology can optimize financial services, you can read our Case Study with fintech Current. Current, a leading U.S. financial technology platform with over three million members, used Neo4j Aura on Google Cloud to create a personalization engine based on client relationships. 

To learn more about Neo4j Aura on Google Cloud for FinServ organizations, register for our webinar on Thursday, December 16 with Jim Webber, Chief Scientist, CTO Field Ops at Neo4j and Antoine Larmanjat, Technical Director, Office of the CTO, Google Cloud. 

Click here to Register