When some of Twitter’s microservices were retired by the company’s current CEO, some users reported that they couldn’t log in immediately afterward. Elon Musk referred to the microservices that were shut down as “bloatware,” but the move caused a setback in the two-factor authentication used by some to log in. Twitter eventually resolved the situation, but the role of microservices within the IT architecture was called into question.
In Twitter’s case, silencing these microservices was like pulling a tangled thread that unraveled some important knots. Other organizations may wonder if they can live without microservices or if they are too tightly coupled to their operations to abandon them.
Pulumi CEO Joe Duffy spoke with InformationWeek about how microservices fit into the IT architecture, the benefits they provide, and how they can become a kind of legacy technology debt — if IT leaders aren’t careful.
Where do microservices fit into the IT architecture?
There is a spectrum in my mind, from monolithic architectures to fully distributed architectures. Microservices lie somewhere along that spectrum, closer to fully distributed architectures. The cloud has enabled us to think about things in a new way. Think about truly distributed application architectures, where we move from the era of “two virtual machines and a database” — where we’re coming from — to full distribution, using managed services, using containers, use serverless architecture; and microservices are central to that part.
The modern cloud has really accelerated the move towards those architectures. There are benefits and drawbacks to those architectures. There are a lot more moving parts, a lot more complexity, and yet microservices offer a way to mitigate some of the complexity by putting services behind API boundaries. Amazon was very famous in the early days because Jeff Bezos wanted the way teams communicated was through APIs. This created this notion that each team was running a different service and the service was connected through software; APIs, not human beings. This helps different teams move independently and codify the contract between teams, and yet there is no doubt that it can be massively overdone and used as a means to sweep complexity under the rug and pretend it doesn’t exist.
Once behind an API, it’s easy to set it and forget it. The reality is that I see companies with thousands of microservices when they probably should have had five. It can definitely be exaggerated, but a spectrum is the way I think of it.
Does it become comparable to legacy IT where many things are layered?
It can. It’s easy to say, “This thing is working. There is an API. It’s just an API call away.” The fact that it’s abstracted behind a microservice is a good thing because you don’t have to think about it regularly anymore, how to use it. It just works. It could be a legacy system. It may be a system that is no longer adding value. That’s also the benefit — you don’t have to think of it as a giant, monolithic system that can’t fit in any one person’s head. You can really share the different features of the platform. Place it behind the API and microservice. However, this legacy, this debt, tends to accumulate over time.
Has there been a call to improve microservices and alleviate headaches in this space?
As with everything, there is the Gartner hype cycle – the peak of inflated expectations, the valley of disappointment. We’ve probably crossed the line when it comes to microservices, but there’s definitely a lot of excitement around it and maybe, frankly, people are adopting it where it wasn’t appropriate. Or adopting it to a degree that didn’t make sense. I see similar things with Kubernetes; everyone wants to rub some Kubernetes on it, and sometimes that’s not the right approach for a certain scale of the problem. Microservices is a little further along in that hype cycle.
Sometimes it helps to go back to the basics. What are we actually trying to achieve with this system? Once you have, say, 1,000 microservices, it’s easy to lose the plot and say, “What was the functionality we were trying to provide? And what is the most effective way to architect this system?” Sometimes with microservices, it can grow very organically. You create a service; you ship the service and put an API in front of it. You start calling the API and then build new services. It creates this web of interdependence. Interrelated.
Monolithic isn’t a bad thing if the monolithic gets the job done, but it can start to become a bottleneck with squad scale. It’s a balance. Neither extreme is the right answer.
Are there ideal situations where introducing microservices makes more sense? Conversely, are there times when it is not the way to go?
A clear example of where it has worked well is Amazon Web Services. If you look at their product portfolio, it’s a collection of 400 different, discrete services, each with its own API. The way Amazon organizes internally, teams are empowered to own their product, their service. That’s a clear business stretch where, if they didn’t do it that way, I don’t think they could have built the platform the way they did.
You see something that might be more of a gray area, like Stripe. Stripe is a collection of services, it has a collection of products. The authentication service, I’m sure, is different from the credit card billing and metering service, which is separate from the reporting and analytics service. Which makes sense. It’s more of an implementation detail of how they ship their product. It would be easy to take it too far, but my impression is that they probably struck the right balance.
The simpler the product and the more monolithic the product is in nature, the less need there is to break it up into lots and lots of discrete services.
What happens if a company is deep with microservices, but the plug is pulled?
These types of architecture decisions are difficult to undo in a moment. They tend to be pretty deep issues. Part of the benefit of microservices is that things are physically separate, often running on different servers, and separated by an API. Those APIs obviously have performance implications.
To undo it really requires deep thought: “Does this mean we shut down all the services because we didn’t need them after all?” This wasn’t really a problem with microservices, per se. It was probably easier to ignore this with microservices, but this was a problem with how you ran your software in the first place. Why did you have services you didn’t need? If you’re going to keep them and consolidate them, that’s a pretty big architectural change.
What to read next:
Could Elon Musk’s Staff Create a ‘Twitter Mafia?’
Why Fiserv Turned to Microservices for API Development
What you need to know when migrating DevOps to Microservice Architectures
