There are two different architectures for app development, respectively as Micro Services and Web Services. While both of them have some distinct advantages, it is important to know their differences in detail. Let us define, provide details and explain the pros and cons of both of these app development architectures.
Web Service architecture exposes the functionalities and API of the app over the HTTP. Thus it actually helps different technologies to communicate and collaborate with each other. Web Services are equipped to run over different programming languages or operating systems by utilising common formats such as XML, Jason, etc. Just because they are not built to run only on one operating system or not tied to a single programming language, they allow communication of two apps built with different languages. Basically, this architecture serves the purpose of connecting multiple apps or services into a Service Oriented Architecture (SOA).
Micro Service architecture is thoroughly independent which is built to deploy for a particular business logic. The main reason for its popularity is its capability to break a large software application into smaller and loosely connected modules that are independently capable to run a unique process. Micro Service architecture is built by event-driven APIs, messaging or through non-HTTP backed RPC. Just because of these broken modules working independently, any application doesn’t get affected by the failure of a single module. This is ideally used is large enterprise level applications.
Now we need to understand how these two architectures actually work. To explain this we are going to take the example of an online store.
Typically, in a web service, the architecture is monolithic in character. The constituents functions of this architecture relate to a single database and together they make the communication with other apps possible. All the functional tasks of such an app invariably depend on the core database and hence if there is a functional problem, the whole app will suffer or stop working. Web services typically suit relatively smaller and easy to maintain business apps with less number of functions.
In complete contrast, the online stores that adopted Micro Service architecture can never stop working or can never face issues that make the whole app stop responding. This happens because in Micro Services different functional contents are deployed independently and any issue with a single component doesn’t derail the working of the whole app. This is why major online retailers like Amazon has switched on to Micro Services. When each component work for a single function, dealing with it becomes much easier. This architecture particularly suits gigantic and robust business apps serving a huge audience with a multitude of products and too many functions.
Let us now explain the various constituents and their roles in the web service architecture.
Provider: The web service provider is responsible for building the app and deploy it on the client app like a browser or an operating system for the larger audience to use it.
Requestor: The role of the requester is to request the web service provider to deploy the service. For example, a browser or OS make a request to a web app for rendering.
Broker: In between the role of the UDDI is to locate the particular web service required by the client application. The broker is mainly service registry that lists the various web services.
This is how web service architecture works:
Publish: The web service provider makes its existence known to the broker or service registry. This makes the service accessible to the client apps.
Find: Now when the client app requires it consults the broker or service registry to find the required web service.
Bind: After the client application knows about the web service it binds or invokes the service to make it available through its app to the larger audience or end-users.
Let us now have a look at the key characteristics of web services:
XML-Based: For representing the data at the layers of representation and transportation Web Service architecture depends on XML. Just because XML is a common and uniformly understood language, the web service can be deployed without any platform-specific dependency.
Loosely Coupled: Web Services remain loosely coupled which means when the web service goes through changes in the future, the way client started deploying it will remain unchanged.
Both Synchronous or Asynchronous deployment: Web services support both synchronous and asynchronous functionalities. While in synchronous deployment client has to look forward to the web server to complete the operation, in case of asynchronous deployment client can invoke a web service and in parallel deploy other functions of his choice.
Support for Remote Procedure Calls (RPCs): Web services offer support for Remote Procedure Calls (RPCs) to allow the clients to invoke functions, procedures, and methods remotely using the same XML protocol.
A Micro Service Architecture is built with the following components:
Let us now explain how the Micro Service architecture really works and the respective role of these components.
Clients: Different types of clients that try to perform different types of actions like search, build, configure etc. is the basic ad first component of the architecture.
Identity Providers: Identity providers basically take the requests from the clients, validate them and communicate the same through the API Gateway.
API Gateway: In Micro Service architecture clients don’t communicate the services directly and so, requests are communicated to the appropriate Micro Services through an API Gateway. Using the API gateway for processing requests has many advantages including the following.
Messaging Formats: In Micro Service architecture two types of message formats are permitted, respectively as Synchronous Messages and Asynchronous Messages.
Data Handling: Every micro service comes with a private and small database to deploy the required business functionality locally. Through the service API, such databases are updated from time to time.
Static Content: Whenever multiple Microservices internally communicate they make the communication known through the static content which is uploaded to a cloud service that further can deliver to clients through a Content Delivery Networks (CDN).
Management: This is the component that takes care of the service failures and that balances the services on different nodes.
Service Discovery: This component works as a guide to various nodes to find the services required by the clients.
Let us now explain the key properties of Micro Services.
Allowing breaking into multiple components: A software built to support micro-services can be broken into multiple components. This allows deploying each of these services independently without undermining the integrity of the whole application.
Focused on business priorities: The popularity of micro-services can mainly be assigned to the ease of prioritising certain functions. Thanks to microservice architecture a business can deliver its clients a neat and singular function without depending on the whole app. This allows faster performing of certain tasks.
Simple routing: The request processing and deploying process in microservices is very simple. It follows the simple routing process beginning with receiving requests, processing them and generating a response subsequently.
Decentralized management: Equipped with different technologies, platforms and being able to deploy as tools across various client apps, it offers a highly decentralised management. With each micro-service having its own unique database, it also gets the boost of decentralised data management.
Failure resistant: When several small services communicate, any one of them fail to respond. Microservices are built to deal with such failure with decentralised architecture. Thanks to its decentralised nature one failure with any one service don’t affect the other services and their performance.
Future-ready: This architecture is equipped to go with the changes and the evolving factors. Unlike monolithic architecture, micro-services can anticipate the devices that in future can deploy the apps.
Finally, we need to reduce our discussion to the key advantages and disadvantages of both the web and microservices. Let us explain below the pros and cons of microservices.
We have already discussed micro-services at length and found several advantages. But in spite of the popularity of these services for several reasons, they equally have some crucial problems.
Let us have an understanding of the pros and cons of microservices in detail.
Both web services and microservices have their own share of strengths and weaknesses. While some apps will always find the web service architecture more suitable, there will be too many others finding microservices perfect for their application. Web services fit smaller applications catering only a limited number of functions with less demand on prioritisation functions. Microservices are more appropriate for apps with a large number of functions with the mission-critical priority of functions.