What Comes After Microservices?

Good API trends can linger on for some time, but as with the decline of monolith, many love to anticipate the death of microservices through strangulation by its own distributed weight. While event-driven, circuit-breakers, GraphQL, and other leading patterns will continue to help us orchestrate successfully across this chaos, there are some other elements of our API operations that will be shaping what the API landscape looks like in the coming years.

I jokingly shared the photo above on Twitter, LinkedIn, and Mastodon, with the statement, “We have finished the transition from monolith to Microservices boss!”–it got quite a bit of attention. While many people commented on the chaotic view of it, and enjoyed emphasizing how microservices might not always be the best solution, I am more focused on what comes next–API standardization, governance, and regulations. It is what happened with electricity and telephone. While standards, governance, and regulation in these industries took on different shapes, what came next in this photo wasn’t business or technical, it was regulatory. Laws requiring that power and telecommunications companies invest in more standardization, and begin governing and regulating how power is generated and distributed, and how telecommunication networks were delivered–this is what is coming next for APIs and microservices.

I know in the United States that we love to hate on regulation, and us developers love to hate on governance. Many of us love to also love to reinvent the wheel rather than use exissting standards. However, we are all better off if we are competing on actual differentiating capabilities, and not reinventing the wheel with commoditized and cross-cutting digital resources like users, products, and other known and ubiquitous resources. This standardization will emerge in coming years at multiple levels, beginning at the team, moving to the domain, and enterprise organizational level, but then Internet and industry level standards will also continue to expand. I know many of us API providers like to think all of our APIs are special snowflake secret sauces, in reality, just a handful of what we are serving up are all that unique.

Let’s continue to move beyond the Wild West RESTish days, and begin to standardize the protocols and patterns we are employing, and begin establishing a common API contract, as well as product, lifecycle, and governance practices. We will all be better off for it. We will get to work on more of the cool and innovative frontline of this ever sprawling API landscape. So, instead of just voting for the demise of microservices and focusing on what comes next, let’s continue to do the work to standardize how we are working today—-ensuring things are more interoperable by default. I’ve been spending a lot of time reading about emergence and expansion of railroad, electricity, telephone, radio, air travel, and television regulation lately, studying and pondering ways that things might play out the same with API regulations, as well as the ways things might be entirely different.