Key elements for building a microservices architecture 

Key elements for building a microservices architecture 

Here are some key tasks to create an effective microservices architecture. Take a look!

The architect’s job is to provide the framework where developers will build their code so that all the pieces of the application fit together. 

When building a microservices architecture, a project architect focuses on a few key tasks that we will address in this article. 

Problem decomposition 

Faced with complexity, most people try to break the problem down into manageable parts. They do this so they don’t have to try to fit all the details of the problem into their heads. Instead, they break the problem down abstractly into a few key parts and then look for the relationships that exist between these parts. 

In a microservices architecture, the architect breaks the business problem into fragments that represent discrete activity domains. These fragments encapsulate the business rules and data logic associated with a particular part of the business domain. 

While you may want microservices to encapsulate all the business rules to perform a single transaction, this is not always feasible. Often, you will have situations where you will need groups of microservices working on different parts of the business domain to complete an entire transaction. An architect separates the service boundaries of a set of microservices by looking at where the data domain does not seem to fit. 

For example, an architect may look at a business flow that will be carried out by code and realize that it needs information from both the customer and the product. The presence of two discrete data domains is a good indication that there are multiple microservices in play. How the two different parts of the business transaction interact usually becomes the service interface for the microservices. 

Separating a business domain is an art form rather than a black-and-white science. The following guidelines can be used to identify and decompose a business problem into microservice candidates: 

1. Describe the business problem and listen to the nouns you use to describe it. Using the same nouns over and over again when describing the problem is often an indication of a core business domain and an opportunity for a microservice. 

2. Pay attention to verbs. Verbs highlight actions and often represent the natural contours of a problem domain. If you find yourself saying, “Transaction X needs to get data from thing A and thing B,” that usually indicates that there are multiple services in play. 

3. Look for data cohesion. As you break your business problem into discrete parts, look for pieces of data that are closely related to each other. If during the course of your conversation, you are reading or updating data that is radically different from what you have been discussing so far, you should look out for another service candidate. 

Establishing service granularity 

Once you have a simplified data model, we can begin the process of defining what microservices architecture you will need in the application. 

The goal is to take these important pieces of functionality and extract them into completely self-contained units that can be built and deployed independently of each other. However, extracting services from the data model involves more than repackaging the code into separate projects. It also involves extracting the actual database tables that the services access and allowing only each individual service to access the tables in its specific domain. 

Having broken a problem domain into discrete parts, we will often find ourselves struggling to determine whether we have achieved the right level of granularity for the services. A microservice that is too coarse or detailed will have a number of telltale attributes. 

When creating a microservice architecture, the question of granularity is important, but you can use the following concepts to determine a correct measure: 

1. It is best to start broadly with a microservice and refactor it into smaller services. It’s easy to overdo it when you start your microservice journey and turn everything into a microservice. However, breaking down the problem domain into small services often leads to premature complexity because microservices become nothing more than detailed data services. 

2. Focus first on how your services will interact with each other, as this will help establish the overall interface for the problem domain. It is easier to refactor it from too coarse-grained to too fine-grained. 

3. Service responsibilities will change over time as your understanding of the problem domain grows. Often, a microservice acquires responsibilities as a new application. What starts as a single microservice may become multiple services, with the original microservice acting as an orchestration. 

Defining service interfaces 

The last part is about defining how the microservices in your application will communicate with each other. When building business logic with microservices, the interfaces for the services should be intuitive, and developers should know the rhythm of how all the services in the application work by learning one or two of the services in the application. 

In general, the following guidelines can be used to think about service interface design: 

1. Adopt the REST philosophy. The REST approach to services is fundamentally the adoption of HTTP as the invocation protocol for services and the use of standard HTTP verbs (GET, PUT, POST, and DELETE). Model your basic behaviors around these HTTP verbs. 

2. Use URIs to communicate intent. The URI you use as endpoints for the service should describe the different resources in your problem domain and provide a basic mechanism for resource relationships within your problem domain. 

3. Use JSON for your requests and responses. JavaScript object notation (in other words, JSON) is an extremely lightweight data serialization protocol and is much easier to use than XML. 

4. Use HTTP status codes to communicate results. The HTTP protocol has a large number of standard response codes to indicate the success or failure of a service. Learn these status codes and more importantly, use them consistently across your services. 

To sum up 

All of the basic guidelines lead to one thing — make your service interfaces easy to understand and functional. Want a developer to sit down and look at the service interfaces and start utilizing them? Then make the interfaces clear and easy to use. 

White Paper

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need. 

See All Posts