The A to Z Of Microservice Architecture

Last Updated on: July 8, 2020

Business requirements change, mostly on a weekly or daily basis, compelling the team to stay nimble and adapt frequently. However, from decades, we are constrained by the IT’s ability to build, deliver, produce, respond to that change fast. With microservice architecture, we could reach the point where there is a major sort of deflection point, which is able to address the change.

What’s Microservice? Is It Useful and Powerful?

In the world of software engineering, Microservices has emerged as a big buzzword.

The simplest way to understand a microservice is that it’s an application that does only one thing, and does it really well.

Microservice are a software development approach that breaks large software projects into loosely coupled modules that communicate with each other using simple APIs. They positively impact business capabilities and aids in completing development, testing, and deployment in a short time span.

To explain how powerful microservice architecture is, let’s take an example of an e-commerce company. Online merchants have to add new products frequently to the site and detect if there is a problem in the service related to the product. Typically, it could be problematic in terms of the time to remedy them in terms of code, testing, and deployment in the non-microservice world (monolithic), whereas in the microservice world, we could have a fix within a few hours or the very next day.

Microservice Architecture Style Structure

 

In the figure,

Client

A client could be of any type, say Mobile client, Web application communicating using the standard protocol like HTTPS, Sockets, etc. Each and every client have to interact with the system using a single endpoint.

Base Service

• This is the single point where all the client application would connect in order to get/set the data.
• All the client-facing APIs/Swagger/Common Logging/ Error reporting would reside here.
• It provides abstraction on all the micro-service; the client would request the base service, the base service would delegate the request to the respective service and forwards the response to the clients.

 

Service Components

• Each service component would have multiple modules, but the modules would be of the same service domain.
• Each service would have separate isolated and dedicated storage; no service should have direct access to the storage belonging to the different service
• If the service wants to access the data of another service, the service should request the owner service of the particular storage/data.

 

Defining Characteristics of a Microservice

Here are some well-defined characteristics of a microservice-

• In a microservice architecture, services are small, discreet, independent, loosely coupled and having bounded context.
• 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 the services themselves, some other components appear in a typical microservice architecture:

Management

The management component is responsible for placing services on nodes, identifying failures, rebalancing services across the nodes, and so on.

Service Discovery

Maintains a list of services and the nodes are located on. Enables a service lookup to find the endpoint for a service.

API Gateway

The API gateway is the entry point for clients like a broker. Clients don’t call services directly. Instead, they call the API gateway, which forwards the call to the appropriate services on the back end. The API gateway might aggregate the responses from several services and return the aggregated response.

The advantages of using an API gateway include:

• Isolate the clients from how the application is partitioned into microservices
• Isolate the clients from the problem of determining the locations of service instances
• Provides the optimal API for each client
• Reduces the number of requests/roundtrips. For example, the API gateway enables clients to retrieve data from multiple services with a single round-trip. Fewer requests also mean less overhead and improve user experience. An API gateway is essential for mobile applications.
• Simplifies the client by moving the logic for calling multiple services from the client to API gateway
• Translates from a “standard” public web-friendly API protocol to whatever protocols are used internally

 

What to Consider While Designing Microservice Architecture?

Making use of personas to understand what data our business needs

• User personas are a representation of a class of users of our system, personified as an individual with specific needs, skills, goals, and frustrations. This concept originated in the UX community and is widely used in design processes.
• Thinking of users in terms of personas helps build empathy and design systems that are a better fit for the jobs they need to get done and that avoid known obstacles.
• Turns out this is an effective way to understand internal users as well, not only customers. So, we can apply them to understand the information needs of our business stakeholders when it comes to making release decisions.

 

Domain Design

• Microservices principles encourage you to focus your service boundaries concur business domain boundaries in a bounded context.
• Having a domain design helps to determine the microservices.
• Steps for designing a domain-

 

 

Sample Domain

For example, in e-commerce, the domains can be divided into parts. Dividing the system into domains would help us to define the different microservice. In the above image, we have divided the system into three domains which would have separate storage for each domain.

User Stories

A very strategic way to create software that meets users’ expectations is to begin with “user stories”. They are nothing but simple, clear, and brief descriptions of functionality that will be valuable to end users.

User Stories offers a requirements process that helps to save time, cut rework, and promotes better software development.

User Stories helps in breaking down the system in modules, organize tasks and prioritize them. With the help of it, we could decide various microservices and interactions between those microservices. It also helps the teams to work parallely on different user stories.

Benefits of Microservices

• Loose coupling

It minimises the risk that a change made within one element will cause unanticipated changes within other elements. Limiting interconnections can help isolate problems when things don’t go well and simplify testing, maintenance, and troubleshooting procedures.

• Encourage continuous refactoring and rewriting

By enforcing stricter decoupling, it becomes easier to internally refactor or rewrite a service as long as it doesn’t impact its API in a backward incompatible manner.

• Lower dependency on a single technology 

If services communicate over some technology independent medium (like HTTP or ZeroMQ), it doesn’t matter what technologies are used to implement a service internally. This opens up the ability for teams to pick their own technologies and play with new ones.

• Scale Independently 

If one service is receiving too much load to handle, it can be scaled up independently from the rest of the infrastructure.

• Localise failures 

If one service crashes, for whatever reason, it doesn’t take down the rest of the system (when built with resilience in mind, see next point). Independent monitoring of services also can make it easier to localize problems and bugs.

• Can be released on independent release cycles

Rather than having a combined release cycle of the whole system, teams can release their own services as frequently as they like.

• Require zero-downtime deployment

Not strictly related to microservices, but especially important with independent release cycles, you don’t want to introduce downtime whenever somebody updates a service.

Constraints

• Complexity
  A microservices app has more moving parts than the equivalent monolithic application. Each service is simpler, but the entire system as a whole is more complex to decode.
• Lack of governance
  The decentralised approach to building microservices has advantages, but it can also lead to problems. You may end up with so many different languages and frameworks that the application becomes hard to maintain.
• Network congestion and latency
  The use of many small, granular services can result in more inter-service communication. Also, if the chain of service dependencies gets too long (service A calls B, which calls C…), the additional latency can become a problem. You will need to design APIs carefully.
• Data integrity
  With each microservice responsible for its own data persistence. As a result, data consistency can be a challenge.
• Skillset
  Microservices are highly distributed systems and might end up managing different tech stacks.

The constraints could be easily overcome by having-

• A mature DevOps culture to handle all the moving parts in an automated way.
• Project-wide standards for designing the microservices and communication between them.

 

Best Practices

Microservices architecture style’s best practices can be stated as-

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

 

Conclusion

Microservice architecture is a smart and distributed approach designed to overcome the limitations of conventional monolithic architectures. Microservices help to scale modern apps and companies while improving cycle times. It provides fast deliveries, lowers the time to market, reduces the operational cost and ready for future changes. With such features microservice is one of the most popular architectures used in the industry. However, they also come with challenges that might cause additional architectural complexity and operational burden. It’s better to hire a team of dedicated web developers who can understand your requirements and offer end-to-end development and deployment services to help you grow.

We at Systango are adept at microservice architecture development. We can help you leverage rapid development by creating a suite of modular components. To get detailed information or contact our team, visit us here.