Adoption of microservices over SOA Architecture

The software industry is a fast-paced and extremely competitive space. It is constantly flooded with new technologies, processes, and tools that attempt to keep pace with the demands of the day. Most of these products and concepts that hit the market are extremely trendy and have a short life. This makes it extremely difficult for the organization to determine what to adopt, and when to adopt it. This brings us to a fairly recent trend that is seeing ever-increasing adoption, microservices.

Microservices architecture is a derivative of service-oriented architecture(SOA) in the way that they seek to modularize an application into unique services in order to increase granularity.

I will be focussing on how each of them plays a vital role in solving business problems while aligning to the organizational goals in this post.

Let’s delve deeper to understand how it all started.

Evolution of SOA with ESB

Service-oriented architectures were first devised in the 1990s but became more widely understood and utilized in the 21st century. It gained more popularity due to the growing prevalence of the internet and internet technologies.

Since SOA supported the idea of building a service that provides a common function, it helped the organization to keep all the services available at a single source and not to re-invent the wheels every time. It became widely popular because of its principles of loose coupling, clear interface definition, and the reuse of services functionality.

“SOA is a style of design that guides an organization during all aspects of creating and using business services. It provides a design framework for realizing rapid and low-cost system development and improving total system quality”

Soon SOA became synonymous with the communication protocols SOAP over HTTP and tools like Enterprise Service Bus(ESB). Service-Oriented Architecture led to the popularization of “Middleware” as a separate layer, and products targeting it became powerful platforms for application integration. These consolidated the centralized data dictionaries thus increasing the focus on the “Enterprise” standards and architecture.

It uses the Web services standards and technologies and rapidly became the standard approach for enterprise information systems.

SOA is an architectural software concept whose core working is based on services, a functionality that can perform any specific task and facilitates to support business requirements. In an SOA environment, resources are made available to other users within the network as independent services that are accessible across the network in a standardized way.

SOA based architecture delivers a number of benefits which includes the following:

• Reduced time to market,
• Improved business alignment for growth
• Reduced costs and business risk.

Each Service Oriented Architecture plays one or more of three roles:

• It is a web service responsible for deciding the type of information exposed. A service provider has to make trade-offs between availability & security.
• A service broker or service register is responsible for making information available to a requestor. A service broker has to decide the amount of information transfer.
• The service requestor or Web service client requests for service and binds to the service provider in order to call upon one of its Web services.

Now, if we have a central location where all services are registered, service clients need no longer worry about how to find them, nor how to communicate with them. So how is that wrong? The problems arose from having a central pivotal element in the application design which actively inhibits change. With application development you will soon be confronted with the need for change; either the “customers” want a slightly different service interface, or you yourself want to incorporate new functionality. This causes friction because you can no longer consider the service interface as your own, and unexpected changes may break other applications. You are left with basically two alternatives: create different versions of the interface, or coordinate releases over the boundaries of applications or even departments.

Enterprise Service Bus soon targeted this problem, allowing us to quickly develop variations on services, but also use service composition and create aggregated interfaces. We can create the basic service once, and then implement the variations in the ESB. The Middleware layer, sitting in-between services and their clients, grew with the addition of increasingly complex compositional technologies, allowing automated processes to use a high-level script (BPEL). All of these with glorious amounts of XML, consuming and producing SOAP services. As a result, we have a feature-rich and highly volatile interface layer with actual business functionality in it, which often prevents development agility for the backend applications through the rigid interface specifications.

Now the problem arose while meeting the organizational goal of combining high-quality software with a quick time-to-market. SOA forces IT into using strict rules on development practices, while the ESB searches for ways to bypass those rules. At the same time, both goals clamor for high levels of reuse to reduce cost. Unfortunately, the most important effect of chasing reuse in the context of strict specifications and high-productivity platforms, is that all applications are increasingly tied together into a giant ball of mud. No application can be changed without implications to many others, and release measure of once per four months (or slower) have become the norm in many large organizations

Microservices got into the Limelight

Microservices in a way, are the next step in the evolution of Service-Oriented Architectures. Basically, this architecture type is a particular way of developing software, web or mobile applications as suites of independent services, known as microservices. These services are created in a way that each service serves only one specific business function, such as User Management, User Roles, E-commerce Cart, Search Engine, Social Media Logins, etc. Furthermore, they are completely independent of each other, meaning they can be written in different programming languages and use different databases. Centralized services management is almost non-existent and the microservices use lightweight HTTP, REST, etc for communicating between themselves.

Microservices originated in a workshop of software architects held near Venice in May 2011. They used the term “microservice” for the first time, to describe the common architectural style that many of them had been recently exploring. In May 2012, the same group decided on “microservices” as the most appropriate name. However, major tech companies such as Microsoft, Amazon, Netflix, and Facebook, have been working with microservices for more than a decade. Other people have called them “Micro Web-Services” or “fine-grained SOA”, before coming up with the commonly accepted name. Martin Fowler, a pioneer in the world of microservices, who once said that we should think about SOA as a superset of microservices.

“A microservices architecture extends to the loosely coupled services which can be developed, deployed, and maintained independently. Each of these services is responsible for a discrete task and can communicate with other services through simple APIs to solve a larger complex business problem.”

Microservices makes it easier to scale up the development effort. Once developed, these services can also be deployed independently of each other and hence it’s easy to identify hot services and scale them independent of the whole application. It also offers improved fault isolation whereby in the case of an error in one service, the whole application doesn’t necessarily stop functioning. When the error is fixed, it can be deployed only for the respective service instead of redeploying an entire application. If you are able to make the pieces of your application essentially ignorant of how they need to communicate with the pieces around them, you can create a buzzing cloud of busy bees, each performing some seemingly independent task, but together achieving great things.

Certainly, many of the techniques used in the microservice community have grown from the experiences of developers integrating services in large organizations. When comparing Microservices vs SOA, they both rely on services as the main component but they vary greatly in terms of service characteristics.SOA is about organizational structure rather than tools and standard protocols, microservices are about business agility rather than — again — tools and standard protocols

Conclusion

One cannot simply say that one architecture is better than the other. It mainly depends on the purpose of the application you are building. Just like the development of a new car, this only has a chance of long-term success if marketing, sales, and production work as one team and the product is the thing you sell to customers, not the thing you use to produce it with. We can only expect to get a fair chance at success if we start seeing change as a continuous stream of small steps.

SOA is better suited for larger, complex enterprise application environments that require integration with many other applications. That being said, smaller applications are not a good fit for SOA as they don’t need messaging middleware components. Microservices, on the other hand, are better suited for smaller and well-partitioned web-based systems.