Microservices

Usually, when we make applications (especially as beginners), we tend to make one application to do everything. This application is said to follow a monolith architecture.

What is a Monolith architecture?

• The standard way of writing code here all the components are a part of a single unit/ codebase.
• The app must be written with one tech stack.
• Teams need to be careful to not affect each other's work.
• Every time you update a part of the application, you need to redeploy the entire application.

Challenges with the monolith architecture

• Applications become too large and complex.
• Parts are more tangled into each other.
• You can't scale particular components which leads to higher infrastructure costs.
• Difficulties arise if different services require different dependency versions.
• Longer release process.
• For every change made, the entire application needs to be tested.
• A single bug in a relatively insignificant component can bring down the entire application.

Since there are a lot of problems with the standard monolith structure, we resolve them by using microservices.

What are microservices?

• We break down the application into several small/micro applications.
• What does their architecture look like?
  • The splits are based on each component's business functionalities.
  • It follows the idea of 'Separation of concerns'- 1 service for 1 specific job.
  • They must be self-contained and independent of each other. Each service must be developed, deployed and scaled separately even though they are a part of the same application. (Known as loose coupling)

Communications between microservices

• Usually done using API Calls.
  • Each service has its own API and they can talk to each other by sending HTTP requests
  • It is a synchronous communication
• It can also be done asynchronously using a message broker
  • Common patterns- Pub/Sub and point-to-point messaging
• A third way to communicate is by using a service mesh.
  • There's a helper service that takes over the complete communication logic.
  • You don't have to code the communication logic into the microservice, it is delegated to the service mesh.

Downsides to using microservices

• Added complexity because the microservices application is a distributed system.
  • Configuring the communications between services for scenarios where one of the services is down.
  • More difficult to monitor with multiple instances of each service distributed across servers. Tools for overcoming these challenges have been built over the years. One of them is Kubernetes.

CI/CD pipelines for microservices

• Companies like Meta, Google and Netflix deploy hundreds of microservices every day. The complexity of the pipeline increases with the number of such services deployed.

Monorepo vs Polyrepo

• Monorepo means using 1 git repository that contains many projects.
  • Each service has its own folder/ directory.
  • Makes code management and development easier.
  • Clone and work only with 1 repo.
  • Changes can be tracked together, tested together and released together.
  • Share code and configurations like docker-compose and manifest
• Some of the challenges are:
  • Tight coupling of projects.
  • Easier to break the 'loosely coupled' criterion.
  • Cloning, fetching and pushing slowdown due to increased size.
  • Makes pipeline code more complex and challenging to write.
  • If the main branch is broken, the entire repo is gone.
• Used by companies like Google.
• Polyrepo means that each service has its repository.
  • Code is completely isolated
  • Clone and work on them separately.
  • In services like GitLab, you can have projects to configure connected projects (Groups).
    • This helps to keep an overview.
    • Create shared secrets, CI/CD variables, runners, etc.
  • The CI/CD is more straightforward.
• Some downsides are:
  • Cross-cutting changes is more difficult.
  • Changes spread across projects must be submitted as separate Merge requests instead of a single, atomic MR.
  • Switching between projects is tedious
  • Searching, testing and debugging is more difficult.
  • Sharing resources is relatively more difficult.

I made these notes after watching Techworld with Nana’s video. Let me know what you think of it and if you’ve loved it, drop a like :)