A microservice is just a web service that is small, well-defined scope and is loosely coupled from any other web service. Usually you don't build just one microservice, but rather your organization adopts a microservices architecture that consists of a collection of microservices, each one self-contained and implementing a single business capability.

Loosely coupled?

A loosely coupled architecture refers to a architectural approach where the various components of an application are built to function independently of each other. This contrasts with tightly coupled architectures, where components are heavily interdependent and changes in one component can impact others.

Imagine you’re organizing a big race for your local running club. Each runner represents a component of your application. In a loosely coupled relay race, each runner is an expert in their own segment of the race track and can perform independently of the others. If one runner has a problem, it doesn’t necessarily derail the entire race; another runner can step in to cover that segment without much disruption.

In contrast, a tightly coupled relay race would mean all runners need to be in perfect sync and highly dependent on each other’s performance. If one runner falters, it creates a domino effect, slowing down or stopping the entire race.

Anyway.. microservices!

Each service has a seperate codebase, which can be managed by a small development team.

Microservices don't even need to share the same technology stack, libraries or frameworks which allows each team to choose the right tool for the job.

This means that each team can build, test and deploy a service. That enables for continuous innovation and a faster release cadence.

Teams can now focus on one service, and with a smaller scope of each service, the code base will be more readable, easier for onboarding of new software engineers. This route allows each microservice to be deployed indepedentently of every other microservice in the organization.

A team can update an existing service, without rebuilding and redeploying the entire application. Rollbacks are also easier to be done if a release would go wrong.

The deployment strategy also means that each microservice can be scaled independently. A benefit of this efficiency is that each microservice is responsible for persisting its own data or external state and not rely on some common repository layer.

Some argue that each micrsoervice should have its own seperate database. The idea here is to make each microservice completely autonomous with no cross-dependencies from a business domain perspective. This kind of freedom provides a layer of fault isolation. If a service goes down, it won't necessarirly take down the whole application.

Each microservice is an island unto itself 🏝️

Then what happens when you need to work with multiple microservices in a single application? Microservices can communicate with each other by using well-defined APIs. The internal implementation details of each service are encapsulated behind their interface. However, typically you'd want to reduce those interdependencies and try to introduce an orchestration or management layer in the higher level consuming application that coordinates calls to various lower level microservices and combines results. A microservices architecture solves some problems and is more appropriate when you have a large application that requires a high release velocity, you have complex applications that are highly scalable, you have applications with rich domains or many sub-domains, you have an organization that consists of small development teams. Microservides can benefit from the management and hosting capabilities of several different cloud providers.

So microservices is a way to simplify an application architecture by focusing on creating smaller, more manageable autonomous and independently deployed web services that address a single business domain or capability.

When should we use microservices?

There could be several factors where you might want to consider microservices instead of a monolithic.

When your application needs to scale different components independently. For example, an e-commerce application where the product catalog and user management might require different scaling strategies. For example if you need to have several different kinds of billing services in different markets, Denmark has Stripe, Sweden has Swish, Norway has Vipps. Designing your application with microservices would allow you to develop different solutions for different iterative cases. This makes it easier for Software Engineers to not code solutions that are "set in stone" 😌

For complexity - When you're dealing with a complex application with many different, interrelated domains. Breaking it into microservices allows each team to focus on a specific domain. One team might develop an application in one programming language optimized for their use case. That is no problem in a microservice architecture.

Continious delivery and deployment - if your organization has a nice agile framework then we want to release small increments frequently. This is easier when having microservices.

When should we not use microservices?

Small applications if your application is small, the overhead might not outweigh the outcome of having to manage microservices.

Tightly Coupled Components if your application components are highly interdependent and can't function independently, microservices might not be for you

How about On-premises (OnPrem) ?

Using microservices in an on-premises (onprem) environment can give many of the same benefits as in a cloud environment, but there are some quirks here.

If your organization sit on good ol smelly big monolith, it can be a great way to slowly but gradually refactor it by writing microservices.

What to consider when switching architecture in an OnPrem environment..

Managing microservices onprem requires robust infrastructure capabilities. Tools like Kubernetes can help manage containerized microservices, but they need to be set up and maintained on your hardware.

Onprem environments need carefully planned network design to ensure that microservices can communicate efficiently and securely. This involves setting up appropriate networking policies, firewalls, and possibly a service mesh. Having latency issues can heavily affect the critical data storage in between any potential outages. Azure however states that their datacenters have backups, therefore securing high availability.

Monitoring and logging become crucial with microservices. Solutions like Prometheus for monitoring, Grafana for visualization, Datadog or ELK Stack (Elasticsearch, Logstash, Kibana) for logging are commonly used to track the performance and health of microservices.

However, there are many benefits with using microservices. One service can fail without affecting the others, improving the overall resilience of the system. Scale individual services according to their specific needs, optimizing resource usage. This can be done both horizontally and vertically. However, of course: mix monitoring to prohibit data concistency and network latency. Detecting data inconsistency across microservices and databases. Datadog FTW.