Before we proceed with the deployment, we must ask the question: what are microservices? 

Microservices is a pattern or style to decompose a monolithic application into multiple loosely coupled services. Each service has a business responsibility, focuses on solving a business domain problem, is independently deployable, and communicates with other services in order to delegate work. 

The microservices pattern evolved to solve the following problems with the monoliths: 

• Monolithic apps are not easy to refactor, changes are not local, and they are very tightly coupled.
• Understanding the application is difficult. Adding a new feature requires cascading changes.
• Deploying multiple instances requires resources, such as RAM and CPU, and so you need more hardware to spin off multiple instances of your monolithic app.
• Adopting new technologies, frameworks, or languages is difficult, such as being unable to develop one module in Java and another in Golang.
• Scaling is difficult. You cannot deploy multiple instances of a module when required. Suppose you have two modules, A and B, and the bulk of the client requests are only accessing module B's services. You cannot deploy B separately, since A and B are packaged together. If we deploy multiple copies of the app, then A will unnecessarily eat up space and resources, and we will need more hardware and instances to handle the scalability and availability required.

Loosely coupled microservices can be developed separately with the following benefits:

• Each service is responsible for one specific task, so it is easy to understand and refactor
• They are easy to deploy
• They are easy to scale, as you can spin off the required services
• It is easy to adopt new frameworks, languages, data stores, and so on (polyglot architecture), since the change is only local to that specific service

There is no silver bullet that will solve all the design-related issues, and the microservices architecture has the following drawbacks:

• Alhough scalability is increased, deployment of the system as a whole is complex
• The microservices pattern forces interservice communication and adds additional complexity to handle the communication failures
• The unavailability of one service can bring down the system, and additional complexity is required to handle the availability issues
• Distributed transactions are slow and prone to failure, so complex patterns (such as Sagas) need to be applied to handle it
• A request can span multiple services, and this requires special attention in terms of traceability and monitoring

There are several design patterns for decomposing a monolithic app into multiple services and balance the forces. You can get details of microservices at https://microservices.io/.

Apache Ignite can be used to build a fault-tolerant, performant, and scalable microservice application. Ignite-based deployment offers the following advantages over traditional microservices deployment:

• The service grid can handle the microservice's life cycle and inter-service communication (service injection)
• The service grid is capable of automatically balancing the service deployments to achieve high scalability
• The grid manages the microservice's availability—even for the singleton cluster deployment, availability is not compromised
• The performance of microservices running on Apache Ignite grid is faster than the application server-based deployment, as the services run on in-memory
• Accessing a data node for application data or service nodes to delegate a task is faster, since all nodes are interconnected and running on in-memory