What Kind of Challenges Can Microservices Help You Overcome

Every business owner is in a race to present their business online to customers. The race is on. The ones that adopt a promising new technology have an advantage over the others. Using these technologies, business owners have to ensure that their services/products reach their customers over different channels. For this, their business applications should be easy to deploy, reliable and easy to scale. Microservices is the much-preferred software architecture model of today that facilitates these actions and brings many benefits to its users.

Microservices is an architecture model that allows complex applications to be built as a suite of smaller-sized applications around specific areas and functionalities instead of a monolithic behemoth. Many companies have successfully moved away from the large monolithic models to microservices in recent times. They have also managed to innovate and become pioneers in the process. Let us see what kind of challenges the microservices models have helped overcome and this exactly the answer to the question ‘what problems do microservices solve’. 

1: How Amazon Overcame Scalability Issues

In the new millennium, Amazon was faced severe server demands and the existing architecture was unable to meet these demands. Amazon was then dealing with a monolithic application. Developers stayed apart from one another and the entire team became more distanced from its ultimate goal. Moreover, the original monolithic Amazon.com in 2001 inspired the decoupling of the service architectures. 

Back in 2000, Amazon’s engineering group was handling the tough task of coordinating process changes from hundreds of developers and queueing them up to be moved into the production phase. The result was: the SDLC became bulkier and longer. 

Read our blog The 5 Best Microservices Technologies List

Amazon ended up creating smaller teams, each with a goal to solve the problem and embed the specific service as an entity in a container that could be independently deployed. Simultaneously, Amazon built new features to the existing system by listening in to the customers.

The result was a simple microservices system that ended becoming a scalable package and new services coming in with a much shorter time to market.

2: How Groupon Shortened Time for Shipping New Features

As one of the fastest-growing eCommerce sites in the world during the period 2010-2014, the subscriber list of Groupon exploded in 2010. The code-base was first built with Ruby on Rails. The company soon expanded its activities into more than 40 countries and the package kept on adding new functionalities. 

Complex code drove the company to operate two separate websites, one for the desktop and another one for the mobile. Groupon made close to 29 acquisitions between the years 2010 and 2013. Integration to the Ruby on Rails package seemed impractical and they ran as separate platforms. 

The software architecture was monolithic and was divided into the backend, mid-tier and frontend sections. Groupon was not able to ship the features as fast as they wanted to. The frontend team had a long queue of features waiting to be delivered.

Download Ebook for FREE "How to choose the best microservices vendor and trim the cost"

The first thing Groupon needed at that point was development velocity. For this, they divided the organization into vertical silos with separate engineering teams. Each vertical had to build and ship its features as required. They then changed their tech stack in the same manner.

The monolith at Groupon ended getting split into smaller manageable pieces and the idea was to leverage the power of microservices. Each major part of the website was migrated into a separate Node.js application.

The result was a package that was easy to maintain and extend and quick to have new features shipped. 

3: PayPal’s Improved User Experience

With more users coming into its fold, the problems were apparent. The existing architecture required the management of thousands of VMs. The throughput performance was abysmal and the number of hops took its toll on network performance. In the end, what suffered was the user experience. The latency increased when the number of services increased.

By late 2015, PayPal had decided to migrate the entire Java-based monolithic system to Node.js microservices containers. Many different components of the original system were built using different frameworks. The latter half of the year 2017 saw PayPal spread over 200 markets worldwide and with 210 million active users.

Read our blog Why Business leaders should care about Microservices

The project envisaged changing application code, operational tools and deployment methods for effecting the new change. After the change was brought about the results were astounding. The system at the end managed as few as 8 VMs and 2vCPUs per application, and this was enough to cater to over 2 billion hits per day. The systems stay responsive even at a 90% load on the CPU which would have been impossible with the older architecture. 

Should you migrate from monolith to microservices architecture? Read our blog for more insights!

4: Twitter’s Improved Uptime

It was the same old story: Twitter started with monolithic architecture which made a lot of sense in the beginning stages. However, more users logged into Twitter and the problems started. The SDLC started getting larger and bulkier with long build times and scalability became very poor with over-capacity error messages popping up now and then. 

To overcome this problem, Twitter resorted to change the architecture to microservices. Each of the microservices was designed to modular, well-defined and independent. They could test and deploy every component separately. They could also be scaled separately. Soon the error messages disappeared completely. 

Do you want to shift from monolithic to microservices architecture? Schedule a call today!

5: eBay’s Balance Regained

eBay uses more than 1000 services. Many of the front end services send API calls and the back end services execute tasks such as administration and shipping. eBay started with a monolithic application built using Perl and C++. For eBay, the website itself is a major product as is with many other online giants. The requirement to add many incremental features to the eBay website kept on growing. Moreover, this kind of website had to be available 24/7 even while work on adding these features were going on. 

For these reasons, when downtime had to be a minimum, eBay decided to migrate to microservices architecture. This allowed the website to improve its stability and encouraged asynchronous integration. Deployment flexibility improved and release cycles were shortened considerably. The performance efficiency increased when services were decoupled and scaling out could be achieved easily. 

6: Uber

Uber the most popular taxi-hailing app started with a monolithic package to serve commuters in the city where it was first deployed: San Francisco. This tightly coupled codebase was able to manage the most, if not all, of the business processes, billing, payments and connecting with driver functions. However, things began to slip when the business grew. Uber had started covering more cities and was providing even more than one service. 
As new features were added, the package became more tightly coupled. All the logic was held in one place and problems started to show up. Soon even bringing about a small change required that the full application be redeployed. 

Soon, continuous integration was almost a big liability.

Download Now: Porting from Monoliths to Microservices

The ownership model was absent because of many intertwined dependencies on the monolith. Migration was therefore difficult. It also happened the new developers who joined the organization could not contribute to the monolith. Even if there was a small mistake, the effects were catastrophic. 

This was when they decided to go the microservices way. Their migration took a long time. They dismantled the entire service and moved the monolithic application to micro services-oriented architecture which was based on Python, Node.js, and Apache Thrift. 

7: KarmaWifi and Spaghetti Code

Karma has users, devices, and a store. With a monolith application at hand, at one point in time, the user-related code ended up in the device-related sections. And the store APIs were going behind the device APIs. Soon, it became hard to track what changed what or who changed what. 

Though the first thought was about splitting the monolith as functioning libraries, they realized they would have problems with scaling and adapting to newer software versions would be difficult. Moreover, they would not be able to experiment with newer technologies that were to hit the market in the future. 

READ ALSO: How to find the best microservices development company

By then they had decided to shift to microservices-based architecture. They started with one big app in the back-end and split off pieces as services when they thought it was necessary. The pieces were initially large but were split into smaller services with time. Soon each microservice ended up with a single responsibility and had an optimum size to contend with.

8: Shorter Development Cycles for Zalando

Zalando, a fashion technology company, has over 10000 employees, with over 1000 of them in the technology department. They initially functioned with a monolithic application constructed using Java, Spring and Postgres. They soon ended up with a bloated code-base and intertwined dependencies. 

When the team size grew, the bug density also increased. This led to coordination problems, and soon, slower development cycles. The old tech stacks that were being used also made hiring a difficult job for them. 

Download Now: Porting from Monoliths to Microservices

The organization decided to transition into microservices with each team getting to pick their tech stacks and tools for building the service.

The company used AWS for provisioning, Docker for deployment and Zmon and Appdynamics for the function of monitoring. They also make use of extensive audit trails that helps them to trace back any change to the specific individual that brought about the change. 

Zalando banned shared libraries across the different libraries. The teams, therefore, had to use only open-source as per the company rules. The testing services across the different teams were accomplished by a single cross-functional business unit. All these together helped them to accomplish shorter development cycles whenever new features were to be added. 

9: Quick Adaptation to Changing Market Conditions by AutoScout24

AutoScout24 initially used a monolithic application that was written using .Net. Using the traditional IT development process, they were unable to quickly adapt to changing market conditions when the company’s business grew. 

They then chose to move towards a microservices architecture setup using JVM and Scala. They set up cross-functional teams. As they decided to change everything at the same time, they had to limit the impact of this decision on the organization. There was a strong emphasis on learning and groups were formed with many experienced engineers and newcomers. The teams were stabilized when delivery became the focal point. 

They are now equipped to meet ever-changing market conditions in less time and with less effort. 

10: Walmart’s Improved Performance

Walmart started their microservices journey by acquiring a DevOps platform from a small startup named OneOps. They decided to make it into an open-source project to be able to give back to the community. 

They started using technologies such as Node.js and Cassandra databases and make different microservices, all of which could be invoked dynamically using APIs. The aim was to make it easier for the developers working in Walmart’s different business units and help them own their applications. This, they observed, reduced the dependency on a centralized IT organization. 

The end result was an improvement in business agility that came along with the ability of the developers to extend the back-end services of the organizations eCommerce services. 

Download Now: Porting from Monoliths to Microservices

Java is most suitable for writing microservices. One of the main reasons is that its annotation syntax is easy to read and understand. This makes writing microservices much easier, more so when powered by a framework such as Spring Boot. The value in readability is high, especially when it comes to working on complex systems and large teams. 

Spring boot is the smartest choice when you want to reduce the development time and better productivity in DevOps. Spring Boot has production-ready apps that are of immense help when it comes to automated testing and prototyping. 

Further testing microservices app architecture against user requests can be gauged in a more effective manner and independent app functionality status can be achieved quickly. If your organization is looking to reduce development time and cost, then Spring Boot is the way to go. 

Why Choose SayOne Technologies

At SayOne Technologies, we can help you to migrate your application from a monolithic structure to the microservices model. We can help you make your enterprise application an easy-to-maintain and scalable solution.

The key discriminators that we provide in our services are:

• A domain-driven design to prevent the application from failing,
• Ensure a high level of scalability
• Decentralized database design
• Enable failure isolation with ease, and
• Enable continuous delivery though using the DevOps culture

Closing Thoughts

Microservices challenges and solutions are discussed with gusto by most large corporations that have migrated successfully from the monolith behemoth they tried to sustain earlier on. Though the challenges were overwhelming, the results have brought important benefits to these businesses. 

We are experts in creating microservices for any industry vertical. Get in Touch with us today!