Microservices Architecture – A Good or Bad Approach?


Microservices is today’s fashion trend in IT. Whether it’s at a conference, on the web or in a discussion with peers, microservices is increasingly presented as the solution to issues with monolithic applications. But is microservices really the silver bullet, or just a passing fad?

But First, what is Microservices Architecture?

Microservices architecture consists of a collection of small, autonomous services. Each service is self-contained and should support a single business capability. By following this principle, microservices remain small, independent and loosely coupled. Each service has a separate codebase, which can be managed by a small development team, and can be changed easily.

At the same time, services can be deployed independently, so one team can update an existing service without rebuilding or redeploying the entire application. Another important distinction between microservices and monolithic applications is the fact that services contain their own set of data.

The communication between the services is done using well-defined APIs without requirements to share the same technology stacks, libraries or frameworks.

Microservices architecture is ideal for applications that are large and require short release cycles, complex applications that must be highly scalable and applications with rich domains or many subdomains. Microservices is also a good approach for organizations with small development teams and limited resources.

Advantages of a Microservices Architecture

As stated above, microservices architecture supports independent deployments. Indeed, a service can be updated without redeploying the entire application and rolled back or rolled forward if an update goes wrong. Therefore, maintenance is much easier and bug fixes and new feature releases are less risky. Moreover, if a service goes down, it won't take out the entire application.

Microservices architecture also enables independent development. A single development team can build, test and deploy a service with continuous innovation and faster release cadence. For big applications with many microservices, the technology stacks can also be mixed.

Teams can pick the technology that best fits their service to narrow the scope. The smaller the scope for each service, the easier it is to understand the code base, which is a big win when new team members are ramping up on the project.

Common Challenges with Microservices Architecture

One of the biggest challenges with microservices architecture is software complexity. An application with microservices has many more moving parts than the equivalent monolithic application. Each service is simpler, but the entire system is more complex. This requires teams to maintain a very good understanding of the entire architecture of the application. It also requires a permanent verification of application architecture to ensure that all the microservices are working well together. This kind of verification can be done by specific set of rules that should be checked on regular basis.

The decentralized approach to building microservices can also lead to problems. You may end up with so many different languages and frameworks that the application becomes difficult to maintain. It is important to put project-wide software quality gates in place and have it controlled regularly without overly restricting teams' flexibility.

Another challenge when working with microservices is backward or forward compatibility. Updates to a service must not break the services that depend on it. Because multiple services can be updated at any given time, the design of the application is very important. Design rules must be rigorously followed and checked with any new version release of a microservice in order to prevent breakdown of the application.

At the end of the day, microservices architecture presents many benefits, but it also its own set of unique challenges that must be considered and addressed to keep quality high and software complexity low. Sound design and architectural rules are essential to success in microservices. 

  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Narcisa Zysman
Narcisa Zysman Senior Product Manager at CAST
Load more reviews
Thank you for the review! Your review must be approved first
You've already submitted a review for this item