Service-Oriented Architecture is a style in software development and design. In SOA, applications provide services to other applications or components through a network. This approach to software design makes it easy for components on different networks to work with each other.
Microservices are part of an SOA architecture where applications are a sum of independent service units. An application has small modules with well-defined interfaces, each with a team. The team learns and operates that module from end to end. The team, usually of 5-10 people, is responsible only for that module.
Let us take an e-commerce application as an example. The client who accesses the application through the internet interacts with the UI Microservice. However, underneath, there is a Search Microservice, a Payments Microservice, and Reviews Microservice, all of which are built and maintained independently in a Microservice Architecture.
Web APIs are application programming interfaces that enable web users to extend functionalities of a web server or web browser. An example would be YouTube API, which when installed on a website enables the website to display videos. The Twitter API allows tweets to be shown on a website.
Monolithic Applications vs SOA and Microservices Architecture
SOA and Microservices represent a shift from monolithic applications. Monolithic applications are built as single units, which differs vastly from today. The main problem here is that developers cannot use different technologies to implement different functionalities. In addition, if one functionality fails, the whole monolith also fails, which might lead to frequent downtimes. Scaling is also difficult when working with monolithic applications. Scaling will normally require a complete rebuild of the entire application to improve capacity.
Enterprise applications today will have three layers as opposed to one. The first is usually the database, then a client-side user interface (which is what we see on the browser side), and a server-side application. The server-side application is what handles the logic on the application as well as retrieving and updating the database. The server-side application is a monolith because employs one technology and improving it will involve a rebuilt that holds the whole server-side app from functioning.
SOA Principles
To understand the Service Oriented Architecture better, there is a need to look keenly at the principles behind the implementation. First, services tend to follow a standardized service contract so that client applications can understand the purpose of the service.
In addition, web services are loosely coupled. There is not too much dependency between them so when a web service fails, the client application does not fail as well. There is a great emphasis on the abstraction of web services. The service will normally not expose how its functionality works. It should simply provide the client application with instructions on how to use it.
Another important principle is service interoperability, so services should use standards that allow subscribers sets of subscribers to use it. Web services will implement standards such as XML and HTTP communication. Reusability is equally important where developers will build logic into services in a manner that makes it possible to reuse. There is no need to rewrite code with similar logic in different applications.
Microservices Architecture
In an SOA, services offer different features to the application. In contrast, a microservices architecture has its components as tasks that perform different functions independently. The focus in SOA is the reusability of services. In contrast, the focus in a microservices architecture is the decoupling of tasks. In addition, the communication between the various modules in microservices architecture is through complex APIs.
A major principle in this architecture is that we build microservices around business functions. This allows the developers to deploy the most appropriate technology stack to fulfill the function. As highlighted earlier, the development team responsible for a microservice takes ownership and is continually working to improve it.
Microservices allow for organic growth of systems. Because microservices are independently deployable, the system can add more features and functionalities with little effect on the existing ones. If a microservice is not working as expected, it can be removed or replaced. It also allows the implementation of new technologies gradually without overhauling the whole system.
Microservices are great for websites that have many small components. However, not all types of businesses or workflows have tasks that can be split this way. Attempting to implement a microservices architecture in such a scenario could cause glitches in the whole application. Still, microservices architectures are great for rapidly growing businesses that are launching new features on the go. It is also useful when the business has development teams spread out in different parts of the world.
Web APIs
The world is only starting to use API technology. There are little to no rules on how to build or implement them. APIs exist for payments, finance, weather, messaging and so many other areas with only continue to grow. But the most useful area of API application has been the exchange of data across applications. Microservices use complex APIs to fetch information from one another. Within an organization, this happens through private APIs.
There are many other examples of the ubiquity of APIs both in consumers’ daily lives and in business as well. For instance, when you want to order food through an app that gives you access to menus from dozens of restaurants, an API gives you access to the database. When making payment for the order, an API, such as the PayPal API, facilitates the exchange of information and verification of payment. Once payment is acknowledged, both the consumer and restaurant get notified. It is likely that you will have included your location for delivery, and this is enabled through another API, such as Google Maps.
Today, the success of businesses somewhat depends on how well they can pull different APIs together to build solutions. Developers in this age must be able to sieve through and determine which APIs solutions to put in the projects as opposed to attempting to build things from scratch. It makes for a faster and more accurate development process.
If your organization would like help in picking, building, or implementing the right technology architecture, check out Transcendent Software. We are an experienced IT firm with over two decades of helping clients make the best use of technology.