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.

The Google Maps Platform Android SDK supports extensions for reactive programming, which helps you write code to handle asynchronous operations.

Write reactive and responsive mapping applications with Google Maps Platform

In mobile apps, asynchronous events can happen at any point in time: user touch events, waiting for network calls to complete, or receiving push notifications, to name a few. As an app developer, accounting for these events and composing them with other asynchronous events can be challenging. Reactive programming is an alternative to passing callbacks for different events and helps simplify the process of working with asynchronous events. In reactive programming, events are modeled as a stream, emitting items over time.

https://youtube.com/watch?v=1TmJvOZfBVQ%3Fenablejsapi%3D1%26

There are two libraries you can use to write reactive code: Kotlin Flows and RxJava. The next two videos show you how to use each one.

Writing reactive and responsive mapping applications using Kotlin

If you’re a Kotlin developer looking to use Coroutines and Flows, the KTX library allows you to use Kotlin Flows to receive events. The Maps KTX library includes extension functions that return Kotlin Flow objects, so you can listen to events in a reactive manner. Unlike suspending functions, which return a single value, Kotlin Flows can return several values over time. For example, you can use a Flow to receive camera event changes over time. To get started using Kotlin Flows in your app, include the Maps KTX library in the dependencies section in your build.gradle file.

https://youtube.com/watch?v=Cotx1ZmEYg8%3Fenablejsapi%3D1%26

Creating reactive maps on Android with RxJava

Integrate Google Maps Platform SDKs with popular Android library RxJava. RxJava is the Java implementation of Reactive Extensions, which is a library for composing asynchronous and event-based programs using observable sequences. One thing RxJava does is allows you to convert callback-based asynchronous code into a chain of transformations. Learn how this works and the other ways you can use RxJava in the third video in this series.

https://youtube.com/watch?v=AgGE7fAMrdA%3Fenablejsapi%3D1%26

​​We hope you learn more about reactive programming concepts to help you build responsive and reactive mobile apps in this three-part YouTube series. Have ideas for helpful videos you’d like to see on our channel? Leave a comment on any of our videos. And don’t forget to subscribe to our YouTube channel for the latest updates, tutorials, customer stories, and more.

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

Editor’s note: This post is part of an ongoing series on IT predictions from Google Cloud experts. Check out the full list of our predictions on how IT will change in the coming years.

Prediction: Over half of all organizations using public cloud will freely switch their primary cloud provider as a result of available multicloud capabilities

In the years ahead, companies will use a multicloud strategy not just as a way to hedge their bets, but as a way to switch from their first cloud to their next one. Research shows that the majority of companies are already multicloud, meaning they use more than one hyperscale cloud provider.

More and more, we’re talking to companies that describe using multicloud technologies as a way to do switch not just workloads — but mindshare — to a different cloud. In other words, for many people, multicloud is a phase, not a permanent state.

You may start using one cloud but still need to be able to incorporate existing investments you’ve already made in other clouds without having to move anything. Here at Google Cloud, we’ve made unique investments to make sure we can meet our customers wherever, and in whatever cloud, they are.

For instance, Anthos, our multicloud management plane, ensures consistency when working with your compute and data on other clouds. You can view workloads, deploy services, and apply common security policies across multiple clouds. BigQuery Omni allows you to query data in other cloud storage accounts in Amazon S3 or Azure Storage without having to move the data itself, helping to bring analytics to data wherever it resides.

Building new skills and getting comfortable in other clouds is not where multicloud stops. Many organizations are taking it a step further — upgrading technology, moving core data, and continuing to grow cloud adoption with a secondary provider.

What starts out as wanting the best capabilities to achieve IT goals will often lead organizations to swap from their first cloud to their next cloud — and by 2025, we believe that most organizations will be doing just that.