Don't start with microservices – monoliths are your friend • Hacker News Board

Re: Don't start with microservices – monoliths are your friend

#271

Post by deniska » Thu, Dec 16, 2021, 4:55 PM UTC

bspammer wrote: post #93

deniska wrote: post #26

Unless you have a strong technical or organizational reason to use microservices, using microservices is just more work to achieve the same results. Organizational reason would be multiple people/teams who don't want or can't talk much to each other, so they develop pieces of a larger system as relatively independent projects, with clear API and responsibility boundaries. Frontend/backend style web development is an…

> no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “d…

> People throw around “distributed monolith” like it’s a dirty phrase but I’ve found it actually a very pleasant environment to work in.

For ones I saw, the answer to the question "how do I run our project on a single laptop?" is "haha, you don't". That makes features which could take hours to implement take weeks. But deployment is 5 minutes instead of… 15? Not too worthy of a trade-off.

Your CSV writer probably has both technical and organizational reasons being an independent unit of development. Or, in other words, something which appeared organically, rather than someone deciding months prior before a project even started that authentication and user profiles should live in two parallel universes.

Re: Don't start with microservices – monoliths are your friend

#272

Post by kgeist » Thu, Dec 16, 2021, 4:56 PM UTC

KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

We've been following this modular monolith approach as well (for 3 years now), bounded contexts and all, but our architectural end goal is still "mostly microservices". Maybe it's specific to PHP and the frameworks we use (what the modulith is written in) but the startup time of the monolith is just unacceptable for our processing rates (for every request the framework has to be reinitialized again, with all the 9000 services via DI and what not). Microservices tend to be much more lightweight (you don't even need DI frameworks), and monolith also encourages synchronous calls (calling a bounded context's API in memory is so simple) which has been detrimental to our performance and stability, because microservices, at least in our architecture, encourage event-based communication which is more scalable, and allows clean retries on failure etc. But again, your mileage may vary, maybe it's specific to our tools.

Re: Don't start with microservices – monoliths are your friend

#273

Post by madsbuch » Thu, Dec 16, 2021, 5:01 PM UTC

hiptobecubic wrote: post #240

madsbuch wrote: post #225

Earlier quoted context omitted.

There are plenty of solutions to authentication. But really, don't implement a user system if it is not needed. There are plenty of other ways to secure on applications, which are way out of scope for this discussion. The main point is, that one should never spend a "a few days to a week" to implement a feature that at best i useless and at worst is detrimental to the service stood up. Implement auth, if it is needed…

I feel like "spaghetti garbage now, we'll fix it later" is a big part of why startups fail to execute well. Yeah you saved $8000 by launching your thing in a completely unmaintainable way, but now it's both harder to maintain and more likely to need it. Literally the first time it breaks you will probably lose that cost advantage just because it takes so long to debug. The point you should have made is that dogmatic…

In that case it would be bad to b cut corners, ey?

Though these were not the cases I talked about.

I talked about implementing features that are not necessary for the product because of dogmatic reasons.

Re: Don't start with microservices – monoliths are your friend

#274

Post by lubesGordi » Thu, Dec 16, 2021, 5:01 PM UTC

The problem with monoliths is that they're written fast and chock full of business logic that isn't reusable anywhere else. With microservices, if done correctly a la hasura, your business logic is abstracted to config, or to the highest level of abstraction your business allows.

Re: Don't start with microservices – monoliths are your friend

#275

Post by p_l » Thu, Dec 16, 2021, 5:02 PM UTC

sdevonoes wrote: post #40

jhoelzel wrote: post #9

There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either. maybe we are getting caught up in sematics because its christmas, but "monorepo/monolith/microservices/etc" is -just- the way you organize your code. Developing a montolith for years but now you have written a 15 line golang ht…

> Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. But the 15 lines of Golang are not just 15 lines of Golang in production. You need: - auth? Who can talk to your service? Perhaps ip whitelisting? - monitoring? How do you know if you service is up and running? If it's down…

Well, it quickly can become a mess because of people having different ideas about what microservice is, and also decrying things as "for microservices only" when for example I just want to offload auth and monitoring to a specialized service.

It's also a common trope when I'm dealing with k8s decriers - yes, you might have one application that you can easily deploy, but suddenly there are 15 other medium-weight applications that solve different important problems and you want them all ;)

P.S. Recently a common thing in my own architectures is separate keycloak deployment that all services either know how to use, or have it handled at separate request router (service mesh or ingress or loadbalancer)

Re: Don't start with microservices – monoliths are your friend

#276

Post by p_l » Thu, Dec 16, 2021, 5:04 PM UTC

koffiezet wrote: post #228

sdevonoes wrote: post #40

Earlier quoted context omitted.

> Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. But the 15 lines of Golang are not just 15 lines of Golang in production. You need: - auth? Who can talk to your service? Perhaps ip whitelisting? - monitoring? How do you know if you service is up and running? If it's down…

Many of these points you're mentioning is exactly why k8s was developed. Yes it makes deploying simple applications unnecessary hard, but it make deploying more complicated applications WAY more manageable. So in the k8s world: - auth: service meshes, network policies, ... - monitoring: tons of tooling there to streamline that - deploy: this at scale is trickier than you'd think, many seem to assume k8s on it's own h…

My first production k8s deployment involved around 60~70 monoliths packed tightly onto small amount of hardware. Saved a lot of money :)

(And yes, if you need extra argument to sell k8s, remind them about bin-packing more applications onto less hw)

Re: Don't start with microservices – monoliths are your friend

#277

Post by p_l » Thu, Dec 16, 2021, 5:05 PM UTC

dkdk8283 wrote: post #186

YetAnotherNick wrote: post #183

Earlier quoted context omitted.

I agree more or less with 1 and 4 mostly. But for monitoring either you would have to monitor the service calling this microservice or need to have a way to detect error. > if it does have memory leaks anyways, just basic cpu/mem usage monitoring on your hosts Who keeps on monitoring like this? How frequently would you do it? In a startup there are somewhere in the range of 5 microservice of that scale per programmer…

Knowing k8s makes it a lot harder - there’s nothing wrong with apps on ec2.

Except for running out of money - or spending a lot of work on optimizing stuff yourself.

Re: Don't start with microservices – monoliths are your friend

#278

Post by p_l » Thu, Dec 16, 2021, 5:07 PM UTC

deniska wrote: post #271

bspammer wrote: post #93

Earlier quoted context omitted.

> no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “d…

> People throw around “distributed monolith” like it’s a dirty phrase but I’ve found it actually a very pleasant environment to work in. For ones I saw, the answer to the question "how do I run our project on a single laptop?" is "haha, you don't". That makes features which could take hours to implement take weeks. But deployment is 5 minutes instead of… 15? Not too worthy of a trade-off. Your CSV writer probably has…

Often with monoliths, once they go into production service at scale, the deployment can be "3 days, arranged 4 weeks in advance, requiring 9 sign offs including one VP"

Re: Don't start with microservices – monoliths are your friend

#279

Post by sparker72678 » Thu, Dec 16, 2021, 5:12 PM UTC

lubesGordi wrote: post #274

The problem with monoliths is that they're written fast and chock full of business logic that isn't reusable anywhere else. With microservices, if done correctly a la hasura, your business logic is abstracted to config, or to the highest level of abstraction your business allows.

I have never been in an environment where business logic could come even remotely close to being definable via config, even if config was some kind of fancy DSL.

Every product I've worked on had deep interdependencies between major parts of the code _at least logically_, because _that was the product_.

At some point you can't factor out the business logic anymore without factoring out the entire business, in my experience. This is a major reason software is so tricky.

Still, I'm fascinated that this could exist somewhere. Have you seen it in the wild?

Re: Don't start with microservices – monoliths are your friend

#280

Post by p_l » Thu, Dec 16, 2021, 5:12 PM UTC

Philip-J-Fry wrote: post #67

The only issue I have with microservices is when you're dealing with atomic things. Like in a monolith you'd probably just stick it all in a database transaction. But I can't find any good reads about how to deal with this in a distributed fashion. There's always caveats and ultimately the advice "just try not to do it" but at some point you will probably have an atomic action and you don't want to break your existin…

Well, there are distributed transaction systems you could use, but usually it's a good idea to ensure things happen inside one transaction in one microservice (also leads to better code in general, IMO - keep your transaction scope as small as possible)