Modern applications need to process large-scale data at millisecond latency to provide experiences like instant gaming leaderboards, fast analysis of streaming data from millions of IoT sensors, or real-time threat detection of malicious websites. In-memory datastores are a critical component to deliver the scale, performance, and availability required by these modern applications. 

Memorystore makes it easy for developers building applications on Google Cloud to leverage the speed and powerful capabilities of the most loved in-memory store: Redis. Memorystore for Redis standard tier instances are a popular choice for applications requiring a highly available Redis instance. Standard tier provides a failover replica across zones for redundancy and provides fast failover with a 99.9% SLA. However, in some cases, your applications will require more read throughput from a standard tier instance. One of the common patterns customers use to scale read queries in Redis is leveraging read replicas.

Introducing Memorystore for Redis Read Replicas

Today we are excited to announce the public preview of Memorystore for Redis Read Replicas, which allows you to seamlessly scale your application’s read requests by 6X with the click of a button.

With read replicas, you can easily add up to five replicas and leverage the read endpoint to automatically load balance read queries across all the available replicas, increasing read performance linearly with each replica added. Additionally, Memorystore’s support for Redis 6 introduced multi-thread I/O, increasing performance significantly for M3 and higher configurations. Combined, you can achieve read requests of more than a million requests per second. 

You will benefit from this new functionality in several ways. You will be able to scale on demand with up to five read replicas and use read endpoint with any redis client to easily load balance read queries across multiple replicas. This new functionality will also improve availability with automatic distribution of replicas across multiple zones. With read replicas, you will also be able to minimize application downtime with fast failover to the replica with the least replication lag. In the future, Memorystore will also easily enable read replicas on existing standard tier instances to increase read throughput. 

You can learn more about how to configure and use read replicas in the Read Replicas Overview. 

Improving performance with Read Replicas and Redis 6

With the launch of read replicas, you can easily increase the read throughput of a Memorystore instance. You can further enhance the read performance by leveraging Redis version 6 along with read replicas.

To understand why combining read replicas and Redis 6 can significantly improve your application’s read performance, let’s look at the various Memorystore configurations that you can use with your applications today. Memorystore Basic and Standard offerings  provide different capacity tiers. The capacity tier determines the single node performance of a basic and standard tier instance. 

The table below outlines the configuration of the various capacity tiers:

Up until version 5, Redis processed commands using a single thread. The processing involved reading the request, parsing the request, processing the request, and writing the response back to the socket. This approach means that all of the processing, which includes writing the response, was sequentially processed by a single vCPU regardless of the number of vCPUs available in the instance.

Redis 6 introduced I\O threading which allows writing the response using parallel threads. This functionality enables Redis 6 to more effectively leverage available vCPUs, thereby increasing the overall throughput compared to lower versions. Memorystore for Redis version 6 leverages I\O threading and automatically configures the optimal number of I\O threads to achieve the best possible performance for the various capacity tiers. We have also improved the overall network throughput for all redis versions by leveraging improvements in the Google Cloud infrastructure. Together these improvements deliver significant performance improvements and come at no additional cost to you. 

So what can you expect from using Redis 6? As outlined in the table, Redis version 5 and lower uses a single thread to process the write requests for all tiers while Redis 6 uses a larger number of I\O threads at higher capacity tiers which provides substantially incremental throughput for higher capacity tiers.

For example, using a Redis 6 standard tier instance with a capacity of 101 GB (M5), we have observed up to a 200% improvement in read/write performance compared to version 5, though the actual value you’ll see is dependent on your workload. You can get the benefits of Redis 6 by upgrading an existing instance or by deploying a new instance.

By enabling read replicas on an instance using Redis 6, you can further improve the read performance. Read throughput scales linearly with the number of replicas so you can increase your read queries on an instance by up to 500% using five read replicas. By combining Redis 6 and read replicas, you can see a 10X increase in read performance compared to a version 5 standard tier instance with no read replicas.

We are excited about the launch of read replicas but this is just one step in our journey to deliver the scale you need at the best price-performance. You can learn more about read replicas pricing on our Memorystore pricing page and get started using the Read Replicas Overview.

With stated goals of increasing competition, innovation, and financial inclusion, bank regulators across the world are mandating that banks open their systems, enabling consumers to share their financial data with third parties.

One touted benefit of this sharing is that it may create digital banking ecosystems that offer consumers more services than ever, provide banking information and capabilities in more useful and convenient contexts, expand the market reach of ecosystem participants, and boost financial participation among the unbanked and underbanked.

These benefits involve requiring that banks produce application programming interfaces (APIs) to make data and functionality easy to share with partners in a standardized way and to give consumers control over the services with which their data is shared. Because APIs enable developers to leverage and reuse software for new services and digital experiences, including by combining APIs from multiple providers, tech pundits and commentators often refer to the “API economy” — that is, to digital ecosystems in which companies symbiotically share and combine their software to create richer offerings, to complement their proprietary strengths with offerings from other organizations, to share innovation across enterprises, and to expand into new sectors.

Rather than being able to access and act on financial data only through specific channels, for example, consumers in an Open Banking world would theoretically be able to use their money across a constantly-expanding array of apps and digital experiences. Likewise, rather than being confined to one bank’s specific digital services, consumers would be able to opt into a range of services, such as better loan matching or debt reduction advice, to help them do more with their money. Banks, meanwhile, would not have to create all aspects of digital experiences themselves but could rely on external partners, which they can add at unprecedented scale via APIs, to shoulder some of the burden of attracting and creating value for customers.

The envisioned disruption is sweeping, but key questions for bank leaders and bank investors remain, notably the extent to which the Open Banking movement will exert significant, durable impacts on market dynamics — and the extent to which Open Banking compliance constitutes an effective market entry into digital ecosystems and the celebrated benefits of the API economy.

Put simply, is complying with Open Banking regulations adequate to advance a bank’s digital strategy?

Building compliant APIs vs. entering the API economy

Individual regulators are fundamentally constrained in their ability to give banks detailed instructions on how to behave in digital ecosystems. Mandatory regulations can be originally conceived with only one or two business models in mind, not the many thousands of business models that could be partially or fully enabled by the API economy. Detailed rules and specifications may threaten the functionality of services, as regulatory interventions that give highly specific guidance may not be system- and business model-agnostic.

In terms of policy, the willingness of regulators to force banks to adopt APIs is highly significant, but because these regulatory interventions do not offer a meaningful and durable market entry roadmap for banks to follow, the regulations may be an initial catalyst to prompt financial market evolution rather than a natural and enduring end-state for business activity.

Aside from the constraints at the level of the individual bank regulator, there is limited consistency among Open Banking regulations across the globe. Europe’s PSD2 was the regulatory intervention that kicked off this global wave, but there are small but significant variations in the ripple of regulatory actions around the world.

In Australia, Open Banking is part of the Consumer Data Right, an initiative to give customers the right to access their data in a machine-readable form — a right the country does not confine to banking. In Singapore, the Monetary Authority of Singapore is pushing for a lightweight regulatory framework regime. Japan’s Amended Banking Act introduced a registration system for third party providers. Korea’s Financial Services Commission has launched a Fintech Open Platform. Mexico’s recent law to regulate financial technology institutions lays groundwork for an Open Banking regime. The Central Bank of Brazil is aiming to implement the relevant regulatory reforms by the end of 2019. For the largest, internationally diversified banks, these regional differences further complicate any effort to regard mere compliance with these interventions as an effective and coherent market entry strategy.

Despite these complexities and ambiguities, I’ve observed in my work consulting with financial institutions that some banks nevertheless treat Open Banking compliance projects as a means of market entry into the API economy. This mindset could be a costly mistake and may leave these banks at a significant competitive disadvantage as we continue to accelerate into the era of digital ecosystems. In addition to compliance, banks should view a commercial entry into a foreign country as a useful reference for entering the API economy.

Entering the API economy is like entering a foreign market

Banks executing a commercial entry into a foreign country will encounter cultural differences, whether in the form of language, ethnicity, religion, social networks, values or norms. When these cultural differences are large, market entry into a foreign market is more difficult.

The practical implications of administering new business activity in a foreign country also impact the level of difficulty. The physical distance between the home country and the foreign country has to be managed. Border hardness, time zones, and climate also impact the administrative challenges posed by the foreign country. Additionally, the market landscape is foreign. New countries can significantly differ in their natural, financial, and human resources. Staff sent to build up a new division in a new country will have to cope with different levels of market Infrastructure, information, and knowledge. Finally, the economics of entering a foreign country can be heavily influenced by historical and political factors such as a shared colonial history, common memberships of trading blocs, and shared currency zones.

These patterns of differences and similarities can likewise be observed when a bank tries to enter the API economy.

Like entry into a new territory, entry into the API economy may pose sharp cultural and operational differences for banks to grapple with. In this world of APIs and software ecosystems, an API provider’s commercial aim is to make third-parties the dominant force for innovation — that is, to securely share data and services with external contributors who build new connected experiences that generate value for the provider, much as ridesharing companies have generated value by leveraging APIs such as Google Maps. Enterprises focused on ecosystem development market their APIs as products for developers so that new innovation can emerge organically, without necessarily being pre-planned. Investment decisions in the API economy are driven by a desire to help preferred ecosystems to evolve fastest. All of this may be a very sharp change in culture for many banks that historically have sought to be the dominant innovator shaping customer experiences.

The established approach to innovation in banks is highly deliberate, aiming to match bank financial products to specific customer needs and to beat the financial product offerings of peer banks. Compared to modern digital ecosystems, these legacy banks’ resources for, scope of, and receptivity to innovation may be considerably constrained. Banks that actively treat the culture of the API economy as very foreign to their traditional corporate culture have a far greater chance of acknowledging these challenges and making a successful market entry into the API economy.

Many banks may also face challenges transitioning to ecosystem administration models. In traditional banking models, the C-suite commands and controls the bank staff that distributes products. Typically, very few external business partners are involved, and those that are have generally been deliberately, if not laboriously, selected. In contrast, the API economy requires the orchestration of very large numbers of third parties that add value to a bank’s innovation and distribution capabilities. Literally thousands of partners may access a bank’s APIs to build services atop banking data, extend a bank’s functionality or insert the bank’s APIs into new business contexts. In many ways, the whole point is that partnerships don’t have to occur in slow-moving, methodically planned formal partnerships but rather can be achieved at Internet scale while preserving control over and visibility into customer data. This shift in strategy is no small departure for many banks — so again, thinking of the endeavor as entry into a foreign market, rather than something that can be jumpstarted via regulations, is wise.

Crucially, the market landscape in the API economy is also very different from what legacy financial institutions are used to. Traditionally, banks have segmented the market into very large market segments (e.g. consumer banking, corporate banking, private banking etc.). In sharp contrast, the API economy sees partners working together to serve market micro-segments that would not be reachable and profitable by each individual enterprise working in isolation. Simply put, addressing all customer needs, from mainstream use cases to niche applications, is beyond the capabilities of any single enterprise and can generally only be achieved through ecosystems and partnerships. Because partners working together in the API economy seek to serve the customer through the customer’s preferred digital interface (which may be different than bank’s preferred digital interface), ecosystem partnerships represent a massive shift in marketing management, with major implications for a bank’s business architecture, technical architecture, governance, and risk management.

Additionally, in the API economy, pricing decisions are generally driven by a desire for ecosystem growth. Partners work together to extend the customization and value that customers experience when consuming services. By design, the intellectual property in an ecosystem becomes dispersed. Banks have traditionally sought to protect the exclusivity of their intellectual property, and they have often sought economic returns via cost-plus pricing and minimal customization of financial products. Just as with other aspects of the API economy, these ecosystem dynamics and economic relationships typically fall outside a bank’s status quo operations and strategies — more akin to entering a foreign market than to simply satisfying regulatory requirements.

The C-suite should be involved

To approach entry into the API economy as they would approach market entry into a foreign country, banks should consider focusing on a small number of products or segments. They should seek complementary partners who can help them adapt their skills to the API economy and extend the reach of their core differentiating strengths. Just like entry into a foreign market requires combining elements of the home country business model with new local elements, banks will have to transform to increase the effectiveness of their ecosystem participation.

Because an Open Banking compliance project involves regulators specifying the scope and schedule for mandatory APIs, the C-suite may feel relegated to the role of budget provider, which may tempt executives to delegate the sponsorship and steering of the project. Such delegation is not an option for a foreign market entry, where all decisions on scope, cost and timetable are strategic and entirely in the hands of the bank itself — and the C-suite should not consider it an option for entry into the API economy. Bank leaders need to be involved, as the organization likely will not be able to make the necessary strategic and operational transformations if the vision is not defined and driven from the top.

Over the decades, technology has helped us organize large amounts of physical information in ways that are streamlined, efficient, and easily accessible. Rows upon rows of encyclopedias are no longer needed; simply punch in or speak a query into Google Search and find numerous results at your fingertips. There’s no need to haul around cases of CDs or cassettes either, when you can access hundreds of thousands of songs on music streaming services. 

We wanted to bring that same level of accessibility to one specific type of publication: the printed car manual. Here’s how we shifted the paper manual to become an easy-to-access, voice-activated digital experience for owners of the all-new Sienna. It’s helped this resource become just as modern and useful as Toyotas themselves.

Putting cloud technology in the driver’s seat

Far too often, the printed car manual remains unused, collecting dust in the glove compartment—that is, until it’s needed during a roadside emergency or to solve the meaning of a mysterious light popping up on the dashboard. Even then, thumbing through hundreds of pages during high-stakes moments can be stressful. On top of that, these manuals can be expensive to print and update.

Digital versions, such as a PDF file, are a nice start. But, they’re often little more than reformatted flat documents. In poor visual conditions on the side of a road, the last thing a driver wants to do is squint at a phone or scroll through pages of tiny text. And similar to printed manuals, digital versions don’t facilitate ongoing, real-time conversations between drivers and automakers when it matters the most; they’re often only text and pictures, and at best, schematic drawings.

With that in mind, we set out to elevate and personalize the car manual by creating a voice-activated digital owner’s manual experience, all powered by Google Cloud. A voice-based assistant was the clear choice because, as it felt like the most intuitive, natural option, especially while driving. In fact, 51% of U.S. adults have used a voice assistant while driving, and 95% of all drivers expect to use a voice assistant in the next three years. 

We’re now putting this technology on the road by powering the Toyota Driver’s Companion for the all-new 2021 Toyota Sienna model. Accessible through the existing Toyota app, this companion provides real-time assistance, any time of the day. Drivers can ask questions and the companion will efficiently provide helpful answers in convenient ways, from voice to 3D walkthroughs and explorable environments. 

What a modern car manual should do

The Toyota Driver’s Companion has interactive features to help drivers discover the Sienna’s dashboard, set up the car’s interior and exterior appearance, better understand vehicle maintenance, and explore Dynamic Radar Cruise Control, Lane Departure Alert and other features. 

Here are a few other additional key features to call out within the Toyota Driver’s Companion: 

• An easily accessible virtual voice through the Toyota Driver’s Companion lets app users ask personal questions about their 2021 Sienna such as “what’s the height of my car?” and receive immediate answers either by voice, display or interactive input. 
• The manual automatically connects with the purchased vehicle’s VIN number to create a completely personalized experience, curated specifically for the driver. For example, if an unfamiliar light on the dashboard pops up, the Toyota Driver’s Companion can help identify the light’s meaning.
• Interactive hotspots throughout the vehicle’s interior let drivers explore the cabin virtually. Drivers can discover button functionalities, find specific dials, and learn more about car functions, such as how to slide seats or open doors, to become acclimated with their new vehicle.

To bring this experience to life, we tapped into some of our key Google Cloud solutions:

• APIs powered by Google Cloud artificial intelligence technology make accessing specific vehicle information easy and effortless, by leveraging Google’s natural language processing:
  • Google Cloud DialogFlow API serves as the decision tree that gives intelligence for both finding an answer for a question, i.e., how the Companion responds to the end user’s questions. 
  • One of our Text-to-Speech APIs—called Wavenet—creates the Companion’s realistic voice. 
  • And finally, our Speech-to-Text API “listens” to the user’s voice and finds the correct information to craft responses. That means a driver can ask a question multiple ways, and the Companion will still respond with the right answer. 

Our Firebase mobile app dev platform gleans analytic insights that help improve the overall experience and services for OEMs and drivers alike.https://www.youtube.com/embed/66QxWS-PzIM?enablejsapi=1&

We’re encouraging better consumer experiences by providing faster access to fresh information, in a natural, accessible format—voice. But these new voice-activated experiences aren’t only an opportunity to help out drivers; it’s also about strengthening connections between drivers, their vehicles, and automakers, too. 

Our hope is that through this information exchange, drivers can provide feedback on the most frequently misunderstood features, enabling OEMs to address questions early on. By understanding the most requested features, OEMs can also predict and inform driver questions about features. We’re incredibly excited to help make the driver’s experience more connected and helpful.

Vinayak Bhavnani, Co-Founder and CTO of India-based bus transport technology company Chalo, shares how Google Maps Platform is used to improve visibility for commuters and bus operators across India by visualizing geospatial data.

Effective public transport networks contribute to the local economy and help make cities safe, pleasant, and sustainable. In India, buses make up around 90% of the public transport offering, but when you talk to the people who ride them every day, you find that there’s a lot of room for improvement. Heavy traffic means there are rarely any fixed schedules and it’s impossible to know exactly when your bus is coming. We’ve found that people tend to wait at a bus stop for up to 30 minutes a day, which creates a lot of frustration and wasted time.

When we founded Chalo, our aim was to make the daily city commute a more positive experience. Reliability is synonymous with visibility: when you know exactly when the bus is coming, you can plan your day better. If you’re in your office, for example, and see the next bus is in 10 minutes, you can be at the stop at the exact time it arrives, instead of waiting around. To enable this, we base our solutions on richly-detailed geospatial data provided by Google Maps Platform.

Eliminating wait times and increasing revenue with geospatial data

In India, bus passengers tend to have fewer resources. The Chalo App, which can be downloaded for free, allows them to see exactly where their bus is on its route and when it will arrive at their nearest stop. They also tend to be late adopters of mobile technology, meaning we had to create an interface that was user-friendly, reassuring and adapted to all age groups and backgrounds. One of the main reasons we opted for Google Maps Platform is that it’s very present in India and other emerging markets and is familiar to our users, which inspires trust. At the same time, we like the fact that Google Maps Platform provides rich geospatial data while being simple to implement and work with. We use the Geocoding API, Reverse Geocoding, and the Directions API to enable location search and provide directions.

We also worked with MediaAgility to identify the Google Maps Platform products most suited to our needs and the best practices to be followed. This helped to ensure that our business objectives could be met efficiently.

The Chalo App also enables digital ticketing, alongside the Chalo Card, a payment card for those who don’t own a smartphone. India, like the rest of the world, is gradually moving away from cash payments, but the public transport system is proving slow to catch up, meaning people still must have cash in hand when they board the bus. Digital ticketing not only makes commuting more convenient, it also helps protect passengers, drivers and conductors during the COVID-19 health crisis by limiting physical contact. 

Chalo also offers solutions aimed at bus operators that help them improve their services and their bottom line. In major Indian cities, buses are run by a combination of public and private agencies and small private individual bus operators, with the majority of the latter only operating one or two buses. The market is very fragmented and there’s not much incentive for bus operators to invest in infrastructure or customer experience – especially when they have little to no visibility on where their fleet is at a given time, how many kilometers it travels in a day, or how much money it takes. 

The Chalo dashboard provides operators with a map-based real-time overview of bus locations, alongside scheduling features and route, ticketing, and passenger statistics. Geospatial intelligence and insight into passenger demand enable operators to explore new avenues of revenue and adapt routes and services to passenger needs. Operators who’ve partnered with Chalo report an average improvement of 10% to 30% of their bus fleet operations.

Chalo is currently powering about 100 million rides a month on 15,000 buses in 37 cities. We’d like to see the number of rides increase tenfold over the next few years. To do that, we’re looking to broaden our offer and expand to other parts of the country and across international borders. A pilot is underway in Bangkok, and we’re considering expansion into South-East Asia, Africa, and the Middle East. Having access to detailed geospatial data anywhere in the world via Google Maps Platform, without having to make any major investments or changes to our technology stack, will make this considerably easier. 

At the same time, we’re exploring artificial intelligence and machine learning to improve the accuracy of our scheduling features and we’re introducing video-based solutions for people-counting on buses. Our aim is to continually improve our offering and optimize our services. We’re looking forward to working closely with Google to make that happen.  

For more information on Google Maps Platform, visit our website.