Microservices with DVNITSOLUTIONS expertise?

  • Our view for microservices are small, independent, and loosely coupled. A single small team of developers can write and maintain a service.
  • Each service is a separate codebase, which can be managed by a small development team.
  • Services can be deployed independently. A team can update an existing service without rebuilding and redeploying the entire application.
  • Services are responsible for persisting their own data or external state. This differs from the traditional model, where a separate data layer handles data persistence.
  • Services communicate with each other by using well-defined APIs. Internal implementation details of each service are hidden from other services.
  • Services don't need to share the same technology stack, libraries, or frameworks.

Besides for the services themselves, some other components appear in a typical microservices architecture:

Management/orchestration. This component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth. Typically, this component is an off-the-shelf technology such as Kubernetes, rather than something custom built.

API Gateway. The API gateway is the entry point for clients. Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end.

Advantages of using an API gateway include:

  • It decouples clients from services. Services can be versioned or refactored without needing to update all of the clients.
  • Services can use messaging protocols that are not web friendly, such as AMQP.
  • The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.

Benefits of following DVNITSOLUTIONS Microservices facility.

  • Agility. Because microservices are deployed independently, it's easier to manage bug fixes and feature releases. You can update a service without redeploying the entire application, and roll back an update if something goes wrong. In many traditional applications, if a bug is found in one part of the application, it can block the entire release process. New features may be held up waiting for a bug fix to be integrated, tested, and published.
  • Small, focused teams. A microservice should be small enough that a single feature team can build, test, and deploy it. Small team sizes promote greater agility. Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.
  • Small code base. In a monolithic application, there is a tendency over time for code dependencies to become tangled Adding a new feature requires touching code in a lot of places. By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features.
  • Mix of technologies. Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.
  • Fault isolation. If an individual microservice becomes unavailable, it won't disrupt the entire application, as long as any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).
  • Scalability. Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application. Using an orchestrator such as Kubernetes or Service Fabric, you can pack a higher density of services onto a single host, which allows for more efficient utilization of resources.
  • Data isolation. It is much easier to perform schema updates, because only a single microservice is affected. In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky.

Topperforms to follow:

  • Model services around the business domain
  • Decentralize everything. Individual teams are responsible for designing and building services. Avoid sharing code or data schemas.
  • Data storage should be private to the service that owns the data. Use the best storage for each service and data type.
  • Services communicate through well-designed APIs. Avoid leaking implementation details. APIs should model the domain, not the internal implementation of the service.
  • Avoid coupling between services. Causes of coupling include shared database schemas and rigid communication protocols.
  • Offload cross-cutting concerns, such as authentication and SSL termination, to the gateway.
  • Keep domain knowledge out of the gateway. The gateway should handle and route client requests without any knowledge of the business rules or domain logic. Otherwise, the gateway becomes a dependency and can cause coupling between services.
  • Services should have loose coupling and high functional cohesion. Functions that are likely to change together should be packaged and deployed together. If they reside in separate services, those services end up being tightly coupled, because a change in one service will require updating the other service. Overly chatty communication between two services may be a symptom of tight coupling and low cohesion.
  • Isolate failures. Use resiliency strategies to prevent failures within a service from cascading. See Resiliency patterns and Designing reliable applications