microservices

Table of Contents

1. microservices

1.1. How Culture Impacts Technology Choice: A Review of Netflix’s Use of Microservices

https://www.reddit.com/r/programming/comments/oe1x3i/how_culture_impacts_technology_choice_a_review_of/

Microservices are a way to manage teams of developers, not software. Too many developers piled onto the same monolith can result in a “too many cooks” situation.
the added complexity is not worth it unless you have hundreds of developers working on the same project.

Any time the ratio between the number of developers employed and the amount of development effort actually required starts to get higher than can be easily managed otherwise.
Sometimes you need 500 people to do in 1 month what would take 50 people six months, and 5 a year. If you do, then microservices are about the only known way of breaking Brook’s Law.

1.2. Microservices - maybe not - Techblog - Hostmoz

https://www.reddit.com/r/programming/comments/m99gg3/microservices_maybe_not_techblog_hostmoz/
Interesante la discusión en otros subreddits, en ese justo no

1.3. Cargo (Rust) is the only real microservice architecture!

Rust Is a Scalable Language

1.6. Ver “The Problem With Microservices” en YouTube

https://youtu.be/zzMLg3Ys5vI

1.6.1. Small

Small enough to fit in your head. Something you could rewrite in a week or two

1.6.2. Focused on One Task and Doing It Well

Separation of Concerns in the Problem Domain. Accomplishes one task when viewed from the outside

1.6.3. Aligned with a Bounded Context in the Problem Domain

Domain Driven Design → “A Bounded Context is a defined part of software where particular terms, definitions and rules apply in a consistent way”
If you split your monolith with an abritrary division you’re not doing microservices → leads to more coupling than necessary
This is often overlooked
When you cross a boundary, you should translate information crossing it (Ports & Adapters)

1.6.4. Autonomous

The teams can change service implementation without coordinating with others
This is the biggest value of microservices, allows to scale an organization
Building, testing and deploying is completely separated
Service Based Design is not Microservices: services were invented before

These two are coupled via Conway’s law:

  • Distributed Monolith vs (Distributed) Microservices
    Distributed Monoliths can have a service architecture, but are not independently deployable (can be on one repo)
    Microservices are independently deployable and so it’s better to keep them at separated repos

1.6.5. Independelty Deployable

This is a key aspect of being Autonomous
Teams can develop separatedly and decide separatedly when do deploy. Reduces development coupling to the rest of the organization
This is the real value of microservices and the real cost (namely, maintaining that independence!)
Microservices are an organization de-coupling strategy
If you don’t need to de-couple your organization developmentally they’re probably not the right thing to do

1.6.6. Loosely-Coupled

You need to make external & internal representations different (which means building at least 2 different implementations) → time & effort
Treat the interface to a microservice is a public API → you have to be very careful when changing it
When consuming an API, use the minimum data that you can to reduce coupling
For example, this may need supporting multiple versions of interfaces on the same service, or multiple versions of services

1.7. “The human scalability of ‘DevOps’”

“The human scalability of ‘DevOps’” por Matt Klein
https://link.medium.com/4yq4wGg0W8
So what happens when a modern (phase three) Internet startup finds success and enters hyper-growth? A couple of interesting things start happening at the same time:

  1. The rate of personnel growth rapidly increases, causing severe strains on communication and engineering efficiency. I highly recommend reading The Mythical Man-Month (which is still largely relevant almost 50 years after its initial publication) for more information on this topic.
  2. The above almost always results in a move from a monolithic to microservice architecture as a way to decouple development teams and yield greater communication and engineering efficiency.
  3. The move from a monolithic to microservice architecture increases system infrastructure complexity by several orders of magnitude. Networking, observability, deployment, library management, security, and hundreds of other concerns that were not difficult previously are now major problems that need to be solved.
  4. At the same time, hyper-growth means traffic growth and the resultant technical scaling issues, as well as greater repercussions for both complete failure and minor user experience issues.

the reality is that state of the art cloud native technology is still too hard to use if every product engineering team has to individually solve common problems around networking, observability, deployment, provisioning, caching, data storage, etc

  • The fallacy of fungibility
    Finally, we arrive at the idea of “fungibility,” which is the crux of the failure of the pure DevOps model when organizations scale beyond a certain number of engineers. Fungibility is the idea that all engineers are created equal and can do all things
    Fungibility and generalist hiring typically works fine for early startups. However, beyond a certain size, the idea that all engineers are swappable becomes almost absurd for the following reasons:
    1. More complex applications and architectures require more specialist skills to succeed
    2. All engineers do not like doing all things
    3. All engineers are not good at doing all things

1.9. Microservices envy

https://www.thoughtworks.com/radar/techniques/microservice-envy
Microservices has emerged as a leading architectural technique in modern cloud-based systems, but we still think teams should proceed carefully when making this choice. Microservice envy tempts teams to complicate their architecture by having lots of services simply because it’s a fashionable architecture choice. Platforms such as Kubernetes make it much easier to deploy complex sets of microservices, and vendors are pushing their solutions to managing microservices, potentially leading teams further down this path. It’s important to remember that microservices trade development complexity for operational complexity and require a solid foundation of automated testing, continuous delivery and DevOps culture.

1.11. Microservices, granularity and complexity

Why are microservices needed, architecturally?
Workload is not fixed (complicated), but is often driven by unpredictable, unexpected, complex human behavior (more so in B2C than in B2B, or internal developments)
Therefore is far easier to design systems that adapt to that workload than to try to predict it, because it follows a power law, not a gaussian distribution
You can achieve this by breaking things down to the right level of granularity and then amplyfing on success / dampening on failure
Similary, LRU caches are built because it’s easier to cache based on use that trying to predict usage a priori

Author: Julian Lopez Carballal

Created: 2024-10-21 Mon 09:46