• There are no suggestions because the search field is empty.

Microservices Framework

A microservices framework takes a big monolithic architecture that isn’t easy to maintain or change and make it easier to scale, replace, and change. Microservices address the concerns of the bigger systems, creating a framework that is a set of services that communicate using a messaging system such as REST over HTTP.

A microservices framework makes it possible to replace one piece of an application puzzle if necessary, scale only one piece because it is necessary for forward movement, or eliminate something that is no longer necessary and only adds to technical debt.

However, a bad microservices framework will do exactly the opposite. It isn’t necessarily easy to develop a distributed system - but there are many, many frameworks out there that make it possible.

Microservices Frameworks and Patterns

Within microservices, there are different types of patterns to pay attention to:
Application Architecture Patterns: These include monolithic architecture where the application is a single unit or microservices architecture, where each application is a collection of coupled services.

Decomposition: How do you decompose an application into its services?
Deployment patterns: How do you deploy the application’s services? There are many different options here including:

  • Multiple service instances per host
  • Service instance per host
  • Service instance per VM
  • Service instance per Container
  • Serverless deployment
  • Service deployment platform

Cross Cutting: Which frameworks do you use: a Microservices Chassis or an Externalized Configuration?
Communication patterns in microservices are also quite important because they help to dictate development, messaging, remove procedure invocation, and domain-specified protocol. There is also a question of external API and how external clients communicate with the services. Another facet to consider is transactional messaging – meaning how does the microservices framework publish messages.

Microservices Design Frameworks & Pattterns

There are a few different microservices design patterns that are the most common. They include:

Aggregator Microservice Design Pattern: The most common microservices design pattern, Aggregator is a simple web page that uses many services to achieve their task set out by the application. Since each service uses a lightweight REST mechanism, the web page can retrieve the data. If nothing needs to be displayed, the aggregator simply collects the data from each individual microservice and applies the business logic to it.

This design pattern uses the DRY principle and can scale independently on the X-axis and Z-axis.

Proxy Microservice Design Pattern: Proxy microservice design pattern is similar to Aggregator but no aggregation needs to happen on the client. Proxy can scale on the X-axis and Z-axis as well and is typically used when the service does not need to be exposed to the consumer and instead goes through an interface.

There are two types of proxy microservice design patterns: dumb and smart. Dumb proxy delegates the request to one of the services whereas a smart proxy uses some data transformation is applied before the response is served to the client.

Chained Microservice Design Pattern: Chained microservice design patterns produce a single consolidated response to a user request. The services may form a chain where they have to talk to each other (using a synchronous HTTP request). Here, the client is blocked until the chain has been completed, even if the requests are different or the commands look completely different. Within a microservices framework, the idea is to not make the chain too long so that there isn’t too long of a wait or an elongated response time.

Branch Microservice Design Pattern: This microservices design pattern extends Aggregator and allows for a simultaneous response from two different chains of microservices.

Shared Data Microservice Design Pattern: When designing a microservices framework, one of the biggest principles is autonomy. With shared data microservices design patterns, the service needs to be full-stack and have complete control over all of the components, including UI, middleware, persistence, and transaction. This will help the service choose the right tool for the job and become more efficient.

Asynchronous Messaging Microservice Design Pattern: There are some limitations within the REST design pattern due to synchronicity. Some microservices will instead use messaging queues to help alleviate some of these limitations. This will allow one service to call another while communicating through a messaging queue – and thus, be able to carry out more complex activities.

For more information about microservices and how you can use them in your application and software development, CLICK HERE for a free white paper.