Application Architecture: Monolithic vs SOA vs Microservices

09.05.2019

Over the last few years Microservices architecture has been adopted by some of the biggest companies on the planet including Netflix, Amazon, twitter and eBay. These companies strive for continuous Business Transformation and have said goodbye to outdated Frameworks such as Monolithic and SOA due to greater flexibility, agility and efficiency.

In this article we cover the different types of architecture as well as their characteristics and how they are used within different organisations.

  Microservices SOA Monolithic
Design Services are built in small units and expressed formally with business-oriented APIs. Services can range in size anywhere from small application services to very large enterprise services including much more business functionality. Monolithic applications evolve into huge size, a situation where understanding the entirety of the application is difficult.
Usability Services exposed with a standard protocol, such as a RESTful API, and consumed/reused by other services and applications. Services exposed with a standard protocol, such as SOAP and consumed/reused by other services – leverage messaging middleware. Limited re-use is realized across monolithic applications.
Scalability Services exist as independent deployment artifacts and can be scaled independently of other services. Dependencies between services and reusable sub-components can introduce scaling challenges. Scaling monolithic applications can often be a challenge.
Agility Smaller independent deployable units ease build/release management, thereby high operational agility. Enhances components sharing that increases dependencies and limits management capabilities. Difficult to achieve operational agility in the repeated deployment of monolithic application artifacts.
Development  Developing services discretely allows developers to use the appropriate development framework for the task at hand. Reusable components and standard practices helps developers with implementation. Monolithic applications are implemented using a single development stack (i.e., JEE or .NET), which can limit the availability of “the right tool for the job”.

 
Monolithic Application

A Monolithic application is built as one single unit in which the user interface and data access code are combined into a single program on a single platform. Enterprise Monolithic applications are built in three parts: A database, consisting of many tables usually in a relational database management system. Client-side user interface consisting of HTML and/or JavaScript running in a browser. Server-side applications which work as the middle man between the user interface and the database will handle HTTP requests, execute some domain-specific logic, retrieve and update data from the database, and populate the HTML views to be sent to the browser.

The difficulties when deploying Monolith Architecture comes when scaling up. Every time you build, test and deploy, you have to change the whole monolith due to modules being extensively dependant on each other. Monolith Architecture is most effective on small projects with a well-defined scope, where you are unlikely to maintain or evolve the codebase on a recurring basis. Remember a monolithic application can be deployed on the cloud and you are still able to use the benefits of storage resources.

WHISHWORKS Monolithic

Service Oriented Architecture (SOA)

SOA is an architecture approach for defining, linking and integrating reusable business services that have clear boundaries and are self-contained with their own functionalities. These services communicate with each other to enable simple data passing or it could involve two or more services coordinating activity. The complexity of each service within SOA is usually very low and they communicate with each other over a set of APIs.

An example of where SOA is commonly used is in car insurance comparison websites’, it accesses databases and provides business data and the technical details to construct a graphical interface. SOAs give you a great amount of flexibility when building complex architectures and one component will not bring down the rest of it if a deployment goes wrong. One clear disadvantage is that although the services are simple the architecture can become too complex to accommodate growing business requirements, if you don’t need separate functionalities of your architecture then don’t do it as it will come at a cost.

WHISHWORKS SOA

Microservices framework

Microservices architecture breaks the application into smaller, completely independent components, enabling them to have greater agility and scalability. It is the logical evolution of SOA that supports modern business use-cases.

Microservices solve the problems of outdated Monolithic systems, this type of architecture consists of greater amounts of small services each running its own processes and are independently deployable therefore making it easier to understand, develop and test to enable Continuous Delivery and Continuous Improvement. Microservices architecture renders itself to suit a cloud-native platform, so when ready this type of architecture can move to a cloud native platform.

WHISHWORKS Microservices

Benefits of Microservices Framework: 

  • Agility: By breaking down functionality to the most basic level and then abstracting the related services, you only need to modify and redeploy when a change is needed in the entire application.
  • Efficiency: Leveraging a microservices-based architecture enables far more efficient usage of code and underlying infrastructure, with an ability to independently develop and deploy services without waiting on decisions regarding the entire application.
  • Resiliency: By dispersing functionality across multiple services eliminates application susceptibility to a single point of failure. If one of the services fails, the others will continue to work.
  • Revenue: Faster iterations and decreased downtime increase revenue.
  • Retention: Continuous improvement offers lead to increased user engagement and retention.
  • Technical Debt: Less time consuming, more adaptable and ultimately, less expensive to maintain, which, in turn, reduce the technical debt. 


Final thoughts

Microservices architecture seems to be the way forward due to the architecture being broken down into multiple component services, so that each of these services can be deployed and then redeployed independently. But this may be too complex for what your business needs and a simpler Framework may be easier and more cost efficient to implement. At WHISHWORKS we are here to help assess your options and get you on track for streamlining and automating your Application Architecture.

 

If you would like to find out how you can move away from existing Monolith and SOA Frameworks and upgrade to a Microservices Framework, then please feel free to give us a call on +44 (0)203 475 7980 or email us at marketing@whishworks.com.

API reusability – why does it matter?

API recipes with MuleSoft Anypoint Platform

Customer success stories

Recent Posts