It has been seven years since Marc Andreesen’s famous article “Why Software is Eating the World” was published in the Wall Street Journal, and given the slow pace of change in many companies, some executives still may not be taking the threat of being “eaten” seriously enough. 

Software, and platform business models based on software, have the potential to deliver powerful economic forces into virtually any company or industry. Every company has valuable assets—such as data, expertise or access to certain services or user bases—and most of these assets can be delivered via software. Once an asset is expressed as software in a modern way—that is, as an application programming interface (API)—it can be combined with other software to create new applications and digital experiences.

Benefits of this approach, just to name a few, include near-zero marginal cost to scale up APIs for new users or use cases; global reach for both partners using APIs and end users consuming the digital experiences those APIs power; and network effects triggered as more partners use a given company’s digital assets and spread its services into new markets and use cases.

Disruption by software-powered business models

In the last two decades we’ve seen individual companies and entire industries upended by these kinds of software-powered business models. Examples abound: Amazon and the retail industry, Netflix and movie rentals, Uber and ride hailing, Airbnb and hotels, etc. We’ve reached the point that these companies’ names have become verbs synonymous with being “eaten” by software (e.g., “Amazoned” or “Netflixed”).

The most famous examples of digital disruption involve digital natives, of course, but legacy businesses are leveraging software to evolve too. Brazilian retailer Magazine Luiza—a company I’ve worked with through my employer, Google Cloud’s Apigee team—has enjoyed enormous revenue growth and seen its stock soar, for example, as it has built out its digital platform capabilities and transitioned from a primarily brick-and-mortar model to an omnichannel one. The point is, whether a company has been in business five decades, five years or five months, software remains ravenous and is always looking for new companies and industries to “eat.”

Change in the face of serious threats

Facing this threat, how should corporate leadership respond? There are some excellent examples of CEOs who have galvanized their companies and led them through the massive, gut-wrenching change required to pivot in the face of a serious threat. A few of the biggest examples include: 

• In 1995, it became apparent to Microsoft co-founder and then-CEO Bill Gates that the internet was “the most important single development to come along since the IBM PC,” and, if not embraced in haste, a threat to many of Microsoft’s businesses. In May of that year he published the “The Internet Tidal Wave” memo and focused all of Microsoft on adopting and building for the internet. Almost 20 years later, current Microsoft CEO Satya Nadella similarly made the bold decision to redirect the company for a cloud-first world. 

• Facebook went public at $38 per share in May of 2012 but within months, stocks could be had for a little over half that. The concern? Facebook was a desktop-optimized website without a polished mobile presence, and by 2012, consumer attention had begun to accelerate towards mobile at a much higher rate than many initially predicted.  Facebook CEO Mark Zuckerberg reacted by not only proclaiming Facebook a mobile-first company, but also backing up that proclamation with action.  

• Turning to another company I’ve worked with via Apigee, T-Mobile launched its highly visible “Uncarrier” campaign—which offers streamlined, customer-friendly plans and services—while also investing in and executing a new IT vision dedicated to ongoing digital transformation. T-Mobile execs have credited the technology effort, spearheaded by CEO John Legere, with helping the company to introduce new services and better service customers. T-Mobile’s market cap has more than doubled since Legere took over in 2012.  

Keeping pace with changing customer needs

In the face of an existential threat, strong executive leadership is required to pivot the company to safety, as these examples attest. Digital transformationisn’t about deploying new technologies just to make an existing approach more efficient or to add a few new apps or features to the status quo; digital transformation is about keeping pace with changing customer needs by leveraging software platforms to continuously evolve how the business operates. This can be akin to turning an enormous ship—and a ship can’t turn very well without her captain, first mate, and other leaders showing the way.  

Research supports this. A recent Deloitte survey, for example, found that over “80 percent of respondents from digitally maturing organizations say their leaders have sufficient knowledge and ability to lead the company’s digital strategy,” compared to only “22 percent of early-stage business respondents [who] have the same belief.” Similarly, Gartner research finds that CEOs are seeking a “deeper understanding of digital business” as they shift their focus from growth in general to how technology helps them attain it.  

More recently, the onslaught of software devouring the world has been further accelerated by machine learning making everything smarter, voice interfaces changing how people interact with devices, and more. To keep pace, corporate leaders need to galvanize their companies to build and deploy software faster, make systems and data easily accessible inside and outside their companies, and improve digital experiences through not only machine learning but also constant data-driven iteration. 

Seven years after Andreesen’s editorial, the pace of digital disruption is still increasing, and so is the need for strong leadership to pivot fully into digital. Over half of the Fortune 500 has been acquired, merged or declared bankruptcy since 2000—and the companies that survive in coming years won’t be those whose leaders treat technology as an IT concern rather than a core part of the business.  

Traveloka is an Indonesian tech company currently focusing on the travel and lifestyle markets. Our customers, the majority of which come from Southeast Asia, visit the site mainly to book flights, hotels, transportation, lifestyle experiences (e.g. theme parks, movie tickets, beauty and spa treatments, and restaurant vouchers), and much more. We aim to serve more customers across the globe as part of our giant expansion plans.

In past blog posts, my colleagues have written about how Traveloka is using Google Cloud for data provisioning and stream analytics. Today, I’m sharing how we use Apigee API Management Platform from Google Cloud, a key part of my role as an engineering manager in charge of the after-sales and affiliation domain.

Extending the global footprint with Apigee

Expanding to markets globally means dealing with a lot of unique and challenging factors in each country. Thinking about different government regulations, currencies, payment systems, and customer service expectations is only the beginning.

Problems arose when partners who had connected with our flights API wanted to add another service, like accommodation. They felt like they were working with a different company. We turned to Google Cloud and found an answer.

There’s a lot of potential obstacles given how differently each country’s marketplace operates, which is why we use APIs and a partner integration approach to better distribute our inventory, thus helping us to scale our business quickly in a competitive space.

When we started Traveloka, we were serious about building a product that would be better than our competitors. Better in terms of inventories, services, and also pricing.

We also knew that we wanted to have the best strategies for increasing our exposure within and outside of Southeast Asia. With all the right features needed (security, high performance, monitoring, and low development and maintenance costs), Apigee helps us execute on our business plan, by making it quick and easy to work with the partners that make the Traveloka platform a success. 

API Gateway: Make Or Buy?

When we started, we built our own API gateway with our first version of API specifications. Before that, we looked into several API gateway products (including Apigee), did some research, some POCs, and had several meetings with vendors.

However, since we were just starting to dip our toes into the API business and didn’t have enough use cases to justify the purchase, we decided to build our own system with the bare minimum requirements. 

It used to take up to three months to deploy a new API for a partner. Now that we have the Apigee developer portal, it just takes a few days.

After a while, other Traveloka products that also wanted to have their API exposed rebuilt the same thing. Problems arose when partners who had connected with our flights API wanted to add another service, like accommodation. They felt like they were working with a different company. Different standards, different security practices, different formats—it wasn’t an optimal way to work.

About a year and a half after the release, we started to understand the scale, needs, and the limitations of our own platform. We were convinced that a better solution was needed to support our business growth. We then met with Apigee team again, at the Google Cloud Summit 2018 in Jakarta.

Aside from standardizing our APIs, Apigee supports benchmarking, a fantastic developer portal, a sandbox environment, and great monitoring and analytics. Apigee gives us remarkable speed and agility. It enables us to scale quickly, which is vital to executing our business plan to offer more services in more regions. 

I also like the rate-limiting feature that lets us limit the throughput rate from one API to another. The fact that we can do this not only per URL, but also per partner, gives us a lot of flexibility.

For example, if partner A has a throughput of 100 calls per second, but partner B needs 500, we can easily meet those differing needs and manage our traffic efficiently. When we evaluated API gateways, Apigee was the only one that enabled us to limit to that level of granularity. 

Our APIs are meant for B2B, not for the public. Because of the requirements, we need a high level of security. Apigee helps us in managing the security with its SSL handshake features as well as the authentication and authorization methods. 

Aggressive Growth with Apigee

Before we had Apigee, sharing APIs with partners was a laborious process. We exposed approximately 20 APIs through a shared document that listed our APIs with the types of the requests and responses they need to handle. Partners could see what was available and how they could integrate into our staging. More work was required before they could come in and try APIs in our sandbox.

It used to take up to three months to deploy a new API for a partner. Now that we have the Apigee developer portal, it just takes a few days.

The developer portal enables our partners to view all of our APIs and try them out in the sandbox. The simplicity in creating and managing proxies is also a huge time saver. Right now, we have two B2B partners onboarded to the developer platform, and a few more still working manually through our old, in-house platform.

We expect to transition them over and add 20 new partners to the Apigee platform this year. Because it now takes us as little as two weeks to onboard a new partner from first establishment to go live, we’re ramping up quickly. We estimate that we saved at least a year of development time by deploying the Apigee platform as opposed to building one in-house.

Rapid Learning, Rapid Onboarding

Our developers are very happy with Apigee and feel the portal makes Traveloka look more professional. Equally important, the Apigee learning curve for developers and partners has been short. In just one week our partners know how to use all our APIs. If you compare that to the previous process of referring to a Google Doc and building their own servers to connect to our staging, it’s incredibly easy.

We look forward to exploring other ways that the Apigee platform can help Traveloka; we see strong potential to use even more features to help Traveloka grow and stay competitive.

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.