In the API space, it’s almost ubiquitous to join the concept of the modern API with the microservice. Advice abounds, with fans claiming microservices architecture to be the best possible application of our coding ethos and our design conceptualization. Unfortunately, in some cases, adopting a microservice architecture may not be an effective business choice.

Microservices were envisioned to enable fast response and agile organization. Implemented in certain situations, they can actually have the inverse effect. There is no silver bullet approach, and advising a developer to adopt microservices without question may cause more harm than good.

Today, we’re going to talk about the nature of microservices in the current API industry. We’ll look at some theories as to how the current industry operates, and the economic realities therein. This article is a companion piece to this awesome presentation by Uwe Friedrichsen at the Nordic APIs 2018 Platform Summit — many of these concepts are arguable, but they represent an alternate view of microservices that should be considered in the context of the modern API space.

The Problem: Market Realities

“Supply is a lot higher in most markets than demand, which creates a very different situation [from traditional supply and demand models]. You no longer know how this product is going to be sold, which gives you a high degree of uncertainty”

We often lump SaaS within the context of traditional industrial economics. We typically frame the idea around supply and demand, in which the demand for effective solutions is the principal driver. This of course results in a situation in which the global market dictates the API solution and companies must move quickly, responding to ever-changing demands and requirements in order to remain competitive against smaller, leaner, faster companies.

It is perhaps easier to think about the modern economy outside of the scope of generalized trends, and more towards the specific drivers that underlie this process. In this post-industrial era, it is the adaptability of the organization, the flexibility, and speed that defines success.

IT Realities in Economic Context

“IT has become the business nervous system. The whole business DNA is coded into IT. We can’t think about IT and business as being separated anymore. They affect each other very closely.”

The problem is that, in terms of economics and business organization, the need for fast movement does not mesh with the complexity of the IT solutions and the business requirements that support them. In order to have agile, powerful, efficient, and complete solutions, your underlying business structures — and the IT resources it represents — become increasingly complex and unwieldy. In a sense, the more the industry develops, the greater this underlying IT cost, and thus business cost becomes.

Friedrichsen makes a salient point of this in his presentation and presents a simple, but a powerful, concept — we strive to control our IT of today based on the business concepts that we developed almost 50 years ago. This causes a wide array of issues, small and large, that microservices, in many cases, only perpetuate.

Microservices as an Organizational Issue

“If you really want to go fast, and you think about that from an organizational point of view, you will end up with autonomous cross-functional teams with all the skills that you expose out to the market. The problem is they also have IT assets in there. [Accordingly] they have to coordinate all the time with each other if they want to touch anything; this makes them slow, this cross-coordination. IT building blocks should not cause team boundaries — and that’s basically the whole story of microservices, that’s 95% of it.”

This rising complexity is actually the chief problem at hand. In order to move fast and to offer these powerful solutions, you must have cross-functional teams. In order to have these teams, though, you end up having IT assets exposed over a large surface area, and any change to the underlying code has a resultant IT asset that needs to be moved or manipulated. This coordination then makes the teams slow, which is what we were trying to avoid in the first place!

The problem is that microservices inherently require this spread of assets — that’s the entire point of microservices, to have each service cordoned off, in its own universe, with a complete backing behind it. This is a chief concern in terms of organizational planning, and ultimately, according to Friedrichsen, it becomes a concern in terms of business planning and development.

Expectations Drive Interaction

“Customer expectations — well, they have to be great. Adapt to their needs, be fast, always there … Give me a cool experience or I’m gone.”

All of this comes down to a single salient point – without proper user experience driven by positive experience and customer interaction, your API will fail. In order to do this without bloat, microservices cordons off resources and functions. By doing this, you, in turn, make it harder to grow as complexity increases, which in the end can result in slower development, and worsened experience.

What’s the solution, then?

What Should We Do With Microservices Now?

Friedrichsen suggests we redefine what exactly microservices are. Instead of viewing microservices as a defacto solution, perhaps we should frame it as a stepping stone. Friedrichsen states:

“Microservices are a transitional step. We use them to speed up, to support this organizational autonomy. But they come at a price, and the price is high. They’re really hard to master. They’re distributed by default, and distributed systems are hard. We need a lot more support to run them correctly, and a lot more tooling. We haven’t solved any business problem yet — we need all that just to make it work somewhere.”

There’s some reason to believe this – and in many situations, the fact that the system is distributed can, in fact, be more problematic than any other organization. This complexity, an endless fracturing of organizational structure, can result in slowness and poor user experience.

More than anything, though, this concept is based upon the idea of intellectual overload. What promises faster development and less production stress results in the inverse, and causes the load upon the organization and the developers to increase without a resulting payoff.

Reducing Intellectual Overload

“How can we reduce intellectual overload? I propose serverless. It’s the managed services that make the difference.”

One answer to this problem is to pivot away from microservices, and instead adopt the next logical process — the serverless environment. Serverless has a lot of things going for it, and in many cases, these benefits resolve much of the negative aspects of the microservice approach.

First and foremost, serverless essentially leverages infrastructure as a managed service. By decoupling your IT assets from your underlying code base, you reduce the complexity of managing these resources and remove the IT nightmare from the equation. This allows you to be a microservice without actually depending on the underlying IT assets as a business resource, and thereby removes much of the limitations discussed.

In fact, this offloading of resources is not just isolated to the IT realm – many of the business services and the development and production tooling can be moved into a serverless environment. The remaining microservices can then be run on these rented resources, thereby increasing revenue while decreasing cost, and improving speed while decreasing resource weight.

Caveats

“Is it all perfect in the world of serverless? No, of course not. Can it improve? Yes, it’s quite a young technology, but it will develop over time. It gets more and more mature every day.”

Serverless is powerful, but it’s not the solution to end all problems. In fact, while Friedrichsen’s points are salient and well-researched, there are some cases (such as a small organization) in which serverless may not be appropriate. With that being said, the fundamental issues with microservices exist, and whether they affect you or not really boils down to the size of your organization and the complexity of your IT resource pool.

Accordingly, even if you don’t adopt serverless, you need to figure out some solution. This may take any variety of forms, but ultimately, serverless is perhaps the easier of these solutions, both in terms of implementation and maintenance.

Conclusion

Ultimately, whether serverless is the answer for you or not, many of the business concerns elucidated here are justified. Serverless is an easy, powerful, and growing technological solution that still requires some development. These issues need to be seriously considered for any microservice offering within the business contextualization and common sense that underlies it.

What do you think about serverless? Is it as strong a solution as Friedrichsen suggests? Are the business issues justified? Let us know below!