Software engineering is about creating services and infrastructure to serve the needs of a group of people. We create services and we solve business problems through software engineering. As software engineers designing systems and architecture of software are the main part of our job. It is not just about coding but how we will put a system together so that we can maintain and scale it further. Now imagine we want to break the system into smaller services. So a single monolith service breaks down into small services We call it a microservice.

Since many mainstream software companies use this architecture I decided to create a series of posts about microservices and mainly I refer to the book Building Microservices by Sam Newman. I follow the book mainly because it gives a nice round map. And also we add some more information to it.

Let's begin by understanding the fundamentals of microservice.

What is mircoservice?

A microservice is a small, independently deployable, and scalable software component that encapsulates a specific business capability. Microservice is molded around the business domain. It operates as a modular unit within a larger system, communicating with other microservices through well-defined interfaces (say APIs) over a network. Microservices are designed to be flexible, allowing developers to work on, deploy, and update them independently, contributing to a software system's overall agility and scalability. Being independent is a key.

Example:

Imagine a Marketing SaaS (Software as a Service) platform that traditionally handles various marketing domains within a monolithic structure. In a microservices architecture, these functions can be separated into individual microservices, each responsible for a specific aspect of marketing(or business domains):

1. Campaign Management Microservice: Manages the creation, scheduling, and monitoring of marketing campaigns. Exposes APIs for creating new campaigns and retrieving campaign analytics.
2. Email Marketing Microservice: Handles the email marketing component of the platform. Manages subscriber lists, sends out emails, and tracks email engagement metrics.
3. Analytics Microservice: Collects and analyzes data related to user interactions with marketing content. Provides insights into the effectiveness of campaigns. User Authentication Microservice:

Each microservice is treated as a black box. We can say it is a service-oriented architecture. Each service exposes APIs and other services that use the functionality of the service.

One important aspect is that internal implementation from the technology to where data is stored is hidden from the outside world. That means each microservice (in most cases) will have its own database.

another important aspect is that microservice uses information hiding. It means It exposes as little as possible via the external interface and keeps the much of information inside. This gives each service the power of controlling on what can be changed and what can not be modified.

Is Microservice a service-oriented architecture?

Microservice is a specific approach for SOA in the same way that Extreme Programming (XP) or Scrum is a specific approach for Agile software development.

Key concepts of microservice

1. Independent deployability
   Make changes to one microservice and deploy it into production without having to deploy anything else. It is the key point.
   So we should make microservices loosely coupled. That means Minimal dependencies, independent operation, and ease of modification between system components. That is why sharing the database is not a good idea at all.

2. Shaped around a business domain
   Techniques like domain-driven design help structure code to mirror the real-world domain. In microservice architectures, the same idea is applied to define service boundaries around business domains.
   This makes it easier to roll out new functionality and allows flexible recombination of microservices for delivering new features.
   
   Implementing features requiring changes in multiple microservices is costly.
   Our goal should be minimizing cross-service changes to streamline development efforts.
   Layered architectures, such as three-tiered structures, often have each layer representing a service boundary.
   Changes in functionality often span multiple layers, complicating the development process. For example, a change in backend needs a change in fronend too.
   Efficiency in making changes is slowed, especially in highly layered architectures.
   Microservices prioritize arranging services as end-to-end slices of business functionality.
   Aims to make changes to business functionality more efficient by avoiding technical functionality layers.
   Emphasis on high cohesion of business functionality over high cohesion of technical functionality in a microservices architecture.

3. Owning their own state
   The challenge often faced in adopting microservices lies in the notion that shared databases should be avoided. Instead of one microservice accessing the data of another through a shared database, microservices should directly request the needed information. This approach allows microservices to independently determine what is shared and what remains hidden. To achieve true independent deployability, minimizing backward-incompatible changes is crucial. Analogous to encapsulation in object-oriented programming, hiding internal state in microservices contributes to information hiding. This encapsulation of data, including user interface, business logic, and underlying databases, promotes high cohesion of business functionality and reduces coupling, aligning to make changes to business-related functionality more efficient.

4. Size
   Chris Richardson, the author of Microservice Patterns (Manning Publications), once said—that the goal of microservices is to have “as small an interface as possible.” That aligns with the concept of information hiding again, but it does represent an attempt to find meaning in the term “microservices” that wasn’t there initially. So we need to keep the size as small and as meaningful as possible and expose the data necessary to keep the cohesion of the microservices. After all, size is not that important.
   The two most important things here are:

   • How many microservices can we handle? If you want to move to microservice and keep the complexity arising, manageable, migrate to microservice incrementally.
   • How do you define microservice boundaries to get the most out of them, without everything becoming a coupled mess?

Alignment of Architecture and business

MusicCorp (a real company with an imaginary name), an online CD-selling ecommerce company, currently operates with a traditional three-tiered architecture, consisting of a web-based UI, a monolithic backend for business logic, and a traditional database. The architecture aligns with how teams were traditionally organized based on core competencies, resulting in high cohesion of related technology but low cohesion of business functionality. However, as expectations around software development have changed, the company aims to transition into a more agile and efficient model.

The three-tiered architecture is optimized around familiarity and how teams were historically organized. Conway's law, which states that system designs mirror communication structures within organizations, is evident in this architecture. To adapt to changing forces and align with current practices, the company explores an alternative microservices architecture organized along vertical business lines. This approach involves dedicated teams responsible for end-to-end changes in specific business functionalities, enhancing the cohesion of business functionality rather than technology. The introduction of stream-aligned teams, as described in the book Team Topologies, becomes a key concept, emphasizing teams' empowerment to deliver customer value independently. This shift towards microservices and stream-aligned teams aims to facilitate quicker, safer, and more aligned development and organizational structures.

In the next post, we will talk more about monolith and microservice fundamentals.

Stay Tuned!

Photo by Omar Flores on Unsplash