Examining Application Development Approaches

By CIOReview | Monday, July 10, 2017

The dynamism of current day environments necessitates the usage of highly sophisticated applications. Sophistication essentially refers to the advanced functions featured in the application; while some are built into the software, there are others that could be integrated into the application. The success of integration relies on the degree of communication between the applications and the various services that they are composed of, which in turn depends on the architecture of each application. Service Oriented Architecture (SOA) and Microservices are the commonly used architectures for building enterprise applications. Both the approaches share similarities and differences that are taken into account during the development phase. Therefore, zeroing in on the best approach to application development requires a thorough understanding of the SOA and Microservices.

Service Oriented Architecture

SOA is a software architecture pattern, where several interdependent services are amalgamated form a monolithic application. Applications built using SOA feature two main roles: service provider and a service consumer. While software could take up both the roles, there exists a layer where humans interact with the services defined in the application, called the consumer layer. Point-to-point connections between the providers and consumers are enabled using an Enterprise Service Bus (ESB)—an integration architecture for the service components within the service. SOA patterns the enterprise software by collecting best-in-class interdependent services, where each service interacts with the other through communication protocols such as SOAP, REST or even JSON. The interactions between the services could be to support a larger function to carry out enterprise activities or merely data transfer.

The downside of SOA is that the code base grows with increase in application, which potentially reduces the development team’s productivity. Therefore, a modular approach where each section of the code is partitioned into multiple services becomes necessary.

Microservices Architecture

Microservices is an architecture pattern, where the application is split into multiple component services. Each service can be deployed, altered and redeployed elsewhere, without compromising on the functionality of the original application. The communication between individual processes or services happens through language-agnostic application program interfaces (APIs). The architecture offers better scalability and control throughout the phases of development, testing and deployment of an application. Consequently, software patterned as Microservices, processes the requests received and further generates response accordingly, unlike ESBs that require high-end systems for applying business rules or message routing.

Differences between SOA and Microservices

Both SOA and Microservices have their share of similarities and differences. For example, both the architectures assign a definite role to the services within the software due to which services can be developed using various technologies. However in SOA, teams responsible for developing the services need to be aware of the communication protocols, unlike Microservices where APIs take care of the communication. Further, the Microservices architecture allows services to be redeployed and reused, without affecting the functionality of the original application, which is not the case in SOA.

SOA is based on the principle of sharing the maximum resources with the services. However, data coupling between the resources tends to be very tight. This makes it challenging to implement any changes in the architecture. On the other hand, Microservices architecture adopts a ‘bounded context’ approach, wherein there is a self-containerized association between each service and its data.

In the SOA, every service is routed through the ESB making it a central hub controller for orderly execution. Therefore any failure in the ESB is bound to impact the entire application. Microservices, however, is better with regard to fault tolerance as the architecture is based on inter-services communication. Each microservice within an application calls another microservice, based on the requirements, for completing the function. Faults in a single microservice affect only the particular service and not the entire application.

The flexibility offered by Microservices with regard to fault tolerance, reuse of services—has popularized Microservices; scalability is a major driving force for the architecture. Not surprisingly, products like Netflix have been developed using the Microservices approach. However, Microservices is not without its share of drawbacks. For example, developing distributed systems, which is the main feature of Microservices is indeed complex. Also, as each service has its own database environment, managing multiple databases could be tough. Testing an application having the Microservices architecture is more difficult as compared to a monolithic application.