Modernizing applications and APIs

Jules Baptiste has run Birchline's online shop for six years, and the hardest part of the job has never been the customers. It has been the software. The shop is one large application, built over a decade, where the product pages, the basket, the checkout, the loyalty points and the email confirmations all live in a single codebase and are released together. A small change to the loyalty points screen means testing everything, scheduling a release window late on a Sunday night and hoping nothing else breaks. Releases happen about once a month, and Jules has a list of improvements that would take a year to get through at that pace. This lesson follows how Birchline plans to modernize the shop, and why APIs have become one of the most important business assets a company can build.

From one big application to many small services

An application built as a single unit is often called a monolith. Monoliths are not bad in themselves: they are simple to start, easy to understand when small, and many successful systems run as monoliths. The trouble begins as they grow. Every change touches a shared codebase, so teams wait for each other. The whole application must scale together, even if only the product search is busy. And one faulty component can bring down everything, so a bug in loyalty points can stop customers from checking out.

Modern application development breaks large applications into microservices: small, independent services, each owning one business capability and its own data, communicating through well-defined APIs. Birchline's shop will eventually become a set of services such as product catalog, search, basket, checkout, loyalty and notifications. Each can be developed by its own small team, released on its own schedule, scaled on its own and run with its own choice of managed service. If the loyalty service fails, the checkout can carry on and award points later.

The exam guide highlights four qualities of modern applications. They use microservices so that parts change independently. They lean on managed services, such as Cloud SQL, Pub/Sub and Cloud Run, so teams spend less time operating infrastructure. They are scalable, adding capacity for just the parts that need it. And they are resilient, designed to keep working when individual components fail, for example by retrying requests, queuing work in Pub/Sub and running in several zones.

Microservices carry costs too. There are more moving parts to monitor, more network calls that can fail, and more need for clear contracts between teams. Farah warned the committee against breaking the shop into dozens of services overnight. Birchline will use a gradual approach sometimes called the strangler pattern: new features are built as separate services, and old parts of the monolith are replaced one at a time, starting with the ones that change most often or suffer most under load, until little of the original remains.

Releasing changes quickly and safely

Microservices pay off only if teams can release them easily. Modern teams use continuous integration and continuous delivery (CI/CD): every code change is automatically built, tested and prepared for release, and approved changes are deployed automatically, often many times a day. Google Cloud offers tools for this, such as Cloud Build for automated builds and tests and Artifact Registry for storing container images, but the exam is more interested in the business effect. Smaller, frequent releases are less risky than large, rare ones, because each change is small enough to understand and quick to undo.

These practices are part of DevOps, a culture and set of practices that bring development and operations teams together, share responsibility for running software and automate as much of the path from idea to production as possible. Lesson 11 covers DevOps and the related discipline of site reliability engineering in more detail. For Jules, the promise is concrete: instead of one risky release a month, the checkout team should be able to release small improvements every week and measure their effect on sales the next day.

What an API is

An application programming interface (API) is a defined way for one piece of software to request data or actions from another. It specifies what can be asked, how to ask and what will come back, without revealing how the other system works inside. When the shop's basket service needs a product's price, it calls the catalog service's API; when a customer's phone app shows store stock, it calls an inventory API. Most modern APIs work over the web, using the same protocols as a browser, and exchange data in formats such as JSON.

A good analogy is a restaurant menu. Customers do not walk into the kitchen; they choose from a menu, and the kitchen returns a dish. The menu is the API: it lists what can be ordered and what to expect, and the kitchen can change its equipment or its staff without customers noticing, as long as the menu still works. APIs give organizations the same freedom: the systems behind an API can be modernized, moved to the cloud or replaced, while everything that uses the API keeps working.

APIs as a business opportunity

Once an organization's capabilities are available through APIs, they can be used in ways the original systems never imagined. Internally, APIs let teams reuse each other's work rather than rebuilding it: the same inventory API serves the website, the mobile app, the store tablets and the analytics pipeline. Externally, exposing APIs to partners opens new channels. Birchline's tent and kayak suppliers could check sell-through through an API instead of waiting for monthly spreadsheets; a trail-guide app could show Birchline gear recommendations for each route; and outdoor clubs could let members book Birchline's rental gear from the club's own website.

Some organizations go further and monetize APIs, charging partners for access, often in tiers by volume or features. A weather company sells forecast data through APIs; a payments company earns a fee per transaction processed through its API. Even where no fee is charged, APIs can create value indirectly by bringing in sales, strengthening partnerships or reducing the cost of serving partners manually. The exam expects you to recognize these opportunities and to understand that APIs must be managed like products: designed for their users, documented, secured, measured and supported.

# Estimating monthly revenue from a tiered partner API (invented prices and usage).
tiers = [("Free", 10_000, 0.0), ("Standard", 1_000_000, 0.0004), ("High volume", None, 0.00025)]
partners = {"Trail app": 2_400_000, "Outdoor club": 8_000, "Kayak supplier": 650_000}
def monthly_fee(calls):
    fee, used = 0.0, 0
    for name, limit, price in tiers:
        top = calls if limit is None else min(calls, limit)
        if top > used:
            fee += (top - used) * price
            used = top
    return fee
for partner, calls in partners.items():
    print(f"{partner:15} {calls:>9,} calls  fee {monthly_fee(calls):8.2f}")
print("Total:", round(sum(monthly_fee(c) for c in partners.values()), 2))

Trail app       2,400,000 calls  fee   746.00
Outdoor club        8,000 calls  fee     0.00
Kayak supplier    650,000 calls  fee   256.00
Total: 1002.0

Apigee API Management

Publishing APIs to partners raises practical questions. Who is allowed to call them? How many calls may each partner make? How are keys issued and revoked? How does Birchline know which APIs are popular, which are slow and which partners are approaching their limits? How are charges calculated? Apigee is Google Cloud's API management platform, designed to answer exactly these questions. It sits in front of an organization's APIs as a gateway and provides security (authentication, keys and threat protection), traffic management (quotas and rate limits so one partner cannot overwhelm the systems), analytics on usage and performance, a developer portal where partners can discover APIs, read documentation and sign up, and monetization features for charging by plan or by use.

Apigee also helps with modernization itself. Because it sits between callers and the systems behind the APIs, Birchline can move a backend from the old data center to Cloud Run without partners noticing, change versions gradually, and translate between older and newer formats. For a digital leader, the business value is that APIs become reliable, measurable products rather than one-off technical connections.

Designing APIs that people want to use

An API is only valuable if developers inside and outside the organization can use it without a support call. Farah gave the shop teams a few design habits that apply to any API. Name things in the language of the business rather than the database, so a partner asks for a product's stock at a store rather than a row in table INV_LOC. Keep responses predictable, with the same structure and error messages everywhere. Publish clear documentation with examples. Version the API, so that when the catalog team changes how sizes are described, existing partners keep working on the old version while they move to the new one. And design for security from the start: every caller identified, every request checked, and no more data returned than the caller needs.

These habits matter because an API is a promise. Once a partner has built an app on Birchline's inventory API, changing that API without warning breaks the partner's product and damages the relationship. Treating APIs as products, with owners, roadmaps and change notices, is what lets an organization open its capabilities to others with confidence. Jules has added an "API owner" role to each service team so that someone is always accountable for the experience of the developers who use it.

Measuring the modernization

Dana asked how the committee would know whether modernizing the shop was worth the effort. Farah suggested four measures that the DevOps research community has used for years to describe software delivery performance: how often the team releases (deployment frequency), how long a change takes from code to customers (lead time for changes), how often a release causes a problem in production (change failure rate) and how quickly service is restored when something goes wrong (time to restore service). Today the shop releases monthly, changes take weeks to reach customers, about one release in four causes a problem and recovery can take most of a night.

Birchline set targets for the end of 2027: weekly releases for the checkout and search services, lead times measured in days, fewer than one problem release in ten and recovery within an hour. Alongside these technical measures, Jules will track business ones: how many improvements from the backlog reach customers each quarter, conversion rates on the checkout pages and the number of partners using Birchline's APIs. Modernization is judged a success only if both sets of numbers move.