Microservices: What Are They?

A lot of big names have embraced microservices, and while the origin of the term is hard to pinpoint, this approach to application management and development has spread exponentially in the enterprise.

But what is it?

In a nutshell, a microservices architecture is a notion used to talk about the practice of splitting up an application into a series of smaller, more focused increments. Each of these parts communicate with each other across REST interfaces and common ones like APIs.

Every microservice manages its own database, generating their own logs and user authentication which means that at both operations and management level containers are involved generally.

When looking at the old way of building applications as single entities on a server underpinned by one database, microservices are a complete contrast.

This newer approach also sees a change culturally and in the way departments are set up. No longer do businesses need highly specialised teams, but instead mixed product teams that rely on some form of agile/continuous delivery.

So who uses microservices?

With the age of web-scale and cloud applications upon us, microservices are gaining more and more ground. Companies such as ASOS, Netflix, and Spotify all were born into this world. But it’s not just companies such as those that have adopted microservices, it’s also found within more traditional companies as well as they try to take their legacy code and break it down into microservices.

The reasons for changes within companies to microservices are usually the same: database dependencies, coordinating releases among teams, long feature cycles, single points of failure, etc. A traditional enterprise that made the change was BBC. The broadcaster looked to AWS (Amazon Web Services) when it moved its iPlayer video platform to the cloud. The iPlayer system is now made up of around 30 different microservices with messages passing along a chain of services to go through the workflow.

One of the best pros of companies moving to microservices is that when something fails it won’t bring everything to a halt unlike with big services.

But what are the cons?

We have been waxing lyrical about microservices, however like everything it isn’t perfect. When it comes to a microservices architecture the complex nature of dependencies can cause quite a few issues.

Back in 2014, Martin Fowler wrote a critical blog. In it he said “The biggest issue in changing a monolith into microservices lies in changing the communication pattern.”

“Another issue is if the components do not compose cleanly, then all you are doing is shifting complexity from inside a component to the connections between components,” he added. “Not just does this just move complexity around, it moves it to a place that’s less explicit and harder to control.”

While things have evolved from 2014, it still doesn’t mean that it’s the correct path for all companies.

When it comes to microservices, a lot of effort needs to be put into design from the start. If it’s not done correctly then it can end up being a distributed monolith, which could be disastrous.

Customer data specialists Segment engineers said that the company’s move to microservices created new types of event queues formed for each individual partner API destination and service. This meant that quickly developers found themselves overwhelmed by complexity.

The lead developer on the project, Alex Noonan said “Maintenance started to become a pretty big headache for developers. If we did want to suck it up and make the change to every single one of those services, we had to spend multiple days, multiple developers testing and deploying every single one of those services – it became a huge burden, so we ended up opting for not making changes that we’d desperately need.”

The company eventually reverted back to their legacy architecture, putting everything into one event delivery system that the company was building at the time.