What is a Microservice architecture?

A microservices architecture is a service-oriented architecture used to build large applications. The complete picture is a combination of small "services", in which all the modules are independent of each other, but deliver the expected aggregate functionality to the user together. This is done via data sharing amongst the services.

Every team and every product has their own interpretation of how its microservices should look and work, depending on their needs, but mainly they should have:

• A separate project, with separate logic for each service
• Each separate project can sometimes be a separate product itself
• Ideally a separate database for each service
• Separate deployment process for each service
• Designed for failure - the key is if one service fails, others keep working
• A protocol for communication between the services
• A structure and strategy for them achieving the whole functionality of the system
• An API gateway, which will redirect the traffic to the necessary API, without having the end user notice the product is based on many separate services

• A service bus implementation, which will help microservices communicate

  

What are the differences between Microservices and Monolith architectures?

A monolith architecture is generally tightly coupled whereas a microservices architecture is loosely coupled. The focus on microservices architecture is on products rather than projects.

In a monolithic architecture, if a single functionality or any component goes down or breaks, then the entire application could go down. But in a microservice architecture, all components are independent of each other. So if any functionality breaks down then, it is isolated to the service.

In a microservice architecture, any changes implemented in a single data model does not impact that of other services. But in a monolithic architecture, any modifications in the data model could influence the single datastore for the app.

What is Domain-Driven Design (DDD)?

Domain-Driven Design (DDD) is a software development approach that focuses on creating a software system that closely reflects the real-world domain it represents. This is done by collaborating closely with domain experts to understand the concepts and rules of the domain and then translating that understanding into a software model.

Key characteristics of DDD include:

• Focus on domain logic: DDD emphasizes the importance of understanding and modeling the core logic of the domain. This logic encapsulates the business rules and processes that drive the domain.

• Model-driven design: The domain model serves as the foundation of the software design. Complex designs are based on the intricacies of the domain model, ensuring that the software accurately represents the real-world domain.

• Collaboration with domain experts: Domain experts play a crucial role in DDD, providing insights and feedback throughout the development process. Their expertise helps ensure that the software captures the essence of the domain and meets the needs of its users.

• Ubiquitous language: DDD promotes the use of a common language that is understood by both developers and domain experts. This shared vocabulary facilitates communication and reduces misunderstandings.

• Bounded contexts: DDD divides the domain into smaller, self-contained units called bounded contexts. Each bounded context has its own model, ownership, and responsibility, promoting modularity and manageability.

How Is DDD Used for Microservices?

Imagine a software company which specializes in developing supply chain management solutions. As the business grew, their monolithic software system became increasingly complex and difficult to manage. To address these challenges, they decided to adopt a microservices architecture.

The team started by applying DDD principles to identify and define bounded contexts within their domain. They identified four key areas:

1. Order Management: Handling order placement, tracking, and fulfillment.

2. Inventory Management: Tracking product stock levels, replenishment, and allocation.

3. Warehouse Management: Optimizing warehouse operations, including picking, packing, and shipping.

4. Transportation Management: Managing deliveries, routes, and carrier integrations.

Each bounded context represented a cohesive unit of domain logic with its own model, ownership, and responsibility. These bounded contexts were then mapped to separate microservices.

By adopting DDD and microservices, they achieved several benefits:

1. Reduced Complexity: The monolithic system was broken down into smaller, more manageable microservices, reducing overall complexity.

2. Improved Maintainability: Each microservice had a clear purpose and responsibility, making it easier to understand, maintain, and update.

3. Increased Agility: Teams could work independently on their respective microservices, enabling faster development and deployment cycles.

4. Enhanced Scalability: Each microservice could be scaled independently to meet specific domain requirements, improving resource utilization.

5. Clearer Collaboration: DDD's focus on ubiquitous language fostered better communication between domain experts and developers.

What is Containerization?

Containerisation is a type of virtualization strategy that emerged as an alternative to traditional hypervisor-based virtualization.

In containerization, the operating system is shared by the different containers rather than cloned for each virtual machine. For example Docker provides a container virtualization platform that serves as a good alternative to hypervisor-based arrangements.

Why are Containers used in Microservices?

Containers are useful technologies for allocating and sharing resources. It is considered the most effective and easiest method for managing microservice-based applications to develop and deploy them individually. Using Docker, you may also encapsulate a microservice along with its dependencies in a container image, which can then be used to roll on-demand instances of the microservice without any additional work.

Docker generally provides a container environment, in which any application can be hosted. This is accomplished by tightly packaging both the application and the dependencies required to support it. These packaged products are referred to as Containers, and since Docker is used to doing that, they are called Docker containers. Docker, in essence, allows you to containerize your microservices and manage these microservices more easily.

What types of tests are usually made for microservices?

• Bottom-level tests: The bottom-level tests are those that deal with technology, such as unit tests and performance tests. This is a completely automated process.
• Middle-level tests: In the middle, we have exploratory tests such as stress tests and usability tests (integration tests).
• Top-level tests: In the top-level testing, we have a limited number of acceptance tests (system tests). The acceptance tests help stakeholders understand and verify the software features.

In which technologies are Microservices usually built?

Microservices are usually used for web applications, and the most common back-end technologies for building them are .NET (C#), and Spring Boot (Java).

Why we need DevOps in microservice?

Because the requirements that a microservice needs are the key feature of DevOps technology and the automation, for example frequent and automated releasing of software, and standardization can easily be done using DevOps.

What is Continuous Integration (CI)?

Continuous Integration (CI) is the process of making the build and testing for code automatic whenever a team element modifies version control. As a result, it motivates the developers to share code as well as unit tests. The same is done after combining the changes in a shared version control repository and after each small task complete.

What are the challenges that developers have to face for implementing Microservices?

Functional Challenges:

• Require heavy infrastructure setup
• Need investment
• Require excessive planning to handle or manage operations overhead

Technical Challenges:

• Microservices must communicate with each other
• It is a heavily involved model because it is a distributed system
• To support heterogeneously distributed microservices, you need skilled professionals
• It is difficult to automate because of the number of smaller components. For that reason, each component must be built, deployed, and monitored separately
• It is difficult to manage configurations across different environments for all components
• Challenges associated with deployment, debugging, and testing

One Pager Cheat Sheet

• Microservice architecture is a service-oriented approach that consists of independent modules with separate logic, databases, deployment processes, communication protocols and an API gateway, designed to achieve the whole package of an application's functionality.
• The microservice architecture allows for flexibility and scalability by connecting individual databases through an API Gateway or Service Bus, creating more independence between services.
• Domain-Driven Design (DDD) is a design pattern that focuses on the core domain logic and creates complex designs based on the domain's model, allowing for collaboration with domain experts to improve and fix any issues.
• Containerization provides more efficiency and resource-savings than hypervisor-based virtualization, by allowing the Operating System to be shared across different containers.
• Microservices usually require unit tests, performance tests, stress tests, usability tests, integration tests and system tests, and are typically built using .NET (C#) and Spring Boot (Java), while DevOps enables automated releasing and standardization. Continuous Integration (CI) is a process that facilitates automated build and testing of code whenever it is modified.
• Continuous Integration (CI) automates the process of combining changes and building and testing code, encouraging developers to share code and unit tests, and standardizing the process of releasing software frequently and automatically.
• Developers face functional challenges such as heavy infrastructure setup, investment and excessive planning, and technical challenges, including communication between microservices, skill level requirements, difficulty in automation and managing configurations.
• Microservices are decentralized architectures where separate services communicate with each other via two-way communication to provide autonomy, scalability and flexibility.