Micro Services Vs Web Services

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.

What is Web Service?

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).

What is Micro Service?

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.

Explaining with some use cases

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.

Web service Architecture

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.

Microservice architecture

A Micro Service Architecture is built with the following components:

• Clients
• Identity Providers
• API Gateway
• Messaging Formats
• Databases
• Static Content
• Management
• Service Discovery

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.

• All services are automatically updated.
• Some messaging protocols that are not web friendly can also be used in microservices thanks to API gateway.
• The API Gateway can also take some additional responsibilities like taking care of security, load balancing etc.

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.

Pros and Cons of Web Services

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.

Web Services Pros and Cons

Pros

• Interoperability and platform-independence: Web services offer optimum interoperability allowing deployment across diverse platforms, OS platforms and flexibility to work with diverse programming languages. This platform independent nature of web services is a key selling point.
• Usability for diverse business logic: Web Services can be deployed over the web by different business systems with a variety of business logic. This helps businesses choosing the web services of their preference with ease.
• Reusability: For deployment across applications web services need no additional coding and this makes it highly reusable for different business applications across platforms.
• Easy to deploy: Being equipped to be deployed over standard web platforms and is fully equipped to communicate with different apps through XML, web services are the easiest as far as deployment is considered.

Cons

• Not performance-driven: Just because web services use plain text protocols for identifying data, the requests are much longer and this bigger size of the requests often take a toll on the performance when the connection speed is slower.
• Not for extended sessions: The core web protocols like HTTP and HTTPS in spite of their simplicity often lack what it needs to maintain a connection for an extended period of time. Such connections are stateless and the communication between the server and the client is extremely short-spanned. This makes the web services vulnerable to performance issues for longer sessions.
• Centralised architecture: Having a centralised non-component based architecture a web service is always deployed together in one piece. If any of the functions stops responding, the whole service needs to be addressed.

Microservice Pros and Cons

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.

Pros

• Ease of development: Microservice architecture allows developers the optimum flexibility to develop and deploy services. Even a small developer team can build microservice. It also allows writing codes for different services in different languages. It is easy to make a team member learn and become part of development.
• Easy integration and automatic deployment: Microservices can easily be integrated and deployed automatically by using open-source tools like Jenkins, Hudson, etc.
• Decentralised architecture allowing fault isolation: With a decentralised architecture it allows fitting into diverse business systems and applications. With any micro service being affected, the other services remain unaffected and as performing as ever because of the decentralised architecture. Similarly, any change required for a function of the app, the developers need to fix it with one micro service instead of doing it with the whole app.
• It is quicker and speedier: Microservices can start with the web container more quickly helping faster and speedier deployment.

Cons

• Complicated testing: Because of the distributed architecture the testing of such services can be a little challenging and complicated.
• Complexity and information barriers: Microservice architecture needs to deal with complexities especially for network latency for different apps, multiple message formats, fault tolerance and evolving business logic for different services. A number of services also cause several information barriers for the administrators and users. With the increase in a number of services, complexity level increases.

Conclusion

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.