Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices are a tax your startup probably can't afford

nexo.sh

Post reply on HN
Print view View original

251–260 of 272 posts

Re: Microservices are a tax your startup probably can't afford

#251

Post by tauoverpi »

mrgriffin wrote: post #247
tauoverpi wrote: post #221

Earlier quoted context omitted.

The type system doesn't replace unit/snapshot/property/simulation tests as it's only job is specification. The type system is meant to be used in addition to testing to reduce the set of possible inputs to a smaller domain such that it's easier to reason about what is possible and what isn't. The same would be true even if you go as far as formal verification of programs, you always need to test even when you have po…

> `foo :: Semigroup a, Traversable t => t a -> a` I already know that whatever is passed to this function can be traversed and have it's sum computed. It's impossible to pass something which doesn't satisfy both of those constraints as this is a specification given at the type level which is checked at compile-time. To add to your point, I don't think foo can even be implemented (more accurately: is not total) becaus…

Yep, I missed it as I don't often work in haskell anymore but with the correction the rest of the above still stands (haskell syntax is still the most efficient I'm aware of for talking about this). Also, it being unimplementable is also a nice property of having such a type system as you can prove that your specification is impossible to implement (more applicable in Lean, ATS2, Idris, Agda) or make invalid states impossible to even write (consider state transition rules at the type level).

Re: Microservices are a tax your startup probably can't afford

#252

Post by DanielHB »

antonvs wrote: post #218
roguecoder wrote: post #180

Earlier quoted context omitted.

Sure! Functional programming precludes encapsulation, so it doesn't scale indefinitely the way fractal paradigms can. Eventually, the complexity becomes overwhelming. One effective solution to that is introducing microservices: programmers can still write entirely functional code, but have encapsulation in the form of services. They have to be micro, though, because conventionally-sized services are still big enough…

You’re suffering from a misunderstanding there. Functional programming is all about encapsulation, starting at the individual function boundary (closures can encapsulate state) and then at every layer above that. Functional languages have some of the most rigorous module systems available. In fact Java adopted such a system recently, showing the weaknesses in its previous support for encapsulation via classes and pac…

I think he means stateless, at some point a system needs to have some internal state to keep things running and that state can be really hard to manage when it is mixed with all other functions in the system that also have state.

Even if that state is kept outside the service itself (like a database or event queue) it can still be really hard to reason about when said state-stores are shared across a huge codebase. Changes to a part of the state can have negative effects in completely unrelated functionality.

And of course, there is nothing blocking a monolith from isolating/modularizing their state-stores, but it tends to not happen unless the architecture forces it to happen or through strong tech leadership.

Re: Microservices are a tax your startup probably can't afford

#253

Post by steveBK123 »

jamesfinlayson wrote: post #234
steveBK123 wrote: post #41

Earlier quoted context omitted.

Every org I've tried to see push microservices did exactly the wrong version. Rather than 1 micro service per team, which many devs.. it was some team that owns 20 services, generally way more services than developers. It's probably just how non-lean Mag7 were in peak vs how lean most other orgs that try to ape them are.

Yep, I remember working at a place where one team churned out a large majority of the microservices and the other three teams just kept on doing their thing. The microservice team were especially terrible because the did all the initial work and basked in the "glory", but when it came to maintaining the services, they wanted nothing to do with it.

At some point it just doesn't scale for the team that owns all the micro services. It's poor organizational decision making to have this setup.

Sure a monolith that does 1000 things might not be ideal, but 100 repos for 100 micro services owned by a team of 5-10 devs is unmanageable on the other end of the spectrum. Oh and everyone forgets the orchestration layer.

Re: Microservices are a tax your startup probably can't afford

#254

Post by antonvs »

DanielHB wrote: post #252
antonvs wrote: post #218

Earlier quoted context omitted.

You’re suffering from a misunderstanding there. Functional programming is all about encapsulation, starting at the individual function boundary (closures can encapsulate state) and then at every layer above that. Functional languages have some of the most rigorous module systems available. In fact Java adopted such a system recently, showing the weaknesses in its previous support for encapsulation via classes and pac…

I think he means stateless, at some point a system needs to have some internal state to keep things running and that state can be really hard to manage when it is mixed with all other functions in the system that also have state. Even if that state is kept outside the service itself (like a database or event queue) it can still be really hard to reason about when said state-stores are shared across a huge codebase. C…

Functional programming, which is what was mentioned, devotes a great deal of attention to managing state. That’s a major part of its point.

If we try to read the commenter’s mind, at best they may have been talking about a hypothetical goal that no-one actually advocates.

Re: Microservices are a tax your startup probably can't afford

#255

Post by cedws »

Wish I could upvote this 100 times. At work we started off with the multi repo, multi service and we have burned countless hours managing dependencies, maintaining pipelines, and hacking together things to make local development work. Now are we trying to consolidate back to a monorepo.

Re: Microservices are a tax your startup probably can't afford

#256

Post by tauoverpi »

frollogaston wrote: post #81
BoardsOfCanada wrote: post #63

Earlier quoted context omitted.

Because the network call turns the rule into a law.

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.

I forgot to add that "like I don't need to keep asserting that a for-loop counter is an int." is exactly what is happening with a dynamically typed language that is exactly what the runtime ends up doing unless it has a built-in range type to avoid that overhead and the loop variable cannot change while looping. With a static type checker that can be eliminated upfront as the compiler knows that it's an int and not suddenly a string as it's impossible to change the variable's type once it's defined thus all of the overhead of RTTI can be erased.

Javascript has to check on each iteration that the item is an int and for arrays that the length of those arrays hasn't changed underneath along with a bunch of other things as the language doesn't guarantee that it can't change. Even the JIT compiler in use has to check "is this path still that I expect" as at any point the type of the variable used in the loop can change to something else which invalidates the specialization the JIT compiler emitted for the case of it being an int. When you don't use languages with static types you push all of this work on runtime which makes the program slower for every check it needs to do while offering none of the advantages you have with static types.

Thus with a for loop in say C you don't assert that it is an int each time you statically constrain it to be an int as the loop condition can well be based on something else even if int is the more common to use. For example in zig `for` only takes slices and integer ranges with any other type being a compile-error:

    var example: [1
This is not more work than what you'd do in a dynamically typed language.

Re: Microservices are a tax your startup probably can't afford

#257

Post by jeffwask »

mindcrash wrote: post #9

I know about a org with ~2-3 devs who decided microservices would be cool. I warned not to go that way because they would surely face delivery and other issues which they wouldn't have when building the solution based on a architecture archetype which could be a better fit for the team and solution, which I evidently decided should be a modular monolith. (the codebase at that point was already a monolith, in fact, bu…

I had a similar experience setting up the Infra for an 8-12 microservice application. The project had been dragging and no one really understood what they were doing. When I started asking scale questions, the answer came back that this was an internal admin UI for 9-5 business that would have 5-10 users.

WHY? Just why?

Re: Microservices are a tax your startup probably can't afford

#258

Post by quesera »

MrJohz wrote: post #242
quesera wrote: post #216

Earlier quoted context omitted.

This seems a bit much. In the DVCS era, we have inexpensive branching. Do as thou wilt on your topic or epic branches. Rebase them against main/master before merging upwards. Fix what must be fixed first. Main/master branch should never fail CI. If it does, there is something seriously wrong with your branch lifecycle and/or deployment process.

Sure, but "never fails CI" is a different assertion from "has no bugs", or even "deploys correctly in production".

If you test defensively[0], CI will catch the vast majority of functional bugs. Anything that is missed suggests at least two bugs: one in tests, and one in business logic.[0]

A reliable deployment pipeline is outside of CI, but can be kept straightforward and minimal to constrain the scope of failures.

Bugs happen, and systems complexify. It is possible to manage both of those risks down to near-zero by the time code reaches production release candidate stage.

In some industries, this is more important than others, though -- obviously the goal is to match quality to business needs.

But I agree with our thread predecessor: I haven't seen a broken build make it anywhere near production in many years, and it's not because of the snarky dismissal that provoked my original response.

[0] In some situations, proper tests are not possible, and in others they are not practical. And I acknowledge that I'm omitting things like visual design/layout bugs, which is probably not reasonable.

Re: Microservices are a tax your startup probably can't afford

#259

Post by stephen »

asim wrote: post #2

> 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…

> Microservices are a design pattern for organisations as opposed > to technology ... breakout into multiple teams

I agree, but just saying "multiple teams" has led many eng directors to think "I have two squads now --> omg they cannot both be in the same monolith".

When both squads are 5 people each.

And the squads re-org (or "right size") every 9 months to re-prioritize on the latest features.

Five years go by, 7 team/re-org changes, all of which made sense, but thank god we didn't microservice on the 2nd/3rd/4th/5th/6th team boundaries. :grimmacing:

We should stay "stable, long-lived teams" -- like you need to have a team that exists with the same ownership and mandate for ~18 months to prove its a stable entity worth forming your architecture around.

Re: Microservices are a tax your startup probably can't afford

#260

Post by danielscrubs »

ang_cire wrote: post #191
danielscrubs wrote: post #161

Earlier quoted context omitted.

Bad software dev. degrees that focus on fancy architecture that brings nothing to the table except overhead.

I don't remember one solitary lecture on CI/CD, microservices, or even just deployment in general, in Uni. The closest that our comp. sci. classes ever came to touching on anything but the code itself was making us use SVN.

The difference between a software dev degree and a comp. sci degree.
Post reply on HN