Understanding the Microservices Concepts

For many years, the monolith applications dominated the web development ecosystem. Millions of monolith apps went to the internet and still millions of them going on. After years, the problem has arised: success and performance.

So how can we describe success? Let’s look at some difficults in monolith apps:

• Application Scalability
• Architectural changes are very complex
• Adding new features is increasingly complex
• Adding new features takes more time than expected
• Working with multiple developers on the same code may cause merges
• Eventually, deploying new features impact the already deployed app

These are just some type of problems we may encounter while developing monotlih app. Increasingly, most companies in the software industry adopting the microservices, where the succes and performance issues meant something. Let’s look at some advantages of microservices:

• Independence between teams
• Implementation of isolation
• Independent deployment
• Easy to identify errors
• Spesific business domain for each microservice
• Scalability for spesific microservice
• Tech independence among microservices

I will explain later how to transition from monolithic to microservice, using appropriate patterns. But in this article I will explain some terms need when we starting the microservice design and implementation

Domain Driven Design

OOP concepts is not only inheritance, abstrraction or encapsulation also it helps us to design and build microservices. OOP has the another ideas such as reusability, minimal coupling…
Eric Evans is the first mention about DDD in the his book. So what is DDD?
Domain-Driven Design (DDD) is an approach in software development that emerged to understand, design, and implement complex business domains. DDD aims to prioritize business requirements over technical details by placing the business domain at the center. This approach ensures that the software is geared towards solving real-world issues in the business world, leading to more effective and sustainable solutions.

One of the core principles of DDD is the concept of “ubiquitous language.” This refers to establishing a shared and understood language between the development team and the business stakeholders. This language helps articulate business requirements clearly and reduces uncertainties in communication. Additionally, DDD encourages the division of the business domain into small, independent sections known as “bounded contexts.” Each bounded context can employ its own consistent model and set of terms, making it easier to manage complexity in large-scale projects.

Explicitly Pusblished Interface

Explicitly Published Interface is a component of the Domain-Driven Design (DDD) methodology and plays a significant role in service-based architectures. This approach aims to define the interfaces exposed to the external world by a service or component in a clear and explicit manner. This ensures that the users of the service clearly understand which functions and capabilities are provided.

The Explicitly Published Interface principle also assists a component in hiding internal details while designing its outward-facing APIs more effectively. This allows the service to continue being used by external users without disruption, even when changes are made to the internal structure of the service. This reduces dependencies between components, enhancing the system’s flexibility and sustainability. In conclusion, the Explicitly Published Interface contributes to creating a clearer, more predictable, and integrable codebase in projects that adhere to DDD principles.

Independently Deploy

Let’s consider a situation, one developer working on a new feature and another developer fixing bugs but both of them hitting the same target. When deployment time, there will be a major problem. The bug will not fix succesfully due to new feature from going into the production.

When we are using microservices, this kind of problems is reduced to death. If we think about the same scenario, these two developer working on a different microservices and even the bug will not fix other service will be perfect and go into prod.

When we split into the microservices of course the complexity of maintaning the operation of multiple machine instances generates more complexity. However, in the world of cloud computing this is not problem than monolith.

Upgrade

Indepent upgrade is a must-have feature for every microservices. For me, If microservice cannot upgrade independently, it is not a microservice!! There is rules must be followed to upgrade as independently as possible:

1. Never share libraries between microservices: In the microservice design, we have to have low coupling and independently deploy. This bring us to this result: Each microservice has a stack totally independent of any other microservice.
2. Strong limitation of microservice domains: When we implementing the microservice desing, It is very essential to determine the donian is really is compatible with microservice architecture.
   The loose coupling is each microservice don’t raise any major conflict when upgrading or changing something in the business level.
3. Establish a client-server rrelationship between microservices: This means each microservice is a different application. If a microservice depends to another microservice’s business, there is an conflict we have to resolve.
   Microservices are free to communicate between themselves to request information as much as they want but never solve business issues.
4. Deploy in seperate containers: By deploying microservices in seperate containers, we ensures that a fault in one microservice is totally individually. In the case of microservices in a single mmicroservices, there will be a error when cyclomatic microservices burst occurs.

Scale

Scalability is common approach for microservices. The scale cube you can see below 👇 whis is discussed in ‘The Art of Scalability’ from Martin L. Abbott and Michael T. Fisher. The comcepts of scale cube fully applicable to microservices and web applications. To better understanding let’s look at What do these axes mean?

Scale Cube

The x-axis: On the x-axis starrategy is horizontal scalability with the same application server replicated n time in full and in a balanced order of 1/n.
The problem with this strategy is when our resources increases such as db and caches, we need more memory and database for connection or etc.

The x-axis diagram

The y-axis: In the x-axis we split one app to three app for solve the problem that resource management. With the y -axis strategy, we are going to split request. As you can see below diagram, the balancer needed for identify where to go request.

The y-axis diagram

Only x-axis or y-axis not scalable by itself. The join between x-axis and y-axis strategy allows us to specific scalability. In the following diagram, order is the most scaled microservice. This type of scalability allows us to reduce shared resources and disadvantages.

x-axis and y-axis joined

The z-axis: The z-axis is very similar to x-axis by scalability structure. In the z-axis strategy each server responds to a specific subset of data. Wiith this strategy, the search providing not only scalability reagrding the application, but also the data you use.

The z-axis

Communication

In the monolithic apps communication provide with methods, functions, parameters and etc. In the microservice architectures, latency and data translation is the key of communication. There are two ways to commmunicate microservice each other: Synchronous and asynchronous

1. Synchronous: Http, TCP, RPC, SOAP …
2. Asynchronous: RabbitMQ, ActiveMQ, ZeroMQ, Kafka ….

Endpoints

In microservices, the separation of endpoints in accordance with standards is of great importance. These standards enhance both the development process and the sustainability of the application. Here are some key points:

1. Restful API Design: Designing endpoints in accordance with RESTful standards offers many advantages. REST is a design principle where resources are represented by unique URIs, and interactions with these resources are carried out using HTTP methods. This makes the names and structures of endpoints clear and understandable.
2. API Versioning: APIs are frequently updated. Therefore, managing the versions of endpoints is necessary. Using version numbers in the URIs of endpoints or another mechanism to maintain compatibility with older versions is important.
3. Documentation: Creating comprehensive API documentation that includes information on how to use endpoints and the accepted parameters is essential for developers.
4. Security Standards: Security of endpoints should be addressed in accordance with standards. Security measures such as authorization and authentication mechanisms should be implemented.
5. Exceptions and Error Handling: Endpoints should be designed to handle errors and exceptions appropriately. Error codes, error messages, and appropriate HTTP status codes should be used.
6. Naming Conventions: Naming conventions for endpoints and data fields should be established. This helps different services and developers communicate more easily.
7. Monitoring and Logging: Monitoring the performance of endpoints and logging errors are important for detecting the health and issues of the application.
8. Appropriate Data Formats: Endpoints should support common data formats like JSON or XML. This facilitates data exchange between different platforms.
9. Rate Limiting: Rate limiting mechanisms should be used to restrict incoming requests to the API. This prevents malicious usage and preserves service quality.

Separating endpoints in accordance with standards is crucial for managing the complexity of microservices architecture and facilitating communication between services. These standards ensure the long-term success and sustainability of the application.

Domains

There are 2 types of microservices domain. Let’s look at what that’s domains

Anemic Domain Model: This approach signifies a design model where the classes representing the data model of a microservice contain only data and the business logic is managed elsewhere. In other words, classes merely store and provide access to data, but the business logic code is located in another part of the system. This makes the microservice lightweight and flexible but can complicate the tracking of connections between business logic and the data model and may increase code complexity.

Fat Domain Model: This approach represents a design model where a microservice’s data model and business logic are integrated, meaning that the classes responsible for the data model not only store data but also encapsulate the associated business logic. This signifies that the business logic is directly integrated into the data model. This approach ensures consistency between business logic and the data model but can increase the complexity of microservices and make maintenance more challenging.

The choice between these models should be based on project requirements, the complexity of microservices, and ease of maintenance. Anemic Domain Model might be suitable for simpler microservices, while Fat Domain Model could be a preferred approach for microservices with more complex business requirements.

Summary

In this article, I tried to show you the basics of the microservice development and how you can scale it.

Thank you for reading this article. You may agree with the viewpoints I’ve shared, or you may have a different perspective, but I eagerly welcome being part of the discussion. Critiques are vital elements that contribute to thinking differently and personal growth.

If you wish to delve deeper into the topics covered in this article or gain a different perspective, please feel free to share your thoughts in the comments section. This opens the door for a broader discussion and mutual learning.

Additionally, consider following my Medium profile to stay updated on future articles and updates. Your feedback and critiques help me improve my writings and serve as a great source of motivation along this journey with you.

Nonetheless, I am grateful for your time and for reading my piece. I look forward to more conversations and truly enjoy the sense of community this platform brings. Happy reading, and until next time!