Microservices have become increasingly popular in the modern-day tech world. If you’ve been previously using service-oriented architecture (SOA), you might be wondering how the two are different. Developers looking forward to creating a new solution would also benefit from knowing more about these architecture types.
What is an SOA?
SOA allows services to communicate through different languages and platforms. It is based on the principle of loose coupling (components depend on each other to the least extent possible).
SOA enables two clients to communicate with one another even if they are not closely related. This is extremely convenient for developers as they don’t have to adopt two entirely different software architectures. But generally, SOA system can be divided into four key service types.
One such service is Enterprise and it assists in executing the main functions stated in a business’ services. It is heavily dependent on infrastructure and application services to be able to complete the calls.
The second service is Business and it defines every major business operation which is presented via Web Services Definition Language (WSDL), XML, and Process Execution Language (BPEL).
The third service is Infrastructure and it is responsible for several functions such as auditing, authentication, logging, and security. This service can be requested via enterprise services.
Last, we have the Application service, which is mainly requested through the UI (User Interface) and is bound to a particular context mandated by the application.
These are the key characteristics that distinguish service-oriented architecture vs. microservices.
Examples of SOAs
There are dozens of big brands implementing SOA into software development — Harvard Medical School, Motorola, NASA, to name a few. However, among the most prominent is the First Citizens Bank. They not only provide services to their own customer base but also cover more than 20 other institutions.
Thomson Reuters is another prime example. The company provides knowledge for companies and professionals and manages 4,000 services, which are all available for their customers. The reason these companies implement such systems is the fact that they allow for real-time analysis of business events, speed up marketing time, and streamline most of the business processes.
Pros and cons of SOA
Pros of SOA:
- Independent location. It doesn’t really matter where the services are located. They can be published on one server or several different ones. Consumer requests would still work fine.
- High reusability. Services can be reused regardless of their earlier interactions with other services. This reusability is possible due to the SOA applications infrastructure — a combination of small self-sufficient functions.
- Improved scalability. You can easily scale up the system since multiple layers of a single service can run simultaneously on different servers.
- Parallel development opportunities. Thanks to the layer-based architecture, developers can work on independent services and have them both delivered fast. This not only increases productivity but also enables businesses to reduce costs.
Cons of SOA:
- Large upfront investment. SOA architecture is a great choice for further business development. It enables your team to work on several applications simultaneously at a smaller cost. However, its implementation is usually a pricey endeavor.
- Greater load and increased response time. In SOA, each interaction between services is followed by a full validation of all input parameters. As a result, the load gets extremely heavy, which in turn prolongs the response time.
- Vast variety of services. SOA has a very special approach to operation. Services constantly exchange messages while executing tasks. Consequently, the number of those messages gets overwhelming, and this peculiarity makes it difficult to ensure decent service management.
What is a microservice?
Microservice architecture (MSA) is a software development practice where a service is divided into smaller service components. The microservices are autonomous and often completely separated. It’s common to have different teams handling each microservice.
In this architecture, complex applications are formed from small, autonomous processes that interact with each other through language-agnostic APIs. The important peculiarity of this system architecture is the fact that it has to be designed correctly from the start. In other words, each service should be able to close automatically whenever it’s not used and be able to independently deploy itself when necessary.
The microservice architecture makes scaling the application way easier while reducing tech debt and increasing agility. Also, each microservice can be reused as a part of a different application. When there’s a need to upgrade a particular microservice, the previous one is easy to replace.
Examples of microservices usage:
- Netflix – A team of engineers runs several business operations that are powered by asynchronous orchestration of tasks which rely on microservices. This allows the company to prepare titles for streaming across the globe seamlessly.
- eBay – The company runs more than a 1000 microservices granting them the ability to remove all kinds of dependencies and add new functionality without taking the platform down.
- PayPal – Everytime a person hits the “make a payment” button, a special microservice app is triggered. This allows the company to modify/update all modules without the need to remove it (i.e continuous support).
Pros and cons of microservices
Pros of microservices:
- Increased agility. All microservices allow for increased flexibility, which makes it easy to pivot segments of an app.
- Reusability. Software engineers can reuse as many services as they desire. This makes cross-platform development significantly easier.
- Independence in case of failure. Broken services will not crash the application if safety measures are in place.
- Enables parallel development. Development teams are able to create, maintain, and deploy all microservices autonomously. This also allows for more scalability as every component can be adjusted separately.
Cons of microservices:
- Increased deployment effort. The deployment of microservices entails a lot of work as all services you’ve included should be able to deploy/undeploy themselves. Another thing to keep in mind is that each service needs to be isolated in case of a crash.
- Complexity. The system puts a lot of stress on developers as it’s easier to run a single program than to juggle different services. Some of this stress is mitigated with tooling, but as the program grows, it becomes harder to run it properly.
- Challenging testing. Unlike the monolithic system, MSA testers need to check every service for an update, which is rather time-consuming.
- Communication slow-downs. The more services are added to the system, the harder it becomes to handle errors. It gets especially difficult when distant calls are required.
Microservices vs. SOA: Comparison
Comparing an SOA vs. Microservice might seem unnecessary but you’d be surprised at how many functions they share. Keep in mind that all these functions have limitations that are directly tied to the scope of the project.
|Four service types: business, enterprise, application, and infrastructure.||Two service types: functional and infrastructure.|
|SOA has an open sharing architecture approach, which presumes sharing as much as possible.||MSA has limited sharing architecture approach, which presumes to share as little as possible.|
|Communication is executed via Enterprise Service Bus (ESB).||Communication is executed via a simple messaging system.|
|SOA is multi-threaded, hence there are more overheads to manage I/O.||MSA is single-threaded and normally employs Event Loop for non-locking I/O handling.|
|SOA favors traditional relational databases.||MSA favors modern relational databases.|
|SOA emphasizes the reuse of business functionality.||MSA emphasizes “bounded context”.|
|SOA follows common standards and governance.||MSA doesn’t follow common standards. On the contrary, it favors collaboration and freedom of choice.|
|SOA supports multiple message protocols.||MSA supports lightweight protocols (e.g. HTTP/REST, Thrift APIs).|
|SOA needs to have single data storage for all the deployed services.||No need for a common Application Server since all services can be independent. Commonly uses cloud computing.|
|SOA needs a systematic change to modify the monolith.||MSA needs a systematic change to create a new service.|
|SOA does not commonly use containers.||In MSA, containers are used very often.|
|DevOps and Continuous Delivery are not mainstream yet (although they already gain popularity).||DevOps and Continuous Delivery are mainstream.|
Microservices vs. SOA Differences — Which One To Choose?
There is no definite answer to this question. In some cases, SOA is the best option; in others, it won’t be as effective as microservices. The differences are in the details. It is essentially down to what your business goal is as well as the kind of project your team is working on.
There are advantages and disadvantages to both architectures. As you might have noticed, both SOA and MSA can be developed in different technology stacks. This means that you’ll have development diversity no matter what you choose. You can also arrange the development of services by several teams provided that they are well aware of the SOA communication system.
If you are looking for an opportunity to scale easily and would appreciate the ability to deploy new versions of the same service more often, then you might not what to go for SOA. In this case, microservices is a much better option.
Also, when it comes to SOA, chances are that it might cause you additional trouble. If ESB stops responding properly at any given moment, all the services will be affected. ESB is the only available means of communication, and when a single faulty service sends too many requests, it might get overloaded. In this regard, microservices do a better job because, in this architecture, each service works independently. Therefore, if one microservice starts acting out, the problem stays there and doesn’t affect other services.
It’s impossible to tell which architecture is less complex as they are both pretty heavy and would require developers to deal with distributed systems and other challenges. No matter which one you choose, you’ll have to take care of a proper communication system between services. This also means that developers may have a difficult time with unit testing.
Another important concern is data storage. SOA requires one common server, whereas microservices don’t. On the one hand, shared data storage is a good thing because it enables data re-use capabilities. On the other hand, it’s not very convenient since it creates an unnecessary dependency between services. Finally, microservices and SOA provide different opportunities in terms of size and scope as SOA is generally much larger.
You might want to choose SOA if:
- You are building a complex application. This allows you to move, adjust, and add new features without the need to rebuild the whole program again. It saves time but it will become more difficult to manage as more functions are added.
- Applications require interaction with one another. If your application needs to communicate with different architectures, SOA completely eliminates the adoption process.
- You’re building an application with the enterprise scope. If your business is constantly growing and microservices simply don’t cut it, then you might want to move to SOA as it provides more scalability.
- You are not yet ready to embrace the DevOps culture. If your development team isn’t ready to change their ways, you might encounter a few disputes which could hinder your performance.
Microservices are a good fit for:
- Smaller web-based applications. Microservices are perfect for small apps as they provide the necessary flexibility, as well as allow for further scalability.
- Projects where a developer wants to have as much control as possible. If your team wants to take full control of the project and make changes on the fly without being worried that some functions might break, microservices are the way to go.
- You want to bring the app to the market faster. This architecture will allow you to push MVP (Minimum Viable Product) significantly faster.
Over the past five years, microservices have become extremely popular among developers, yet it doesn’t mean you have to adopt it. What we suggest is that you don’t follow what everybody else does and instead pick the right technology for your project. There’s no ultimate answer to the Microservices vs. Service-Oriented Architecture question.
Therefore, you should assess your capacity, skills, and ability to adapt to a new architecture first and then decide what works best for you. If you have trouble picking the right system, you can always give us a call or drop a line. Our team is ready to assist you to bring your project to life!