State of the API: Microservices Gone Macro and Zombie APIs

Microservices expanding into unwieldy messes and zombie APIs were among the concerns that emerged from this year’s Postman State of the API survey. But even with those problems, the survey also found that APIs are paying off for organizations — almost two-thirds of the 40,000 respondents said their APIs generate revenue.

Forty-three percent said APIs generate over a quarter of company revenue. For a handful of companies, APIs generated more than 75% of total revenue. These companies were almost twice as likely to be in financial services as other sectors, the report stated.

Given API profitability, it’s not hard to see why 92% of global respondents say that API investments will increase or stay the same over the next 12 months. That’s up three percentage points from last year’s report.

“This increase may reflect a sense in some quarters that the worst of tech’s economic contraction has passed,” the report noted. “At the same time, fewer respondents say they expect to cut investments into APIs this year.”

Microservices, Mesoservices, and Monoliths

Microservices remain the dominant architectural style of APIs at the majority of organizations, but it seems that doesn’t always go as planned. In this year’s report, 10% of respondents said that APIs powering microservices have grown large and unwieldy, creating “macroservices” instead of microservices.

Microservices was defined as small services working independently to carry out single responsibilities, while macroservices were defined as being microservices that have grown large and unwieldy, approaching monoliths. Monoliths are single-tiered apps in which the interface and data access are combined into one package. Finally, mesoservices are Goldilock’s preference: not too big, not too small — just right.

Monoliths and mesoservices each represent a little over 20% of organizations surveyed.

“There is obviously observations that have come in from a decade of microservices going mainstream and how companies are thinking about it,” Ankit Sobti, co-founder and CTO of Postman, told The New Stack. “The idea of microservices that grow and become unwieldy and lose the essence of being a microservice in the first place is something that we wanted to call out through the survey.”

One reason to use microservices is that in theory, the microservice and its API could be reused easier. So it’s worth noting that related to that, 21% of self-identified “API first” leaders cited reusing APIs or microservices as a pain point for their organizations.

“The aspect of reusability is how consumable is the API, and the struggle that we see when we talk to customers is outside of discovering the API in the first place,” Sobti said. “Is the API consistent, conformant, and easy to just set up? Authentication ends up being a big problem in just starting out with API. So I think those factors that drive the consumption of the API make a big difference in the way that the API’s are difficult to integrate in the network.”

Zombie APIs Rise as Layoffs Happen

Nearly 60% of all respondents are concerned over zombie APIs — APIs that lack proper documentation and ownership, but persist after a developer has left the organization. It ranked as the second leading concern when developers leave, behind poor documentation. Engineers and developers ranked zombie APIs as a higher concern than executives did, who placed “loss of institutional memory” as slightly more concerning than loss of maintenance, aka zombie APIs.

“These APIs have no owner, oversight, or maintenance — and are sometimes forgotten by the company,” the report noted. “At worst, zombie APIs pose a security risk; at best, they deliver a poor consumer experience.”

One solution is to maintain a catalog of APIs used, suggested Sobti.

“That’s the emergence of zombie APIs, because a lot of institutional knowledge lies with the people who built it,” Sobti told The New Stack. “Once the people transition out, the change management is complex, and that’s where cataloging your API has internal APIs, in particular, becomes very critical.”

API catalogs can keep track of internal APIs in one place, he added. There are dedicated teams that are now responsible for not just building the underlying infrastructure that allows the catalogs to exist, but also managing the catalog and creating the practices on building to get those APIs into the catalogs. That is where reuse becomes critical, he added.

As further proof of the need for better documentation, the survey found that a lack of documentation was cited as the primary obstacle to consuming an API.

Fewer than one in 20 API changes fail, according to half of respondents. Among industries, healthcare claimed the best rate, with 55% of respondents stating that fewer than one in 20 API deployments failed. Education was at the other end of the spectrum; only 43% of respondents there said their failure rate was that good. Perhaps that ties to another key finding: Education was also the sector likeliest to skip API testing and spend the last amount of time on API development.

API-first leaders were less likely to encounter failures than all respondents, with 60% stating that failures occurred less than one time in 20.

API-First Development

The report also noticed a trend for what it terms API-first companies to perform better across a variety of API issues than companies that are not API-first. API-first companies prioritize APIs at the start of development process, positioning APIs as the building blocks of software. Over 75% of respondents somewhat agreed or strongly agreed that developers at API-first companies are more productive, create better software, and integrate faster with partners.

Being API-first means developing APIs before writing other code, instead of treating them as afterthoughts, according to Postman, which defined the term for survey respondents.

“API-first companies are the ones that acknowledged that APIs are the building blocks of their software strategy,” Sobti said. “So you’re thinking of a development model where applications are conceptualized as this interconnection of internal and external services to these APIs. The API-first organizations are becoming more cognizant of the business and the technical implications of APIs.”

Companies are realizing the strategic value of APIs to the business: More companies reported that the API is generating a significant portion of the company’s revenues this year, he said. The survey also found that the revenue was the second most important metric of APIs access after usage itself. Benefits to API-first companies increase as the company size and developer numbers grow, the survey found.

“At small companies with 100 developers or fewer, 32% of respondents strongly agreed that API-first companies onboard faster. But as developer headcount rose above 100, that figure steadily climbed,” the report stated. “By the time a company reached 5,000 developers, 42% of its respondents strongly agreed with the statement. We see similar increases across almost all metrics when answers are sorted by company size.”

“Technically, what we see are API-first companies being ones that are able to build APIs faster, report fewer failures, and when APIs go down, they’re able to restore and respond in less than an hour,” he said. “What we see is APIs definitely increasing in number across organizations, both internally and externally, and a part of that is the ability to reuse more of the capabilities that have been created within your organization and also externally, that you can now either use or subscribe or buy.”

Leveraging reuse is what drives the ability of developers to do more with less, whether it’s doing less with fewer people, or because developers don’t have to create businesses functions because they can, for instance, subscribe to a Stripe and actually manage billing through Stripe’s API, he said.

GraphQL Improves Position as an API Architecture

The survey also found that while REST remains the most-used API architecture by far, it has lost a bit of ground to newcomers, the report noted. This year, 86% of respondents said they used REST, which is down from 89% last year’s report and 92% the year prior.

SOAP usage fell to 26% of all respondents this year versus 34% last year. Taking SOAP’s place is GraphQL, which was used by 29% of survey-takers.

When it comes to API specifications, JSON Schema is the favorite followed by Swagger/OpenAPI 2.0 and Open API 3.x tied almost evenly. GraphQL came in fourth in popularity.

Editor’s Note: On June 29, 2023, this piece was updated to show an updated specifications chart.