Using Microservices for Legacy System Modernization

What’s the Difference between Monolithic and Microservices Architecture?

Why Use Microservices for Legacy System Modernization?

  • Small, autonomous teams allow for better communication
    Microservices by definition are independent elements and must be manipulated as such. Thus, they are usually developed and managed by small teams of up to eight people (often called two-pizza groups). This organizational structure not only helps developers become attuned to their codebases and resolve issues faster, but also provides better in-group communication.
  • Independent deployment doesn’t require synchronization of processes
    When you deploy each service independently, outages in a single segment of an application will less likely bring down an entire application. Consequently, even if some services are down, most of the clients won’t notice, and the team can resolve problems without rushing. Also, during the deployment process, developers don’t need to coordinate local changes which enables continuous deployment, saves time, and resources.
  • Elements can be scaled separately
    Having monolithic architecture, you are required to scale all components together, compromising on the choice of hardware. Microservices allow you to deal only with functional bottlenecks, scale the parts that have performance issues, and use the hardware that best matches service requirements. Moreover, the automated scaling allows for normalizing configuration during off-peak hours, which results in a better customer experience and cost-savings.
  • Each microservice is developed using the most fitting technology
    Developers can choose whatever language or technology is best suited for each service. Plus, when the services are small, it’s easier to rewrite them using new and modern technologies. With such continuous modernization, your system won’t become quickly outdated. “The nice thing about microservices from a company’s standpoint is that they allow for higher developer satisfaction and higher developer retention. Because, due to the fact that microservices are self-encapsulated, it is possible to give developers more freedom of choice which frameworks, libraries, programming languages, tools, etc. they want to work with.” says Renat Zubairov, CEO of elastic.io, the microservices-based hybrid integration platform.
  • Phased implementation helps escape complete rewriting
    With microservice architecture, you can isolate a small part from your existing application and replace it with a microservice. By breaking a monolith into pieces, you don’t have to completely reimplement it, but rather identify one or more clearly defined functional chunks and pull them out as microservices. However, this approach can be successfully used only at the later stages of migration and will produce a number of complications for developers at the beginning of microservices implementation. We’ll be discussing that in the next section.

Possible Hurdles to Consider

  • The engineering effort may set you back
    One of the main challenges of refactoring to microservices is to gradually replace functionality while minimizing the changes that must be added to support this transition. Since microservices imply a distributed system, developers need to think of the ways to extract the function from the interconnected monolith and keep the new services linked to the remainder of the system. Not only does this increase the amount of work for developers, but it also may slow down the whole development process.
  • Inter-service communication creates more errors
    As opposed to the monolithic architecture, a microservices-based application is a distributed system that incorporates multiple modules. Each microservice uses some sort of an API to exchange data. Changes to the API can introduce errors, such as message format differences between API versions. Also, as more components attempt to exchange information, network congestion can occur.
  • Testing and monitoring may be daunting
    With monolithic architecture, we can test the entire codebase. With microservices, each independent service needs to be tested separately. It’s a complex and protracted process. However, the problem can be eliminated with a set of modern approaches, such as contract testing or the end-to-end method.
  • You will have to adopt DevOps
    If your company doesn’t embrace the DevOps practice, you will lose the main reason to go with microservices–delivering scalable applications fast. To ensure this, development and operations must be aligned to work jointly on a problem, so that one would be able to keep pace with the another. However, considering the popularity of DevOps, this problem can be transformed into an opportunity. Then, you can take on not one, but two evolutionary approaches that perfectly complement each other.

Three Strategies of Microservices Implementation

  • Implement each new functionality as a microservice
    When implementing a new functionality, don’t add it to your existing monolith. Instead, put it in a microservice. This approach prevents a monolith from becoming bigger and harder to deal with, allowing each new service experience the benefits of the microservice architecture. However, this strategy doesn’t help to eliminate a monolith, and the following approaches address that.
  • Break down the monolith
    Usually, a monolith application consists of three components: user interface (front-end), business logic (back-end), and databases. The natural separation between them allows for splitting a monolith into smaller applications, thus making it easy to develop and scale applications independently. Still, it’s possible that two applications (front-end and back-end + databases) will be just as unmanageable as one, and this technique can be used only as a step towards a complete containerization.
  • Extract modules into microservices
    The most logical strategy to use is to extract already existing modules within a monolith into standalone microservices. Once you’ve extracted enough modules, the monolith will stop being a monolith. The following diagram illustrates the refactoring process.

Microservices Architecture Use Cases

  • Netflix
    Being one of the earliest adopters of the microservices architecture, Netflix shared their journey before the term even existed. In 2008, the company was growing rapidly and was unable to build data centers to keep up with scale. Plus, the smallest error in the code required all Netflix engineers to engage into finding a problem. After refactoring non-customer facing applications to microservices in 2009, Netflix began working with customer-facing services, such as account signup, movie and TV selections, and others. By the end of 2011, they’d fully and successfully broken up their monolith into hundreds of microservices. Today, its website is powered by 500+ microservices and 30+ independent engineering teams.
  • Walmart
    Having to deal with 6 million pageviews per minute, Walmart had to rearchitect their giant online business from monolith in 2012. Their huge step to digital transformation required changing the organization’s approach to DevOps and migrating the system to microservices. As a result, the company increased their mobile orders by 98 percent and raised conversions by 20 percent overnight. The biggest concern–downtimes during peak events such as Black Friday–was also eliminated, along with no downtime altogether after refactoring.
  • Amazon
    In 2001, Amazon.com was an architectural monolith. Although hundreds of developers were working on a very small piece of the website, they still had to coordinate each change with other members’ projects. Each update or bugfix had to be synchronized. The company even establish a “merge Friday”– the day when all developers merged their changes and created a final version that would go into production. This discouraging process added a lot of frustration, so the company made an important decision and pulled out functional units to wrap them with a web service interface. Moreover, their two-pizza teams were given full ownership of one or a few microservices, which increased responsibility and efficiency. Now, thanks to continuous delivery, Amazon is able to make 50 million deployments per year.
  • Spotify
    With the intention to stay innovative in a highly competitive market, Spotify required an architecture that could scale independently to 75 million users. Microservices allowed them just that, plus solved another problem–the constant synchronization within the company. By creating autonomous, full-stack teams, each consisting of front- and back-end developers, testers and UI designers, Spotify increased responsibility for each operation and got rid of overlapping between different tasks. The company was also able to create a seamless experience for millions of users by having many services down without customers even noticing it.

Conclusion

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
AltexSoft Inc

AltexSoft Inc

2.7K Followers

Being a Technology & Solution Consulting company, AltexSoft co-builds technology products to help companies accelerate growth.