With 150 million users and counting, Picsart was originally founded as a photo and video editing app we use to enhance our everyday life before uploading them to various social media platforms. As its user numbers continue growing, the company began exploring options for incorporating its easy-to-use editing tools into other applications and services. Now, businesses looking for a low-lift solution to enhance their product offerings with Picsart’s award-winning software suite can do so. Thanks to Apigee, organizations from assorted markets, such as printers, t-shirt makers, and phone case designers, are benefiting from Picsart’s custom design APIs.

Picsart helps companies reach a new audience of customers by offering them graphic design capabilities at an affordable cost, avoiding the resource and time-intensive process of hiring developers and building these functions from scratch. The benefits of APIs are energizing Picsart’s business partners, too; with the addition of photo editing, keeping customers engaged, and returning to their apps.

“Eighty percent of our users are Generation Z and Millennials,” says Jinny Jung, vice-president of Picsart’s API program. “They’re the future of creators all over the globe. They want creative control.”

“Many of the businesses we serve are looking to tap into that audience. They really need solutions like this to take their business to the next level,” Jung adds. Having an API service also takes Picsart to the next level — thanks in part to Apigee.

How to turn a quick pivot

Moving from strictly business-to-consumer (B2C) services to a business-to-business (B2B) offering wasn’t easy for Picsart. The company had to adopt an entirely new business model and develop a new suite of API products — and they did so quickly. 

When a prominent social media site contacted Picsart about offering its editing tools to their users via APIs, Picsart knew it couldn’t miss this opportunity. However, none of their developers knew how to manage APIs for external use, an endeavor involving multiple processes and fraught with logistical complications. Failing to configure APIs correctly allows malicious actors to effortlessly bypass cybersecurity protections, exposing network data.

The company quickly assembled an API business unit to plan and coordinate the creation of a secure API development process. This process would support marketing, sales, distribution, and other facets of the business, all while still delivering great functionality to the company’s original B2C customers. And voila! Picsart was reborn. 

The API BU works as “a scrappy startup within a larger company,” as Jung puts it. Its budget is scrappy too. Among the unit’s first tasks: finding an API management platform that could simplify and streamline all the tasks the team faced at an affordable price. Jung says that Apigee was a clear choice.

“Apigee’s offerings gave us the flexibility to get off the ground without a huge budget and grow our business over time. It’s super easy to use, the dashboard is very intuitive, and the price came in well for us.”

The company had already used APIs internally, but had never provided them to customers or partners.  

“We needed to lean on gateways and management platforms that already knew how to set everything up,” Jung says. “We really needed the shortcut.”

Her team did consider other API platforms, but being part of Google Cloud gave Apigee a natural edge.

“We were already Google Cloud clients. We were already part of the Google Cloud ecosystem. We really liked Apigee’s ease of use and the power of Google behind it.”

Apigee works seamlessly in tandem with its other Google Cloud services, including the Google Cloud Content Delivery Network (CDN) and BigQuery, Google Cloud’s fully-managed data warehouse.

“Apigee’s integration with the whole Google ecosystem makes our lives easier, and makes it quite natural for us to use,” says Tiberiu Stanescu, director of engineering for the Picsart API business unit. “It allows us to also meet our technical needs, including scalability and even improved performance with queries and, when we’re integrating the data, dashboards.” 

Using Apigee for total API control

Picsart uses Apigee to manage all its external APIs, which include those that enable users to remove or change photo backgrounds, apply filters, and add text. Apigee also manages the API features for Picsart’s Editor SDK package.

Key ways in which Picsart uses Apigee include:

• API management. Apigee runs test/stage and production environments, can customize pre-and post-flows, and automatically authorize for services with different methods including API Keys and oAuth.
  Apigee’s pre-built integrated portal has helped Picsart “greatly” in the time the company has been using it, Stanescu says. He praised its flexibility and its rate-limiting function, “which allows us to properly define and secure our products.”

• Developer support. With Apigee, Picsart now takes an “API-first” approach to developing new features by using microservice architectures. They’re exposing APIs via their developer portal, which allows them to describe precisely how developers can use each API.
  
• Apigee helps Picsart’s own developers use APIs to simplify the development process and save the company time and money. In conjunction with other Google products, Apigee is providing Picsart with the data and analytics it needs to view and monitor API-related productivity improvements.

• Security. Apigee’s out-of-the-box security requires no specialized knowledge or skill to implement. Picsart relies on Apigee security features such as including headers to set up security parameters, and custom rate-limiting policies and quotas, allowing the company to avoid stack overflow from API calls.

As a result, the company has experienced zero API-related security incidents, Stanescu notes. “We’re definitely grateful to Apigee for this,” he adds. Recently, Stanescu says, a company performed penetration testing on Picsart’s APIs, looking for vulnerabilities, but failed to discover any security flaws or threats. Apigee’s easy-to-use, but powerful security features are helping Picsart keep its clients and customers safe and secure.

From scrappy startup to business core

In the three years since implementing Google Apigee, Picsart’s API business unit has gone from a seemingly simple request to a critical product offering enabling new and recurring revenue.

“It’s part of the foundation of our business,” says Jinny Jung. “It powers our entire API external-facing business. We wouldn’t be able to sell APIs to developers and partners without the Apigee API gateway. We wouldn’t have gotten off the ground without Apigee.”

Apigee is helping Picsart in another key way, too: its integration with products like BigQuery, Google’s data analytics platform that lets it stay on top of which APIs are most used. That information guides every aspect of the business and helps the company develop and release new generative AI-powered products.

“The data absolutely informs what we choose to develop and where we put our resources,” Jung says. “Apigee makes it super easy for us to track API use and see the trends.”

With Apigee, Picsart is opening up a new world of creative design to audiences across all markets and demographics, while avoiding the stress that comes with a costly development process. Today, generative AI apps continue capturing imaginations, unlocking the ability to create awe-inspiring art with only a few natural language prompts. Picsart and Apigee will continue working together to provide a canvas through APIs no matter where an artist may be.

In the past year, Google has worked to surface timely and reliable health information, amplify public health campaigns, and help nonprofits get urgent support to Indians in need. Now, we are continuing to focus on helping India’s businesses accelerate their digital transformation, deepening our commitment to India’s digitization and economic recovery. To support customers and the public sector in India and across Asia Pacific, we’re excited to announce that our new Google Cloud region in Delhi National Capital Region (NCR) is now open. 

Designed to help both Indian and global companies alike build highly available applications for their customers, the Delhi NCR region is our second Google Cloud region in India and 10th to open in Asia Pacific. 

What customers and partners are saying

Navigating this past year has been a challenge for companies as they grapple with changing customers demands and economic uncertainty. Technology has played a critical role, and we’ve been fortunate to partner with and serve people, companies, and government institutions around the world to help them adapt. The Google Cloud region in Delhi NCR will help our customers adapt to new requirements, new opportunities and new ways of working, like we’ve helped so many companies do in the region: 

• InMobi scaled a personalized AI platform to support 120+ million active users. “With the arrival of the Google Cloud Delhi NCR, InMobi Group sees the opportunity to continue closing the gap between our users and products,” says Mohit Saxena, Co-founder and Group CTO of Inmobi. “Glance, especially, has been serving AI-powered personalised content to over 120 million active users. We can’t wait to continue giving them truly meaningful experiences that are speedy, scale well, and are relevant to them, by expanding the use of our current tools working on Google Cloud with the opening of a new region.”
• Groww now supports a sizable user base. “Google Cloud provides great technology that enables us to build and scale infrastructure to millions of users, and the new Google Cloud region in Delhi NCR will continue to help more businesses and startups in India access powerful cloud-based infrastructure, products and services,” says Neeraj Singh, Co-founder and Chief Technology Officer, Groww.
• HDFC Bank is positioned for the future. “At HDFC Bank, we are harnessing technology platforms to both run and build the bank. As we progress to be future ready, the objective is to invest in future technologies that give us scale, efficiency and resiliency. Towards this the Google Cloud region in Delhi NCR will enable us to enhance our resiliency and help us in building an active-active design framework for our new generation applications on cloud,” says Ramesh Lakshminarayanan, CIO, HDFC Bank.  
• Dr. Reddy’s Lab built a modern data platform with Google Cloud. “At Dr Reddy’s, we pride ourselves in helping patients regain good health, acting quickly to provide innovative solutions to address patients’ unmet needs and in accelerating access to medicines to people worldwide. Our Google Cloud-powered data platform is helping us realize these objectives and we welcome Google’s investment in the new Delhi NCR region as helping us and other businesses in India make further contributions to our social and economic future,” says Mukesh Rathi, Senior Vice President & CIO, Dr. Reddy’s Laboratories.
• “To survive the disruption caused by the pandemic and to succeed in the long term, organizations need to become digital natives, so they can be more agile, explore new business models and build new capabilities that boost resilience. A cloud-first strategy plays a key role in enabling businesses to do this,” said Piyush N. Singh, Lead – India market unit & lead – Growth and Strategic Client Relationships, Asia Pacific and Latin America, Accenture. “Harnessing the potential of cloud requires the right data infrastructure and this expansion by Google Cloud will undoubtedly help Indian enterprises in their digital transformation journeys.”

A global network of regions

Delhi NCR joins 25 existing Google Cloud regions connected via our high-performance network, helping customers better serve their users and customers throughout the globe. As the second region in India, customers benefit from improved business continuity planning with distributed, secure infrastructure needed to meet IT and business requirements for disaster recovery, while maintaining data sovereignty.

With this new region, Google Cloud customers operating in India also benefit from low latency and high performance of their cloud-based workloads and data. Designed for high availability, the region opens with three availability zones to protect against service disruptions, and offers a portfolio of key products, including Compute Engine, App Engine, Google Kubernetes Engine, Cloud Bigtable, Cloud Spanner, and BigQuery. 

Supporting India’s recovery with training and education

Google and Google Cloud will also continue to support our customers with people and education programs. We’re investing in local talent and the local developer community to help enterprises digitally transform and support economic recovery. 

Through the India Digitization Fund, we expanded our efforts to support India’s recovery from COVID-19—in particular, through programs to support education and small businesses. In addition to expanding internet access, and investments to help start-ups accelerate India’s digital transformation, we’ve grown our Grow with Google efforts. Businesses can access digital tools to maintain business continuity, find resources like quick help videos, and learn digital skills—in both English and in Hindi.

Helping customers build their transformation clouds

Google Cloud is here to support businesses, helping them get smarter with data, deploy faster, connect more easily with people and customers throughout the globe, and protect everything that matters to their businesses. The cloud region in Delhi NCR offers new technology and tools that can be a catalyst for this change. To learn more, visit the Google Cloud locations page, and be sure to watch the region launch event here.

Product teams often serve as the nexus between all organizational units within a company, ensuring that a specific line of business follows a clear roadmap and that cross-functional alignment drives success. At their most empowered, product owners are like miniature CEOs for each offering within a company.

Unfortunately, in today’s complicated IT landscape, not everything that should be thought of as a product receives the designation. In my time as a digital consultant, I’ve seen one particular technology too often dismissed as back-office minutiae — application programming interfaces, or APIs.

APIs can be the glue that binds a company’s resources together and the mechanisms through which an enterprise’s data, functionality, and other digital assets are accessed and distributed. They enable software systems to communicate and let developers leverage software for new applications and digital experiences, abstracting underlying complexity into a consistent interface that allows data and functionality to be combined and reused with unprecedented flexibility.

Unfortunately, many business leaders see APIs as middleware and thus as undeserving of the resources of a full-fledged digital product. Their organizations create APIs as one-off projects, with engineers moving on to other projects when they are done and no one looking after an API’s maintenance or whether it offers utility beyond the bespoke use case for which it was created.

This is a problem because APIs can unlock digital assets that otherwise would be captive within enterprise silos. An API that exposes a customer database can likely be used and reused for numerous purposes, for example, and treating developers as customers of this API can help increase adoption of and the amount of innovation around it. But such a powerful outcome is unlikely if an API has been created only as a system integration detail rather than as a product with an owner who oversees a full lifecycle, from ideation to adoption to iteration. Put bluntly, a project-oriented attitude toward APIs misses the boat.

Pitney Bowes, a company I’ve worked with at Google Cloud, offers a high-profile example in which a notable enterprise has treated APIs as products and given its API program the same treatment it would give to any go-to-market offering. After selling traditional mailing and shipping solutions for nearly 100 years, the company transformed itself into a provider of digital logistics and e-commerce solutions by building out 160 public APIs and 400 internal APIs. This enabled its developers and partners to easily consume the company’s location intelligence and shipping services in new, agile ways. It also accelerated the company’s internal project timelines, shortening the average project lifecycle from over a year to just a few months. What’s more, APIs not only introduced efficiencies and reduced costs, but also opened new revenue streams. Because developers can more easily leverage individual Pitney Bowes business capabilities for their applications, the company’s services are manifesting in new ways — such as when Pitney Bowes technology is harnessed to let customers print USPS shipping labels from within the context of an online marketplace.

Manage APIs as products

Traditionally, but wrongly, APIs have been considered pieces of other products. They’ve been built by the IT team at the request of product owners every time a project came up that required one. When the funding spigot is flowing, APIs generally receive support. But once the project runs its course, the APIs are neglected and quickly grow outdated.

Without consistent resources, APIs can’t be adapted to fluctuations in the enterprise and market dynamics. Worst of all, project-oriented APIs often end up siloed within the business unit that gave birth to them, which defies the benefit of modern APIs: to not only allow enterprise assets to be reused by other business units and partners but also accelerate the business’s innovation by increasing the number of developers interacting with its capabilities.

In contrast, if an API is treated as a product in its own right with its own owner lobbying for consistent funding, the API can be iterated according to shifts in internal and market trends. Ideally, the product owner should continually monitor an API’s engagement and collect and synthesize analytics to improve quality of service. Product-minded companies frequently launch APIs as minimum viable products in order to get ideas to market faster, then use API consumption analytics to understand developer engagement and refine APIs to be even more attractive, powerful, and intuitive.

With the help of management tools that facilitate dynamic changes, an API product owner can also help ensure that developers benefit from the latest and greatest build with minimal interruption.

Virtually all traditional product ownership responsibilities can be easily applied to an API. An API product owner is responsible for galvanizing the entire company around their API’s value. Their team can answer any questions users may have about the API’s value proposition or how to use it. It may sound trivial but having dedicated experts available to assist with any question that may arise can be a boon to an API’s velocity.

Additionally, if a dedicated product owner is assigned to pilot a company’s aggregate API program, they can use comprehensive monitoring and analysis of all API traffic to derive insight into which APIs drive value and which don’t. This can save considerable time and money from being wasted on the wrong bets. The product owner can also create API bundles segmented according to each developer community the program wants to serve. Here, the goal is not just to expose enterprise assets, but also to encourage repeat consumption. When it comes to third-party engagement, these bundles should seek to improve partner stickiness to cultivate and maintain new revenue channels. Just as any product is only useful if it has users adopting it and sticking with it, APIs are typically valuable when they attract communities of repeat users.

Tools and processes that turn APIs into strategic assets

To drive an API as a strategic asset, an API product manager should support the API with management tools and processes.

First off, it’s necessary to establish comprehensive security layers for an API so cross-functional internal groups and third-party partners are comfortable using it. Mechanisms that apply protection with introducing user friction — such as OAuth, API key verification, XML/JSON threat protection — are strongly encouraged. It’s also often prudent to integrate machine learning functionality that can detect bot attacks and other adversaries before they breach an API and affect either its developer users or the end users consuming those developers’ apps.

Enterprise software products are typically afforded visualization tools, dashboards, reports, and self-service functionality to drive adoption — and APIs should be no different. Comprehensive portals that highlight API features (including knowledge centers, interactive documentation, blogs, and forums) should be crafted to promote developer consumption. Anything that is likely to magnetize collaborators and expedite registration should be provided for an API. A primary goal of API-first development is to increase velocity, so offering developers a self-service experience while maintaining visibility and control over API usage is crucial.

Manage with an “outside-in” perspective

Perhaps the most important role an API product owner must fulfill is maintaining a staunch outside-in approach.

In an inside-out perspective, enterprise leaders look internally for gaps and fill them with existing IT capabilities. Internal intuition untested by the market can define planning, and the resources that IT already has — rather than those that customers demand — typically restrict options. In contrast, an outside-in approach requires the company to listen to what the market is asking for and to respond appropriately. Outside-in thinkers start by asking what the customer needs, then build strategies from there. Because customer preferences are moving targets, an outside-in perspective is constantly evolving and seeking new data. In the case of API programs, product managers should find ways to align API user data with business KPIs, which can be essential to organizing stakeholders and achieving buy-in for the program throughout the organization.

Because both consumers and developers will abandon products that do not meet their needs, an outside-in perspective is increasingly non-negotiable. The product owner needs to analyze rapidly-changing market trends, understand the competitive landscape, keep a pulse on customer and stakeholder needs, and facilitate a backlog of changes that can help the company satisfy the market. Essentially, API product owners are the end-user advocate — and that’s for both for developers using the APIs and the people touching the applications powered by those APIs.

None of this means product owners need to be entirely risk averse, however. They should have the freedom to experiment with hypotheses and to make adjustments — but to make experimentation viable over the long run, they also need to have the foresight to kill a project immediately if the early end-user response is poor. If the product owner is not learning and iterating, they probably are not pushing the API program forward.

Calling all product professionals

If an enterprise plans to pursue an API-first mandate, it’s crucial that the API program is a well-funded, autonomous business unit. Without a visionary owner, APIs will not be able to usher in the transformation experienced by companies such as Pitney Bowes. The API-first philosophy requires that APIs are built prior to applications and that the API provide a value proposition of its own — which means that if an enterprise wants to accelerate innovation and take advantage of APIs, its first step should be to hire API product managers.

Editor’s note: Today we hear from the Lowe’s SRE team. They share about how they have been able to increase the number of releases they can support by adopting Google’s Site Reliability Engineering (SRE) framework and leveraging their partnership with Google Cloud. 

At Lowe’s, we’ve made significant progress in our multiyear technology transformation. To modernize our systems and build new capabilities for our customers and associates, we leverage Google’s SRE framework and Google Cloud, which helps us meet their needs faster and more effectively. With these efforts, we’ve been able to go from one release every two weeks to 20+ releases daily—about 20X more releases per month. 

Our SRE transformation didn’t happen overnight, though. Every step along the way brought some challenges. But looking back, we are excited to see how much we have accomplished for our customers as a result. 

Back in 2018, before adopting SRE practices, we were more reactive than proactive, following an “eyes on glass” approach. On-call structures and incident management efficiency were not at optimal levels with too many repetitive and manual tasks, resulting in operational toil. Production concerns were not surfaced into the product roadmap, which resulted in delays in making fixes.

Bootstrapping SRE at Lowe’s

As we moved from on-prem to Google Cloud, we decided to move from a monolithic- to microservices-based architecture. And to better manage this new architecture, we embarked on an SRE journey. 

Then as COVID-19 hit, we really had to accelerate this journey as customers increasingly moved to online ordering and delivery to meet their Total Home Improvement needs. To do so, we followed four key principles that allowed us to meet changing customer needs quickly and release fast and reliably.

1. Automate away toil 
   As we moved from traditional Ops to an SRE ecosystem, our biggest opportunity was reducing toil, so that engineers can spend time on activities that drive business impact and customer outcomes. We think of toil as work that is manual, repetitive,  tactical, devoid of enduring value—but automatable. So, to tackle toil, we focused on automating away the need for manual intervention. As an example, we made sure engineers were not the first point of contact for any alert. Any triage or resolution that an engineer can perform, a machine can be trained to do the same. We used supervised and unsupervised learning techniques to automate our toil. With a long-term goal of “no toil,” our SREs work on identifying and reducing toil to a manageable level across the organization.
2. Engineer alignment through roadmaps
   Our goal is to maximize the engineering velocity of developer teams while keeping products reliable. We want an engagement model where product, SRE and development teams are closely aligned. A key way we’ve been able to create this alignment is by having our SREs embedded into domain and product teams. Each domain has an SRE, who is  involved at the beginning stages of product development to ensure that the domain stakeholders are in alignment with the SRE initiatives. As such, SREs are able to improve the reliability, performance, scalability and launch velocity of the services throughout all phases of the service lifecycle. 
3. Adopt one-touch releases
   Our path to production used to contain many manual steps and validations, slowing the rate at which we released features. Additionally, we used to bulk all our releases together to deploy at once, which increased the risk of failure and created a longer feedback loop from production. To tackle this with an SRE mindset, we created a one-touch release process in which SREs review the product team’s pull requests. When approved, this triggers a DevSecOps pipeline that deploys the approved changes to production securely. This process created a safe, reliable and sustainable continuous delivery pipeline with quick feedback loops. Striking the right balance between speed, innovation and stability, we were able to increase our releases exponentially for the year, taking less than 30 minutes per release to deliver quality code, including various automated quality checks and processes, all in just one click. 
4. Embrace capacity planning
   To ensure our services have enough spare capacity to handle any surge in traffic patterns, our SREs emphasize capacity planning, making recommended capacity changes in the continuous delivery (CD) pipeline. They constantly monitor performance to make sure the service is robust, stable and available. And when there’s a sudden surge beyond the forecasted volume, SREs change the capacity on demand and document changes for the performance and domain teams. 

Capacity planning is especially important for us during peak holiday times such as Black Friday and Cyber Monday (BFCM). We lay out our SRE stability plan three months in advance and surface into the domain team’s product roadmap. This way development teams are able to allocate sufficient engineering time to reliability. We do performance testing to ensure the environment is able to sustain increased load over long periods of time and also handle sudden surges in traffic. We also do region failover testing at a global scale to validate the automatic failover duration of service level agreements  (SLAs), SRE and domain readiness. Additionally, we conduct Black Friday and Cyber Monday-specific destructive testing to validate customer experience, reliability and more.

Google Cloud’s Black Friday and Cyber Monday white-glove service played a key role in ensuring our success in both BFCM 2019 and BFCM 2020. This service included on-site visits from Google’s Customer Reliability Engineering (CRE) team who reviewed Lowe’s web architecture, capacity planning, operations practices for event risks, and presented workshops on topics such as incident response best practices. 

Looking ahead

There is always room for improvement, and at Lowe’s we aim to continuously improve our SRE practices. One thing that has worked well for us, which we plan to continue, has been our road shows, where senior SRE leads present to other SREs and application domain teams on the latest SRE principles and best practices, and to get input in real-time from them. 

Google’s tools and methodology have played an instrumental role in helping reshape our SRE practices and better serve our customers. We look forward to building on the momentum and partnership as we continue our SRE journey at Lowe’s. 

If you want to learn more about how to adopt SRE best practices on Google Cloud, check out our documentation. If you want to learn more about Google SRE, visit our website. Stay tuned for the next blogs with Lowe’s discussing how they trained their engineering talent to adopt SRE practices and tooling, and how they improved MTTR using SRE principles.

Most enterprise companies enforce strict requirements for how APIs should be exposed to the public internet that require centralized handling of the authentication credentials, the collection of metrics metrics and other classic API management capabilities. Before the introduction of sidecars in Cloud Run, developers either had to implement these requirements within the service itself or add a full-lifecycle API management platform in front of their service as described in a previous blog post.

In this post we want to demonstrate a new way to fulfill the requirement for API management in Cloud Run. Specifically we want to look at how the recently announced multi-container feature in Cloud Run enables a sidecar pattern that can be used by developers of Cloud Run services to add pre-packaged API management capabilities. This includes self-service developer onboarding in a developer portal, credential validation and quota enforcements. As an additional operational benefit the described solution also adds centralized analytics and metrics for APIs that are exposed via Cloud Run.

Our solution for adding API management capabilities for Cloud Run is provided by the following three components:

• The Cloud Run service that hosts a traditional RESTful web application and is fronted by a vanilla Envoy proxy.
• An Apigee Envoy Adapter aka. Remote service that runs in GKE Autopilot and acts as a policy decision point PDP for Envoy’s external authorization filter and is responsible for accepting or rejecting calls to the Cloud Run service.
• An Apigee API Platform that is used to manage the API lifecycle of the Cloud Run service. Apigee also offers a turn-key developer portal where developers can obtain access credentials to access an API.

The user journey of an incoming request to our new Cloud Run Service with API management looks as follows:

1. An API Developer self-registers in the Apigee Developer Portal and obtains access credentials for the API
2. They call the Cloud Run endpoint and provide their credential for authentication
3. In Cloud Run service the Envoy proxy container intercepts the request and initiates a gRPC call to the Apigee Envoy adapter to authenticate the client.
4. The Apigee Envoy adapter verifies the request’s credentials and identifies the corresponding API product as defined in Apigee. The Envoy adapter also verifies the call quota associated with the client and sends the analytics data and access logs back to the control plane.
5. If the credentials are valid and the client hasn’t exhausted their call quota the Apigee Envoy adapter forwards the request to its co-located container in the Cloud Run service.

The step by step instructions for how to configure the architecture above can be found in this blog post. 

Starting from a pre-existing Apigee installation the Apigee Envoy adapter is used to connect back to the Apigee runtime and control plane for accessing the API product definitions to link the incoming requests to the issued credentials and quotas. The Apigee remote service component can be replicated for high availability and is shared between multiple Cloud Run services that require a gRPC target for the sidecar’s external authorization filter.

The Cloud Run service connects to the Apigee Remote Service via an Envoy proxy that acts as a sidecar to the main application. The configuration for the envoy proxy can either be embedded within a customized Envoy image or mounted via the secret manager integration of cloud run as shown in the diagram above. Externalizing the configuration simplifies the maintenance and upgrade of the sidecar container as it can just pull the latest patch version of Envoy regularly.

The newly added API management capability is transparent for the primary application container within the Cloud Run service and does not require any changes in the application source code. Once the Cloud Run service is re-deployed with the sidecar in place, consuming applications can start to use credentials that they obtained via the Apigee API Management platform or the API developer portal to consume the Cloud Run service. At an operations level the platform operators will start to see requests to the Cloud Run service popping up in Apigee’s analytics dashboards and be able to track consumption and exposure at an API product level.

Next Steps

If you are interested in trying the multi-container support for Cloud Run yourself, check out the release announcement with many more use case descriptions. For another example and a detailed walkthrough on how to use sidecars in Cloud Run to report custom metrics to Google Cloud managed service for Prometheus you can head over to this tutorial in the Cloud Run documentation. Lastly, if you’re interested in the broader picture of how the latest features in Cloud Run are moving serverless forward, then make sure you check out this video.