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.

The benefits of APIs are becoming more clear in an ever-evolving tech landscape, yet ITDMs still struggle to convince executives and investors to buy into an API-first strategy. Here’s a look at the importance of APIs in a changing world, and how ITDMs can make the business case in order to secure the best API strategy for their organization.

According to Google Cloud’s new “State of the API Economy 2021” report, a majority of IT decision-makers view application programming interfaces, or APIs, as essential ingredients in improved customers experiences, expanded partner engagement, accelerated innovation, and other demands of today’s business environment. This is encouraging: APIs are how software talks to other software, and since much of digital transformation involves combining disparate data and functionality into rich user experiences and process automations, APIs are an essential ingredient in modern business strategies. 

What’s less encouraging: the research surveys primarily IT professionals, not business leaders. It’s clear that IT people see the benefits of APIs in the ever-changing tech landscape, but we still hear regular concerns from these same people that they have trouble convincing executives and investors to buy into an API-first strategy. In this article, we’ll look into why they are having these difficulties and some proven ways to successfully position an API strategy not just as a technological solution, but also as a business requirement.

The importance of APIs in a changing world

The rise of APIs has been heavily influenced by the introduction of disruptive new business models and evolving customer preferences that traditional technologies are not positioned to quickly and efficiently address. 

For example, traditionally, if your business sold tickets to events, it would build physical ticket booths and maybe a website or first-party mobile app. Today, tickets in many cases aren’t so much a physical thing presented to an usher as a digital code that an usher scans. Likewise, tickets are less-often purchased in person as opposed to online, and reliance on a first-party website can be unnecessarily restrictive. It places the burden on the business to attract customers, whereas surfacing organically in social media, search engine results, and other digital experiences lets the business meet customers where they’re already assembled. 

Moreover, as COVID-19 continues to disrupt events throughout the world, many ticket sellers—and most organizations, for that matter—have pivoted to digital-first business interactions as a matter of necessity. All of these changes in the business model, and all of the interacting systems and functionality that underpin them, rely on communication among APIs. 

Similarly, today’s banks cannot grow by simply building more branches or hiring more tellers. Instead, they need to make financial information and functionality available when and where customers require it, whether that means via an ATM, a first-party app, or within some other digital experience. Many banks also need to do more than just present this functionality, as customers are increasingly interested in the analytics and insights their spending patterns can yield. Again, all of these interactions—from customers making a purchase within an app to banks applying machine learning in order to offer customers financial insights—are enabled by APIs.     

Related: The “State of API Economy 2021” report describes how digital transformation initiatives evolved throughout 2020, as well as where they’re headed in the years to come. Download for free.

When guidance meets resistance

These examples do not illustrate technology that updates the status quo, but rather technology that unlocks business opportunities that transcend the status quo—and that help businesses to thrive even as the status quo fades into irrelevance and obsolescence. APIs are thus not just an IT topic but also important business enablers that should be understood by everyone involved with the enterprise’s investments, from internal stakeholders approving business strategies to external shareholders trying to assess an organization’s trajectory. 

The challenge for investor relations is to convey these financial and operational benefits in a way that clearly communicates the need for a new business model rather than refinements to the existing models. It’s essential that IT professionals understand APIs, but it’s also essential for business leaders to understand them too.

This is even trickier given that arguments for API investments are often based on future potential, while arguments for more conservative alternatives are based on past success. 

At a high level, the API value proposition is clear: In the past, valuable functionality and data have been encased in systems and applications, making them difficult to scale or leverage for new, evolving use cases. In contrast, APIs make functionality and data infinitely reusable, infinitely scalable, and modular such that APIs can easily be combined for new uses. All of this accrues to richer user experiences and more flexibility than ever for companies to monetize their digital assets, share them with partners, or combine them with assets from third parties. 

It’s essential that IT professionals understand APIs, but it’s also essential for business leaders to understand them too.

But investors typically want as much information as possible because their decisions can affect not just productivity and output, but company stock prices and potential future growth. High-level arguments may not be persuasive. The deeper assurances investors crave would normally come from guidance.

Guidance in this context refers to insights based on growth forecasts and customer adoption, but this can be difficult early in market entry. Robust forecasting processes need to be developed to demonstrate the efficacy and value of the API economy, which can be hard to predict: whereas APIs are well understood in some sectors, and especially among digital natives, they are in the early stages of the growth rate in other verticals, making it challenging to forecast developer adoption of a given API. And since there is a shortage of information, trying to use traditional guidance comes with a risk of being wrong and thus of little value to investors.

Related: Set your 2021 API resolutions with these top 2020 posts.

How to deliver a more useful value proposition

While guidance may be premature during the early stages of market entry, investor relations teams still need to convey the full value of an enterprise to investors. To do this, they need a value proposition that emphasizes the intrinsic value of the investment while reinforcing the benefits that can best drive business and stock growth. Considering how large an investment of time, effort, and money transitioning to an API economy can be, it is vital to convey that the benefits are substantial.

A solid value proposition should demonstrate maximum returns, and while this shouldn’t include far-fetched or unobtainable claims, it can include reasonable aspirational visions alongside statistical insights. To craft these aspirational narratives, investor relations teams should look to their organization’s existing business needs and challenges, and then demonstrate how APIs can benefit the organization in these areas. Here are some options that speak to a number of common business requirements:

• Sales channel: API investments are reusable, improve speed to market, enable automated processes and partner onboarding, and can uncover unanticipated opportunities.
• Cost: Businesses can reduce operational costs by using and reusing APIs for innovation and business development, and by using the services native to your partner’s digital surface, you can further reduce innovation costs and risks.
• Earnings: API-enabled digital ecosystems unlock a variety of partner services that leverage the business’s shared data to drive new customer acquisition, new market positions, new transaction volumes, and direct API monetization.
• Risk mitigation: By investing in a credible API, businesses can mitigate downside risks that traditional enterprises can face from market disruptors, industry-wide shifts to digital tools, and inabilities to ingest and analyze growing data sources.
• Intellectual property: Unlike project-driven innovation and customized, point-to-point integration that traps enterprise knowledge in small teams and divisional silos, APIs are reusable and modular, breaking down silos and encouraging intra-organizational collaboration.
• Speed to market: The efficient, repeatable API interface informs improvements to the fulfillment process with consistent access to data from across the organization, which drives solutions that more quickly and efficiently meet customer needs.
• Ethics: APIs offer the flexibility and economical advantages that give organizations the capacity to focus on their brand’s ethical “reason for being” beyond profitability by serving economically marginal and underserved market segments.
• Customer credibility: Organizations can deliver the extended, connected digital experiences that customers expect with the tools and flexibility included with API products.
• Employee retention: Businesses can avoid losing key employees by updating their legacy technologies with APIs, giving employees the opportunity to enhance their skills with modern technologies.
• Corporate strategy: Enterprises that use APIs’ reusable, modular structure and tools are more capable of adapting to rapid structural shifts in customer demand patterns and sectoral changes in the economy.

Whichever of these business challenges a team speaks to, it is imperative that they demonstrate the benefits of APIs, and that once they’ve determined the angle they intend to use, they keep their message consistent. While we’ve seen a number of viable ways to position APIs as a winning strategy, switching among them could make the presentation—and APIs in general—seem insubstantial and unreliable. 

This is why it’s key to decide on the most relevant business concerns, and once you’ve tailored your presentation, to make sure that you have message alignment, including buy-in and support from C-level executives. With a strong pitch built around solving existing business concerns and solidarity from relevant stakeholders, you can go into your investor meeting with the confidence to secure the best API strategy for your organization.

Strengthen your pitch with additional insights. Here are five key trends in 2021 for API-first digital transformation.

About the Author: Paul Rohan is a researcher on Open Banking and a Google Cloud solutions consultant. Paul works with banking C-Suites that are examining the impact of the Platform Economy and Digital Ecosystems on financial services industry growth, market structures and governance. Paul is the author of “PSD2 in Plain English” and “Open Banking Strategy Formation”.

APIs are the backbone of digital transformation. Via APIs, you can securely share data and functionality with developers both inside and outside of your organizational boundaries, letting you build applications faster, seamlessly connect and interact with partners, and drive new business revenue. 

Because APIs encompass business-critical information, any downtime or performance degradation can lead to significant loss in revenue, customers, and brand value. Therefore, there’s mounting pressure on operations teams to ensure that APIs are always available and performing as expected. If the APIs go down, so too do the services that fuel customer experiences and on which the organization relies for collaboration and business processes.

However, as you build and scale your API programs, it becomes practically impossible for API operators to manually monitor and manage all your APIs. To help, we brought the power of industry-leading AI and ML technologies to API operations via Apigee X, a major release of our API management platform. Apigee X seamlessly weaves together Google Cloud’s expertise in AI, security and networking to help you efficiently build and manage APIs at scale. 

Put your API data into action

Apigee applies machine learning to your API metadata and provides you the required tools that simplify various aspects of API operations. A great example of AI for APIs is anomaly detection: 

• AI-powered rules trigger alerts based on a set of predefined conditions that are determined by applying Google’s industry-leading machine learning models to your historical API data.
• Auto-thresholds adjust the monitoring criteria of your APIs and set them to pattern-based values. 
• Reduce overhead results because operators don’t have to manually monitor anomalies or adjust the monitoring thresholds on APIs.

“By applying AI and ML models to our historical API data, these advanced features are able to alert us about scenarios we haven’t thought of. Such automation capabilities significantly reduce our upfront efforts. And from a security perspective, the actionable insights help us ensure that our proxies are exposed only over secure HTTPs ports and adhere to compliance requirements. We’re also able to closely monitor user activity and quickly pull out reports during audits.” – Adam Brancato, Sr. Manager, Global Technology and Security at Citrix

As our customers scale their API programs, they find it extremely useful to harness AI-powered capabilities.  In our recent State of the API Economy 2021 report, we found a 230% increase in enterprises’ use of anomaly detection, bot protection, and security analytics features.

To learn more about Apigee X, and see AI and machine learning in action, check out this video, and to try Apigee X for free, click here.

On April 6th, 2022, Google Cloud established a new partnership with CAST, to help accelerate the migration and application modernization programs of customers worldwide, complementing the Google capabilities already available through the Google Cloud Application Modernization Program (CAMP).

Application Rationalization (App Rat) is the first step towards a cloud adoption or migration journey, through which you go over the application inventory to determine which applications should be Retired, Retained, Refactored, Replatformed, or Reimagined.

Why is this important to you?

Have the majority of your in-house applications still not moved to the cloud? How much time does your development team spend on support (bug fix, tickets, etc.) versus feature(s) development? Have Infrastructure/Platform dependencies ever delayed product rollout? Would an auto-scalable, managed cloud, increase stakeholder buy-in?

Can Google simplify this journey?

Google Cloud Application Modernization Program (CAMP) has been designed as an end-to-end framework to help guide organizations through their modernization journey by assessing where they are today, and provide a path forward. When it comes to App Rationalization, this depends on what your role is.

Step 1 (Assess): Who is the target audience? The Platform team (or) the Application team?

This determines what kind of challenges we are trying to solve. For e.g. the centralized platform team wants to set some guardrails on how the App teams deploy their apps. Streamlining this would allow the platform team to mature themselves into the SRE territory. The application team, on the other hand, loves flexibility, and the ability to perform Continuous Delivery.

These examples are only the tip of the iceberg. Most of the enterprise customers have a majority of their applications in the legacy world. Unless we move those business critical applications to the cloud, it’s impossible to mature as an enterprise. For more information, check State of DevOps 2021 report.

Step 2 (Analyze): Google Cloud offers the tooling and the framework to analyze your legacy applications.

Platform Owner (persona), usually have very little information on which workloads are a good fit for modernization.

Google’s StratoZone® SaaS platform provides customers with a data-driven cloud decision framework. The StratoProbe® Data Collector Application delivers the ability to easily deploy and scale the discovery of a customer’s IT environment for Private, Public, or Hybrid-cloud planning. To ease and accelerate the VM migration journey, Google Cloud offers assistance and guidance in making the right decisions when deciding to go to cloud.

Google’s mFit aims at unblocking customers in their transformation by providing workload selection for successful on-boarding, at scale, to Anthos, GKE and Cloud Run , in both pre-sales (e.g. proof-of-concept/proof-of-value) and post-sales (e.g. pilot and at scale execution) scenarios.

App and/or Business Owners (persona), get involved in a 1-week workshop, using CAST Highlight, which would provide rapid portfolio assessment through automated source code analysis for Cloud Readiness, Open Source risks, Resiliency, and Agility.

Step 3 (Plan & execute): Each organization is different. Some may follow the “Migration Factory” approach, and some may follow “Modernization Factory”, and some may follow both. Irrespective of which approach you choose to follow, it is important to plan just enough, so that you can start your execution. Ensure to set the OKRs, that would help with the right measurements, before you start the execution. The actual learning from the execution helps the team(s) to learn more about the cloud migration process, and refine it based on their organization.

Using CAST Highlight in the assessment step previously, we get the recommendation for the analyzed applications. From there, for certain workloads, we can use Migrate to Containers, to automate the containerization of suitable workloads. However, there are certain applications that require manual code changes. You have a few options for that,

• Our experts can help you get started.
• Our partners can help you

Step 4 (Measure & reiterate): Measure the progress using the predefined metrics in the previous step. Celebrate the wins. Consistently share the learnings and best practices with the developer community. Pick the next challenge

Take the next step

Tell us what you’re solving for. A Google Cloud expert will help you find the best solution.

For years, Google has been committed to maximizing developer productivity. In 2019, we announced the general availability of Skaffold, a command-line tool that facilitates continuous development and delivery for containerized applications. Today, we’re excited to announce that Skaffold V2 is now generally available.

Skaffold V2 expands Skaffold’s supported platforms and architectures with the introduction of Cloud Run as a supported deployer, and now supports building from and deploying to both ARM and x86 architectures. Skaffold V2 also offers enhanced support for CI/CD and GitOps workflows, with the introduction of the skaffold render phase, verify phase, and kpt integration. Best of all, all existing Skaffold configurations are fully compatible with Skaffold V2, and upgrading from V1 is as easy as running skaffold fix.

Expanded platform support

Since its inception, Skaffold has supported deploying applications to Kubernetes, using either kubectl or Helm deployers. Deploying to Kubernetes with Skaffold unlocks the benefits of improved velocity from source to prod, with reusable building blocks for iterative development and CI/CD.

We’re excited to expand these benefits to Cloud Run, Google’s serverless container runtime. Cloud Run provides a fully managed platform for any containerized application, and includes features such as automatic resource scaling and integrated storage, security, and monitoring solutions.

It’s easy to get started with Skaffold and Cloud Run; all you need is a Cloud Run service config and a few small updates to your skaffold.yaml. Skaffold also powers Cloud Deploy’s support of Cloud Run. Check out our documentation to learn more.

In addition to the new deployment target, the expanded set of compatible image-architecture configurations with Skaffold V2 helps developers ensure that the architecture of the machine on which an image is built is compatible with the architecture of the machine on which the image is intended to be run. Skaffold now intelligently checks the architecture of your local machine as well as the target Kubernetes cluster before building your images, allowing you to deploy to ARM, x86 or multi-arch clusters from a x86 or ARM machine without any manual configuration.

Check out our documentation to learn more about deploying to Cloud Run and managing ARM workloads.

CI/CD and DevOps, simplified

Skaffold helps developers implement CI/CD and DevOps workflows by providing a set of reusable building blocks for repeatable build, tag, and deploy steps. With Skaffold, the same config can be shared in development and production, leveraging Skaffold profiles to implement environment-specific configuration.

With Skaffold V2, the Skaffold render phase is now distinct from the deploy phase. The output of the Skaffold render phase is a manifest, hydrated with tagged image names and templated values, which can then be persisted in source control before deployment as part of a GitOps workflow.

In addition to the render phase, Skaffold V2’s new verify phase helps to configure post-deployment tests. This phase can be used to configure a series of test containers that are then monitored to ensure that the deployment was successful. This allows developers to integrate this verification step into reusable deployment pipelines rather than running these tests manually.

Finally, the introduction of kpt as a supported renderer in Skaffold V2 provides a sophisticated syntax for serially transforming and validating your manifests, unlocking additional customizability and verification in your GitOps workflows. Using Skaffold makes it easy to adopt kpt because you can take advantage of kpt’s transformation and validation functionality without needing to write any separate kpt configuration. It’s as easy as adding a few stanzas to your existing skaffold.yaml. Kpt can also be used alongside Skaffold’s pre-existing integrations with renderers Helm and Kustomize.

Check out our documentation to learn more about the Skaffold render phase, verify phase, and kpt integration.

Upgrading to Skaffold V2

Getting started with Skaffold V2 is easy. If you’re new to Skaffold, check out the V2 installation guide for platform-specific installation instructions.

If you’re an existing Skaffold user, upgrading to Skaffold V2 is simple and requires no manual configuration changes. All of your existing Skaffold configurations will continue to work as-is with Skaffold V2. Simply download the Skaffold V2 binary and run skaffold fix to update your config. Check out the V2 upgrade guide for more details.

Finally, check out our documentation for more detailed instructions on taking advantage of all of the new features introduced in Skaffold V2.

What’s next?

If you’re interested in harnessing the power of Skaffold for serverless workloads, check out our documentation for using Skaffold V2 with Cloud Run.

Also, be sure to check out Cloud Deploy, Google’s fully managed continuous delivery offering, which leverages Skaffold to construct reusable deployment pipelines.

We’re excited to hear from you. As always, you can reach out to us on GitHub and Slack.