131–140 of 272 posts
Earlier quoted context omitted.
If they're doing two very different things, why?
At a larger organization this could be, but there is nothing elixir could possibly be doing for the startup that go would not do. Remember the whole topic here is avoiding this tax
The catch is to keep them all in mind and use them in moderation.
Like everything else in life.
Earlier quoted context omitted.
Microservices are GREAT when 1 team owns each service. I haven't seen a good use case when you have 1 team supporting multiple microservices.
1 team supporting multiple services is not great, but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either. That's why I don't like the term "microservice", as it suggests each service should be very small. I don't think it's the case. You can have a distributed system of multiple services of a decent size. I know "services of a decent size" isn't as catchy as…
Why can the game industry etc somehow manage this fine, but the only place where it's actually possible to adapt this kind of artificial separation over the network, it's somehow impossible not do it beyond an even lower number of devs than for a large game? Suggests confirmation bias to me.
The main problem with microservices is that it's preemptive, split whatever you want when it makes sense after-the-fact, but to intentionally split everything up before-the-fact is madness.
The biggest wins for microservices aren't really technical, they're organizational. They force you to break a problem down and allow each team to own a piece of it, including end to end delivery. This allows specialization of labor which is a key driver of productivity - including an ability to experiment and innovate. Every change is incremental by default, and well-documented external APIs are the only way to talk…
The DB part can also get technical as performance comes into play. Most startups are probably not encountering this problem, but they could.
It makes Database Per Customer type apps really easy, and that is something alot of SaaS products could benefit from.
Problem is that, come recruiting time, interview gatekeepers are filtering out candidates who don't have the shiny words of the season, see micro services, unit tests, lots of abstractions, etc. It's like a dating app game. Everyone knows is overblown but they are still playing the game. The idea that not every company needs to make the same architectural and technological decisions is a concept way too complex for i…
Are unit tests a shiny fad? Second time I've seen it mentioned in this thread. Is there some other type of testing I should be doing, or have I been doing it all wrong for the last two decades?
Programmers coming up through frameworks or functional programming often don't have those, and so the techniques OO unit testers use don't translate well at all. If the first "unit" you build is a microservice, the first possible "unit" test is the isolation test for that service.
I have watched junior engineers crawl over glass to write tests for something because they didn't know how to write testable code yet, and then the tests they write often make refactoring a-la-Martin-Fowler's-book impossible.
(And that is leaving aside the consultancies that want to be able to advertise "100% test coverage!" but don't actually care if the tests make software harder to maintain in the long run because they aren't going to be there.)
Eventually we'll be able to acknowledge that there are a lot of different skills in our profession, and that writing good code isn't about being "smart": it's about knowing how to write code well. But until then people will keep blaming the tools they don't know how to use.
My current take on microservices is that people pay serious attention to modularity and API design in the context of microservices. They work hard to break down the problem properly and design good interfaces between parts of the system. In monoliths, they generally don't. There's no logical reason why you couldn't pay as much attention to decomposition and API design between the modules of a monolith. You could have…
Not that I would ever want to give up our monolith, but we do experience the problems you point out.
> Microservices only pay off when you have real scaling bottlenecks, large teams, or independently evolving domains. Before that? You’re paying the price without getting the benefit: duplicated infra, fragile local setups, and slow iteration. For example, Segment eventually reversed their microservice split for this exact reason — too much cost, not enough value. Basically this. Microservices are a design pattern for…
I don't see any major epiphany in this. In fact, it reads like a tautology. The very definition of microservice is that it's an independently evolving domain. That's a basic requirement.
Earlier quoted context omitted.
Most “benefits” assumed from separation can be achieved with clear interfaces and modular monoliths, without the cognitive and operational tax microservices impose. > It also adds enough intentional friction that we don't accidentally put logic where it doesn't belong as part of the user authentication process. Preventing misplaced logic is a matter of good code structure, well defined software development processes…
The largest benefit of microservices has always been lifecycle management, and "clear interfaces" in "modular monoliths" does not in fact solve that. If you update the logging library in a monolith, everyone takes that updates even if it breaks half the teams. That's a "large" organization problem. But large is actually, not that big (about 5-10 scrum teams before this is a very large problem). It also means on criti…
What lifecycle are we really talking about? There are massive monoliths - like the Linux kernel or PostgreSQL - with long lifespans, clear modularity, and thousands of contributors, all without microservices. Lifecycle management is achievable with good architecture, not necessarily with service boundaries.
> If you update the logging library in a monolith, everyone takes that updates even if it breaks half the teams.
This is a vague argument. In a microservice architecture, if multiple systems rely on the structure or semantics of logs — or any shared behavior or state - updating one service without coordination can just as easily break integrations. It’s not the architecture that protects you from this, but communication, discipline, and tests.
> It also means on critical systems separating high risk and low risk changes are not possible.
Risk can be isolated within a monolith through careful modular design, feature flags, interface boundaries, and staged rollouts. Microservices don’t eliminate risk - they often just move it across a network boundary, where failures can be harder to trace and debug.
I’m not against microservices. But the examples given in the comment I responded to reflect the wrong reasons (at least based on what I’ve seen in 15+ years across various workplaces) for choosing or avoiding a microservice architecture.
Microservices don’t solve coupling or modularity issues — they just move communication from in-process calls to network calls. If a system is poorly structured as a monolith, it will likely be a mess as microservices too — just a slower, harder-to-debug one.
Microservices make sense from a technical perspective in startups if: - You need to use a different language than your core application. E.g. we build Rails apps but need to use R for a data pipeline and 100% could not build this in ruby. - You have 1 service that has vastly different scaling requirements that the rest of your stack. Then splitting that part off into it's own service can help - You have a portion of…
Splitting off a few services from an application is not the same as using micro services. With microservices you split off basically everything that would be a module in a normal application.
Earlier quoted context omitted.
This is also why app backends don't really need statically typed languages, no matter how big the company is. You have a well-defined API on the front, and you have a well-defined DB schema on the back, that's good enough. The static typing makes even less sense at finer code scopes, like I don't need to keep asserting that a for-loop counter is an int.
"Need"? Probably not. But unlike microservices they don't really have downsides (at least not with modern IDEs and the automatic refactorings they support) and they do offer some benefits. Statically-types languages are a form of automatically-verified documentation, and an opportunity to name semantic properties different modules have in common. Both of those are great, but it is awkward that it is usually treated a…