Top Microservice-based Products & Services
Microservices is a service‑oriented architecture composed of loosely coupled elements that have bounded contexts.
— Adrian Cockcroft
Microservices is a popular type of software architecture for many years now. No surprise. They are praised for they are scalable, well-performing, and sustainable. It would be wrong to say that monolith architecture is dead, simply because it still has the purpose. Big corporations with complex solutions opt for microservices architecture though. They build their software/applications/platforms using Java, C-family languages, Python, Golang, Scala, and more languages, to achieve truly perfect decentralized services. Let’s dig deeper and figure out the decisive factors that led globally-recognized companies to the choice of microservices.
Netflix
Netflix is an early adopter of microservices architecture. The development team behind such a convenient Internet TV network believes that technologies which worked fine ten years ago — are not the best options these days. Simple as that. Netflix tech engineers just strive for cutting-edge solutions for their product, and this is the main reason why the app is built with microservices architecture.
The second factor of architecture choice lies in the popularity of the service. It’s available in over 190 countries. Since the number of people accessing the application simultaneously is huge — the goal was to ensure no single process stops in the middle of video streaming. For that, Netflix built the system on Nginx server and distributed the functionality onto the separate service clusters. This measure helped to unload heavy data flows and make every process smooth, resistant, and easy to control. And when your movie-watching goes smooth — all you can say is “Netflix and chill”.
Decisive factor in the choice of microservices: an unprecedented level of speed and control.
Amazon
Back in 2001, Amazon was a huge architectural monolith. Now, this online shopping platform known to every second person in the world — is built on more than 150 services. All of them are accessed just to build one page showing the results of your request. For such heavy loads of data, the service not only has to be scalable but also well-performing at the same time. In monoliths, when new functionality or data is added to the existing application — usually there’s a chance that some processes drop. Working their way from macro to micro — Amazon achieved significant flexibility of their service. Distributed architecture allows extending the app without pain as much as your business needs. And Amazon does that non-stop.
Decisive factor in the choice of microservices: scalability and increased performance proportional to the added resources.
Uber
We all know how fast Uber popularity distributed around the world. Even though this is quite a young service compared to the others on our list — Uber team of innovative connoisseurs started their successful path from monolith architecture. However, things gotta change in order to move forward, and this is why developers saw microservices architecture as the best-fitting solution to ensure consistent business growth. Since this modular architecture type is flexible — they now can perform additional data/service ingestion, encoding, and deployment much faster.
Uber team also claims that tracking and analysis of new features usage are faster when the functionality is decoupled: all you have to do is examine the separate piece of information and make a report. With monolith architecture, it’s much harder: you first have to find this area you want to analyze, and it takes hours, while microservices allow you to perform the same actions in a couple of minutes.
Decisive factor in the choice of microservices: the ability to add, monitor, and analyze new integrations easier.
SoundCloud
SoundCloud allows millions of people to enjoy music online for free, and this is not an easy job for programmers. They also started with a monolith architecture, like most of the businesses do. Yet, with the growth of popularity and ambition, always appears the need for a change. As for 2014, the SoundCloud platform had about 12 hours of music and sound uploaded every minute, and hundreds of millions of people using the platform every day. Now, in 2018, these numbers are even bigger. SoundCloud team of engineers decided to break down their monolithic Ruby on Rails application called Mothership and make it a distributed bunch of services to manage the platform easier.
They took one of the most interesting approaches so far. They didn’t gather the team in order to make up a working solution. Instead, they decided to research existing academic publications on the relative topic to figure out the best-fitting way to achieve their goal. The solution SoundCloud found for their applications was “Bounded Context” by Eric Evans and Martin Fowler. This book offered a strategy of implementation highly cohesive feature sets in a user-to-user messages way, which was just exactly what team was looking for. They found decoupling the services from Mothership quite problematic but a highly-skilled team of programmers with innovative thinking made it possible and proved that transition from monolith to microservices architecture is a great idea.
Decisive factor in the choice of microservices: unload the main server from huge data streams, further smart load distribution.
Twitter must be one of those platforms of the highest interest in terms of architecture. It has such an unpredictable load swings that the development team must be going insane from time to time. That’s what we first thought when we started to dig their history. And we were right. The popularity of Twitter just doesn’t allow this service to drop unexpectedly. Ranging from 6,000 to the world record number of 143,199 tweets per second — you can guess that it’s not an easy job.
Behind the closed doors, Twitter geeks had a much bigger plan that just to transit their platform on microservices architecture. Since initially it was open-source software, they wanted to keep things on the same democracy wave: they allowed technically-savvy users to contribute to Twitter’s improvement, along with sharing their team’s knowledge with the whole world. The high-throughput RPC library, called Finagle — is the powering source for microservice architecture of Twitter.
Decisive factor in the choice of microservices: manage unexpected load swings, create a development community, and share expertise.
We can talk about how cool microservices architecture is for ages and on the examples of large companies you can see why, but there are also drawbacks of this architecture type. The most prominent one is the security issues. Still, PayPal, eBay, The Guardian, and many other enterprise-sized companies opt for this type of architecture, even if the transition is painful. Behind this much of a complicated technical side of every successful business lies one and only reason for such choices — they want to make their clients happy.
The article was originally published on QArea blog.
