When some of Twitter’s microservices got pulled by the company’s current CEO, certain users reported they could not log in shortly after. Elon Musk referred to the microservices that got shuttered as “bloatware,” but the move caused a hiccup in two-factor authentication used by some to log in. Twitter eventually got the situation sorted, but the role of microservices within IT architecture came into question.
In Twitter’s case, silencing those microservices was like pulling on a tangled thread that undid a few crucial knots. Other organizations might wonder if they can live without microservices or if they are stitched too tightly into their operations to abandon.
Pulumi CEO Joe Duffy spoke with InformationWeek about how microservices fit into IT architecture, benefits they offer, and how they might become a type of legacy tech debt -- if IT leaders are not careful.
Where do microservices fit into IT architecture?
There’s a spectrum in my mind, all the way from monolithic architectures to fully distributed architectures. Microservices sit somewhere along that spectrum, closer to fully distributed architectures. The cloud has enabled us to think about things in a new way. Think about really distributed application architectures, where we go from having the “two virtual machines and a database” era -- which is where we’re coming from -- to fully distributed, using managed services, using containers, using serverless architectures; and microservices is central to that piece.
The modern cloud has really accelerated the move towards those architectures. There’s benefits and drawbacks to those architectures. There’s a lot more moving pieces, a lot more complexity, and yet microservices offers a way to tame some of the complexity by putting services behind API boundaries. Amazon was very famous in the early days because Jeff Bezos required the way teams communicate is through APIs. That created this notion that each team was running a different service and the service was connected through software; APIs, not human beings. That helps different teams move independently and codify the contract between the teams, and yet there is no question that it can be massively overdone and can be used as a tool to sweep complexity under the rug and pretend it doesn’t exist.
Once it’s behind an API, it’s easy to just set it and forget it. The reality is, I see companies with thousands of microservices when they probably should have had five. It can definitely be overdone, but a spectrum is the way I think of it.
Does it become comparable to legacy IT where many things get layered on?
It can. It’s easy to say, “This thing is running. It’s got an API. It’s just one API call away.” The fact that it’s abstracted behind a microservice is a good thing because you no longer have to think about that on a regular basis, how to operate it. It’s just kind of up and running. It may 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 about this like one giant, monolithic system, which can’t fit in any one person’s head. You can really compartmentalize the different features of the platform. Put it behind the API and microservice. Yet this legacy, this debt does tend to accumulate over time.
Has there been any call to streamline microservices and ease headaches in this space?
As with anything, there’s the Gartner hype cycle -- the peak of inflated expectations, the trough of disillusionment. We’ve probably passed the trough when it comes to microservices but there’s definitely a lot of excitement around this and probably, frankly, people adopting it where it wasn’t appropriate. Or adopting it to a degree that didn’t make sense. I see similar things with Kubernetes; everybody wants to rub a little Kubernetes on it and sometimes that’s not the right approach for a certain scale of problem. Microservices is a little bit further along in that hype cycle.
Sometimes it does help to go back to basics. What are we actually trying to accomplish with this system? Once you’ve got, say 1,000 microservices, it’s easy to lose the plot and say, “What was the functionality we were trying to deliver? And what is the most effective way to architect this system?” Sometimes with microservices, it can grow very organically. You create a service; you do ship the service and you put an API in front of it. You start calling the API and then build new services. It creates this web of interdependent. Of interconnected.
Monolithic is not a bad thing if monolithic gets the job done, but it can start to become a bottleneck as the team scales. It’s a balance. No one extreme is the right answer.
Are there ideal situations where it makes the most sense to introduce microservices? At the opposite end, are there instances where it is not the route to follow?
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 of which does have an API of its own. The way that Amazon organizes internally, teams are empowered to be owners of their product, of their service. That’s a clear business alignment where, if they didn’t operate that way, I don’t think they could have built the platform the way that they did.
You look at something that might be more of a grey area, like Stripe. Stripe is a collection of services, there’s 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. That makes sense. It’s more of an implementation detail of how they ship their product. It would be easy to take that too far, but my impression is they probably struck the right balance.
The simpler the product and the more monolithic the product is in nature, the less need to break it apart into lots and lots of discrete services.
What happens if a company is deep with microservices, but the plug is pulled?
These sorts of architecture decisions are hard to undo at a moment’s notice. They tend to be pretty deep issues. Part of the benefit of microservices is things are separated physically, often running on different servers and separated by an API. Those APIs definitely have performance implications.
To undo it really requires deep thinking on, “Does that mean we shut off entire services, because we didn’t need them after all?” That wasn’t really a problem with microservices, per se. Maybe it was easier to ignore that with microservices, but that was a problem with how you were running your software to begin with. Why did you have services you didn’t need? If you’re going to keep those and consolidate them that’s a pretty big architectural change.
What to Read Next:
Could Elon Musk’s Staff Purge Create a ‘Twitter Mafia?’
Why Fiserv Turned to Microservices for API Development
What to Know When Migrating DevOps to Microservice Architectures
