Monolithic VS SOA VS Microservices Architecture Details

Monolithic Architecture

Monolithic application has single code base with multiple modules. Modules are divided as either for business features or technical features. It has single build system which build entire application and/or dependency. It also has single executable or deployable binary.

In layman's terms, a monolith is similar to a big container wherein all the software components of an application are assembled together and tightly packaged.

Example for Monolithic Approach

Let’s imagine that you are building an e-commerce application that takes orders from customers, verifies inventory and available credit, and ships them. The application consists of several components including the StoreFrontUI, which implements the user interface, along with some backend services for checking credit, maintaining inventory and shipping orders.

The application is deployed as a single monolithic application. For example, a Java web application consists of a single WAR file that runs on a web container such as Tomcat. A Rails application consists of a single directory hierarchy deployed using either, for example, Phusion Passenger on Apache/Nginx or JRuby on Tomcat. You can run multiple instances of the application behind a load balancer in order to scale and improve availability.

Benefits:

·         Simple to develop — At the beginning of a project it is much easier to go with Monolithic Architecture.

·         Simple to test. For example, you can implement end-to-end testing by simply launching the application and testing the UI with Selenium.

·         Simple to deploy. You have to copy the packaged application to a server.

·         Simple to scale horizontally by running multiple copies behind a load balancer.

·         In the early stages of the project it works well and basically most of the big and successful applications which exist today were started as a monolith.

  Difficulties with monolithic application, when it grows 

·         Large monolithic code base makes complicated to understand, especially for new developer. 

·         Maintenance: If Application is too large and complex to understand entirely, it is challenging to make changes fast and correctly.

·         Scaling the application can be difficult

·         Continuous deployment is difficult: a large monolithic application is also an obstacle to frequent deployments. In order to update one component, you have to redeploy the entire application. This will interrupt background tasks (e.g. Quartz jobs in a Java application), regardless of whether they are impacted by the change, and possibly cause problems. 

·         Overloaded IDE:  Large code base makes IDE slow, build time increase.

·         Overloaded web container: the larger the application the longer it takes to start up. This had a huge impact on developer productivity because of time wasted waiting for the container to start. It also impacts deployment too.

·         Requires a long-term commitment to a technology stack: Extremely difficult to change technology or language or framework because everything is tightly coupled and depend up on each other.

·         Reliability: Bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug impact the availability of the entire application.

Service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or two or more services coordinating some activity. Some means of connecting services to each other is needed

Advantages:

Service Reusability
In SOA, an application is built by assembling small, self-contained, and loosely coupled pieces of functionality. Therefore, the services can be reused in multiple applications independent of their interactions with other services.
Easy Maintainability
Since a service is an independent entity, it can be easily updated or maintained without having to worry about other services. Large, complex applications can thus be managed easily.

Greater Reliability
SOA-based applications are more reliable since small, independent services are easier to test and debug as compared to massive chunks of code.
Location Independence
The services are usually published to a directory where consumers can look them up. This approach allows a service to change its location at any time. However, the consumers are always able to locate their requested service through the directory look up.
Improved Scalability and Availability
Multiple instances of a single service can run on different servers at the same time. This increases scalability and availability of the service.
Improved Software Quality
Since services can be reused, there is no scope for redundant functionality. This helps reduce errors due to inconsistent data, and thereby improves the quality of code.
Platform Independence
SOA facilitates the development of a complex product by integrating different products from different vendors independent of the platform and technology.
Increased Productivity
Developers can reuse existing legacy applications and build additional functionality without having to develop the entire thing from scratch. This increases the developers' productivity, and at the same time, substantially reduces the cost of developing an application.

Disadvantages

·         Increased Overhead: time a service interacts with another service, complete validation of every input parameter takes place. This increases the response time and machine load, and thereby reduces the overall performance.

·         Complex Service Management: The service needs to ensure that messages have been delivered in a timely manner. But as services keep exchanging messages to perform tasks, the number of these messages can go into millions even for a single application. This poses a big challenge to manage such a huge population of services.

·         High Investment Cost: Implementation of SOA requires a large upfront investment by means of technology, development, and human resource.

SOA is not recommended for the following type of applications.

·         Homogenous: Implementing SOA for applications that use the technologies of a single vendor will not be cost-effective. For example, if an application is built in Java, then it would be better to use methods of Java rather than using HTTP for inter-component communications.

·         GUI-Based: SOA would not be suitable for applications with GUI functionality, e.g. a map manipulation application. Such applications require heavy data exchange, which in turn would increase the complexity of the application if SOA is used.

·         Real-time: SOA is not desirable to be used with strictly-enforced response times since the services communicate asynchronously.

·         Stand-alone: It would be futile to invest in SOA for stand-alone non-distributed applications, which do not require request and response-based calls.

MicroServices Architecture:

Microservices, aka microservice architecture, is an architectural style that structures an application as a collection of small autonomous services modeled around a business domain.

Features of Microservices:

·         Decoupling: Services within a system are largely decoupled. So the application as a whole can be easily built, altered, and scaled

·         Componentization: Microservices are treated as independent components that can be easily replaced and upgraded

·         Business Capabilities: Microservices are very simple and focus on a single capability

·         Autonomy: Developers and teams can work independently of each other, thus increasing speed

·         Continuous Delivery: Allows frequent releases of software, through systematic automation of software creation, testing, and approval

·         Responsibility: Microservices do not focus on applications as projects. Instead, they treat applications as products for which they are responsible

·         Decentralized Governance: The focus is on using the right tool for the right job. That means there is no standardized pattern or any technology pattern. Developers have the freedom to choose the best useful tools to solve their problems

·         Agility: Microservices support agile development. Any new feature can be quickly developed and discarded again.

  

Advantages:

·         Independent Development: All microservices can be easily developed based on their individual functionality.

·         Independent Deployment:  Based on their services, they can be individually deployed in any application.

·         Fault Isolation: Even if one service of the application does not work, the system continues to function.

·         Technology Agnostic: Different languages and technologies can be used to build different services of the same application.

·         Granular Scaling: Individual components can scale as per need, there is no need to scale all components together.

Example: e-commerce application:

Let’s imagine that you are building an e-commerce application that takes orders from customers, verifies inventory and available credit, and ships them. The application consists of several components including the StoreFrontUI, which implements the user interface, along with some backend services for checking credit, maintaining inventory and shipping orders. The application consists of a set of services.

Disadvantages of microservices

Microservices may be a hot trend, but the architecture does have drawbacks. In general, the main negative of microservices is the complexity that any distributed system has.

Here’s a list of some potential pain areas and other cons associated with microservices designs:

·         Communication between services is complex: Since everything is now an independent service, you have to carefully handle requests traveling between your modules. In one such scenario, developers may be forced to write extra code to avoid disruption. Over time, complications will arise when remote calls experience latency.

·         More services equal more resources: Multiple databases and transaction management can be painful.

·         Global testing is difficult: Testing a microservices-based application can be cumbersome. In a monolithic approach, we would just need to launch our WAR on an application server and ensure its connectivity with the underlying database. With microservices, each dependent service needs to be confirmed before testing can occur.

·         Debugging problems can be harder: Each service has its own set of logs to go through. Log, logs, and more logs.

·         Deployment challengers: The product may need coordination among multiple services, which may not be as straightforward as deploying a WAR in a container.

Of course, with the right kind of automation and tools and the properly trained staff, all the above drawbacks can be addressed.