DEV Community

Cover image for Microservices
Albert Jokelin
Albert Jokelin

Posted on


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 :)

Top comments (0)