10 Tech Challenges That Are Solved by Microservices
by Maria Terskikh
Today, companies, big and small alike, are engaged in a faster than ever race to be the first. You have to be the first to adopt a new technology, the first to innovate, the first to launch a new product or service. Therefore, companies have to make sure that the customers can easily access their services through all digital channels and that their applications are scalable, reliable and easy to deploy. As a response to these requirements, many companies moved away from their monolithic systems that served them well for many years to microservices.
Microservices architectures allow a complex application to be built as a suite of small services, developed around specific areas. Combined, they provide a cohesive set of functionalities and bring important business benefits:
· reduction of code complexity
· easy application management
· improved testability
· better scalability
· stronger resilience
· higher availability
· quicker release cycles
· better organizational alignment
We know that not every company needs all the above benefits. We also know that not every microservices architecture will deliver them all.
Taking these two aspects into consideration, let’s look at 10 examples of tech challenges solved by microservices.
1. Scalability
Case in point: Amazon
different teams and processes.
To solve the issues, Amazon created separate small teams, each of these teams being assigned to solve a specific need.
The goal for each team was twofold:
- to come up with a solution to the problem and
- embed the service and dependencies as a single entity, deployable on a container.
In the same time, the company started do develop new features by listening to what the customers were asking. As a result, Amazon built a microservices architecture that is as simple as possible. Also, the company gained not only a higher level of scalability but also the ability to shorten the time to market.
2. Shorten the Time for Shipping New Features
Case in point: Groupon
Groupon started with a simple website designed to show one deal per day to the people living in Chicago. The website was initially built with a single codebase using Ruby on Rails. As the company expanded to more than 48 countries and added new functionalities like mobile device support, the codebase quickly grew complex and large, making it harder and harder to ship new features.
As a solution, Groupon decided to split the application into several small and manageable pieces and leverage the power of microservices. For example, each major section of their website was migrated to an independent Node.js application.
In the end, the initial monolith was split into several independent applications that are easy to maintain end extend.
3. Improved User Experience
Case in point: PayPal
As its number of user and transactions skyrocketed, PayPal engineers were facing a unique challenge: due to the complexity of the architecture, it wasn’t uncommon for a service to cover a thousand VMs. Each VM produced a very low throughput but the large number of hops was taking a toll on the network performance.
As more and more services were added, latency was increasing with the same speed that the user experience was deteriorating.
The engineers were well aware that a large number of VMs was good for spreading the load and for redundancy, but they just passed the threshold where adding more VMs meant performance penalty.
To solve the issues, in 2013, PayPal started migrating from their monolithic Java-based architecture to a microservices architecture based on Node.js.
In terms of performance, the results were astounding:
“With as little as 8 VMs and 2 vCPU each, applications were able to serve over a billion hits a day. Our systems stay responsive even at 90% CPU, very uncharacteristic for our older architectures.”
4.Improved Uptime
Case in point: Twitter.
Like many other companies, Twitter started with a monolithic, vertically-integrated application. In the beginning it was a sensible choice, being simple and resource efficient. As the company gained more and more active users, the downsides of this approach became visible:
- poor scaling (only vertical),
- all-or-nothing deployments and
- long build times.
Out of these three, poor scaling was the biggest issue. Even if you don’t see it often these days, Twitter’s Fail Whale, their customized error page, was a regular appearance.
To solve the problem, Twitter stepped towards a microservices based architecture. Each micro-service had a single purpose, and was designed to be well defined, modular and independent. This approach allowed them to test and deploy each component independently and to scale them separately.
Not counting the one above, do you remember last time when you saw the Twitter Fail Whale?
5. Balance Stability, Release Cycle and Performance
Case in point: E-Bay
E-Bay started with a monolithic application, heavily relying on C++ Perl. For E-Bay as for many modern business, the website is the product. Thus, many incremental changes have to be implemented to add new features. In the same time, the website must be available 24x7.
To cope with these requirements, E-bay gradually migrated to microservices architecture which allowed them to:
- improve stability, by scaling out and enocuraging asynchronous integration
- shorten release cycles, by reducing dependencies and improving deployment flexibility
- increase performance, by scaling out and component decoupling
6. Continuous Integration
Following the same path as the other startups, Uber started with a monolithic architecture. Since they were only covering San Francisco, this approach seemed best. It allowed the company to quickly solve its most stringent business problems:
- to bridge drivers and riders,
- provide billing service,
- Process payments.
Once the company started to cover more cities and provide more than one service, the decision to keep all the logic in one place started to show its drawbacks. As the business required new features, the main components became more and more tightly coupled and soon it reached the point where a single change required a complete redeploy of the entire application. To put it simply, continuously integration became a liability.
To solve this issue, Uber dismantled the monolithic application and moved to a microservices oriented architecture, based on Apache Thrift, Python, and Node.js. With this approach, Uber improved the resilience and fault tolerance of their application
7. Spaghetti code
Case in point: KarmaWifi
Initially, Karma application was composed of two main components: backend and frontend. The backend was responsible for several tasks like:
- handling orders,
- user and
- usage management.
Meanwhile, the frontend was providing an interface for the users via the API.
As the complexity of the data model grew over time, it was hard to track the interactions between components because everything got entangled.
To solve the issue KarmaWifi started to split pieces of the backend, whenever this made sense. Each time the engineering team worked on something that looked like a separate entity, they turned it into a service.
In the end, they got an application composed entirely of microservices, each one having a single responsibility.
At the time of writing, KarmaWifi is working on adding new functionalities through microservices.
8. Shorter Development Cycles
Case in point: Zalando
Zalando started their journey with a monolithic Java and Spring application. Soon enough, they ended up with many dependencies and bloated codebase. But the bigger issue was slower development cycles, which meant that the speed of innovation started to decrease.
To solve the issue, Zalando migrated the Java and Spring monolith to microservices, using Docker for deployment and AWS for provisioning.
They also empowered developers to take responsibility for all phases. As a result of their efforts, they are now are able to better manage the ever growing ecosystem and shorten the development cycles.
9. Quickly React to Changing Market Conditions
Case in point: AutoScout24
To start their business, AutoScout 24 chose to go with a monolithic application written in .Net. As the company grew, they reached the point where engineers were unable to react quickly enough to keep up with the ever-changing market conditions.
After taking into consideration the available options, their choice was to begin a transformation project towards a microservices architecture, powered by Scala and AWS. Meanwhile, AutoScout24 promoted cross-functional teams and culture of responsibility.
As a result, they are now much better equipped to adapt to market conditions.
10. Improved Performance
Case in point: Walmart
With the increased number of customers and orders, Walmart’s monolithic platform started to show its age. The biggest problem was not that it could not handle the number of customers and orders, but the time required for every simple operation was constantly increasing.
In 2012, Walmart started to re-architect their platform to a microservices architecture, with the main goal of improving the overall performance.
The results were quick and convincing: conversions were up by 20%, mobile orders up by 98%, no downtimes. Also, since they migrated from expensive hardware to commodity machines, they managed to cut their operational costs.
Conclusion
As we have seen, many companies started with monolithic architectures. But once they expanded and diversified their offering, the shortcomings were quick to appear. If you are a small or a medium company, why not learn from these lessons and choose the right approach from the beginning? Microservices, with their many advantages, will help you quickly penetrate new markets and stay ahead of the competition.
Don’t forget to follow us on Twitter and join our Telegram chat to stay tuned!
You might also want to check our Containerum project on GitHub. We need you feedback to make it stronger — you can submit an issue, or just support the project by giving it a ⭐. Your support really matters to us!
Containerum.com is your source of knowledge on Kubernetes and Docker.
