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

Don't start with microservices – monoliths are your friend

arnoldgalovics.com

Post reply on HN
Print view View original

191–200 of 468 posts

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

#191

Post by jeremyjh »

ianbutler wrote: post #190
jeremyjh wrote: post #179

Earlier quoted context omitted.

Creating a lot of actors and messaging for the business logic of your application is considered an anti-pattern in Elixir, and a typical novice mistake. Applications in Elixir are structured using functions that are in modules that call other functions in other modules. Yes you can use OTP applications to isolate dependencies but none of this is done with the intent to more easily break up your app into a bunch of mi…

Right but that's not really what they're saying, they're talking about Umbrella Apps, https://elixirschool.com/en/lessons/advanced/umbrella_projec... Which is a distinct feature made for breaking up the logic of your applications into smaller, domain bounded libraries. Umbrella apps are for the most part like regular libraries, just internal to the project which let's you do neat things like share config and deployme…

Yes I acknowledged OTP apps as a valid structure. An umbrella app is project that builds multiple OTP apps.

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

#192

Post by alisonkisk »

KronisLV wrote: post #180
madsbuch wrote: post #170

Earlier quoted context omitted.

Not so much snarky as a commentary on the diligence. Yes, if there is mission critical software that affects millions of people, do all that stuff. If your pdf -> stardust service is more a convenience then don't spend hundreds of thousands on infrastructure.

> ...then don't spend hundreds of thousands on infrastructure. I find it curious how we went from doing the basics of software development that would minimize risks and be helpful to almost any project out there to this. To clarify, i agree with the point that you'll need to prioritize different components based on what matters the most, but i don't think that you can't have a common standard set of tools and practic…

I am opposed to sarcasm on the internet, but even I saw the obvious satire of the GP post.

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

#193

Post by ianbutler »

jeremyjh wrote: post #191
ianbutler wrote: post #190

Earlier quoted context omitted.

Right but that's not really what they're saying, they're talking about Umbrella Apps, https://elixirschool.com/en/lessons/advanced/umbrella_projec... Which is a distinct feature made for breaking up the logic of your applications into smaller, domain bounded libraries. Umbrella apps are for the most part like regular libraries, just internal to the project which let's you do neat things like share config and deployme…

Yes I acknowledged OTP apps as a valid structure. An umbrella app is project that builds multiple OTP apps.

No, you do not even need OTP functionality on the child project, that's my point. Not everything uses OTP.

Edit: We may be talking past each other, from Sasa Juric:

"It’s worth noting that poison is a simple OTP app that doesn’t start any process. Such applications are called library applications." Which is what I'm thinking of. He also says "Finally, it’s worth mentioning that any project you build will mix will generate an OTP app."

I was mainly talking about you don't have to use anything like GenServer or other OTP functionality with the split out app so they're more like the library application but that is still in fact an OTP application even if you're not using any of the downstream OTP features.

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

#194

Post by throwaway5752 »

Services, serverless, and monolith don't have to be exclusive and can be applied in different areas where they are good fits. You obviously can't have a pure monolith and everyone knows that because of geographical distribution, scaling, and availability, let along languages having niches.

Monoliths are your friends. SOA is your friend. Serverless is your friend. You don't hang out with all your same friends and do the same things with them in real life, either.

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

#195

Post by bdcravens »

woutr_be wrote: post #96
baash05 wrote: post #83

Earlier quoted context omitted.

In rails this would be an activejob (part of the mono), and spinning up workers would be trivial. The "workers" would pull off a redis queue, and you could add different jobs to the queue easy-peasy.

That's fair, maybe I'm already planning to far ahead. But I ended up using RabbitMQ and Node (since i wanted to use Puppeteer for this, I actually needed to render the webpage).

Put Puppeteer calls in a REST API using Express or the like, call API from Activejob/Sidekiq. (I've built this)

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

#196

Post by farias0 »

matwood wrote: post #144
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…

I've argued for a long time that microservices should grow out of a monolith like an amoeba. The monolith grows until there is a clear section that can be carved off. Often the first section is security/auth, but from there it's going to be application specific. A modulith could be just another step in the carve up process. But, there is no right answer here. Application domain, team size, team experience, etc... all…

In my experience with enterprise software one of the things that cause most trouble is premature modularization (sibling to the famous premature optimization).

Just like I can't understand how people can come up with the right tests before the code in TDD, I can't understand how people can come up with the right microservices before they start developing the solution.

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

#197

Post by AtNightWeCode »

victor106 wrote: post #24
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…

>monorepo/monolith/microservices/etc" is -just- the way you organize your code. It’s also about how you deploy your code. If you have 1000 micro services do you have 1000 deployment pipelines? If so how do you manage those pipelines? If not, you sacrifice independent deployment of each micro service.

If you have that many services you could define a set of generic pipeline versions that you maintain. Then you can tag each service with which type of pipeline to use. The rest is solved with automation.

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

#198

Post by victor106 »

jhoelzel wrote: post #54
victor106 wrote: post #24

Earlier quoted context omitted.

>monorepo/monolith/microservices/etc" is -just- the way you organize your code. It’s also about how you deploy your code. If you have 1000 micro services do you have 1000 deployment pipelines? If so how do you manage those pipelines? If not, you sacrifice independent deployment of each micro service.

yes and no. i totally get what you are saying but this problem has been solved lately in my opinion. Also deployment is part of code organistaion no? i like to point out the fact that i explicitly mentioned you do not need to decide, you can use both at the same time but i would like to try to answer your point anyway: Maybe I am just spoiled with go and github, but those deployment pipelines can be directly integrat…

> totally get what you are saying but this problem has been solved lately in my opinion.

How? Can you provide any examples?

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

#199

Post by bdcravens »

jstimpfle wrote: post #86
asimpletune wrote: post #46

Your code base should reflect the organization of people working on it. Virtually all technical merits are outweighed by that.

Or should the organization of people reflect the code they're working on? :-)

People are expensive, code is cheap.

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

#200

Post by ldiracdelta »

francasso wrote: post #167

For the life of me, I never understood, nor will ever understand, why people think making RPCs is easier or leads to better design than making normal function calls ("split your code into microservices, it will make your code modular, smaller and easier to understand!"). There are legitimate reasons to put a network between one piece of code and another, but "modularity" is not one of them.

Exactly. Injecting 2 NICs and the internet into a function call isn't a panacea.

People talk of monoliths as if code libraries don't exist. You can have fantastic independent interfaces with libraries too, if you want them.

Post reply on HN