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

41–50 of 468 posts

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

#41

Post by kkjjkgjjgg »

kqr wrote: post #21
kkjjkgjjgg wrote: post #14

Earlier quoted context omitted.

Wasn't git invented for that? In what way do Microservices even help? It seems to me you still have to synchronize to be sure that the Microservice from team B does exactly the things that are specified in the new version? Is it not easier to have a pull request that says "this will do thing x", you merge it into your monolith, and then you can see in the git log that this version will indeed to x? How do Microservic…

Well, not git, but modularity was invented for that. You can have a modular monolith that works just as well with 100 people as something service-oriented would. The difference lies in the level of discipline needed. It's much easier to "just go in and make that field public because it makes my implementation easier" when you have a modular monolith. With microservices, you are more explicitly changing an external AP…

Redeployment is an argument I can accept. If it takes hours to redeploy the whole monolith, fixing bugs becomes difficult.

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

#42

Post by VBprogrammer »

Pamar wrote: post #28
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…

Maybe it is just me, but I always understood that properly designed microservices have their own specific datastore , which is not shared with other microservices even if these all collaborate to the same process. If this is actually (still) true, that means that "the way you organize your code" is a bit simplistic. Your example of an "http api that converts pdfs to ..." is surely a valid example of a microservice, b…

IMHO Microservices done well should actually cut a whole vertical through your applications feature space. So not only should it be responsible completely for its own storage of data but it should be responsible for how that data is shown on the front end (or as close to that as you can realistically achieve). A microservice should ideally be reviews or left navigation not customer authentication or order processing.

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

#43

Post by jhoelzel »

Pamar wrote: post #28
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…

Maybe it is just me, but I always understood that properly designed microservices have their own specific datastore , which is not shared with other microservices even if these all collaborate to the same process. If this is actually (still) true, that means that "the way you organize your code" is a bit simplistic. Your example of an "http api that converts pdfs to ..." is surely a valid example of a microservice, b…

Well I dont believe that i need a seperate datastore, but yes i need to communicate my state much more.

The PDF Example for instance: I have to provide all assets that will be converted to startdust or at least links for them I have to define where the finished stardust would be send to (e.g http post)

but its function is nonetheless independent. the epepheral disk on your container is a datastore too. If you need what is stored actually for longer than the request.... that is another story.

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

#44

Post by hzlatar »

formerly_proven wrote: post #4
kulikalov wrote: post #2

Nice article! Although I think you are overdramatizing microservices complexity a little. - Kubernetes is rather a harder way to build microservices. - DB is not an obligatory part of microservices. - Kafka isn't as well. It's a specific solution for specific cases when you need part of your system to be based on an events stream. - Jenkins is not necessary, you can still deploy stuff with a local bash script and you…

> - DB is not an obligatory part of microservices. If the microservices don't have their own store, but are all mucking around in a shared data store, everything will be much harder. I wouldn't even call that a microservice, it's a distributed something. It can work, sure.

Back when I was studying CS in the early 90s, it wasn't obvious at all that I am going to work with a DB anytime in my career. I loved the subject, I passed with A*. But I thought I am not going to see it later, because I didn't plan to work for a bank or some large enterprise.

Then, in about two years, everything changed. Suddenly, every new web project (and web was also novel) included a MySQL DB. That's when the idea about the three tier architecture was born. And since then, a few generations of engineers have been raised that can't think of a computer system without a central DB.

I'm telling this because in microservices I see the opportunity to rethink that concept. I've built and run some microservices based systems and the biggest benefit wasn't technical, but organizational. Once, the system was split into small services, each with its own permanent storage (when needed) of any kind, that freed the teams to develop and publish code on their own. As long as they respected communication interfaces between teams, everything worked.

Of course, you have to drop, or at least weaken, some of ACID requirements. Sometimes, that means modifying a business rule. For example, you can rely on eventual consistency instead of hard consistency, or replenishing the data from external sources instead of durability.

Otherwise, I agree with the author that if you are starting alone or in a small team, it's best to start with a monolith. With time, as the team gets bigger and the system becomes more complex, your initial monolith will become just another microservice.

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

#47

Post by kryptiskt »

I hate the idea of replacing function calls with network requests for organizational reasons, even for a fast network in the same datacenter you add several orders of magnitude of latency to the calls. If the problem is that groups can't work independently of each other in the monolith, it should be solvable with modularization and defining APIs for those modules.

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

#48

Post by Aldipower »

I am just using services with my medium sized application. They are not "micro", but they separate the domains and different concerns pretty well. I have the deployment setup more or less like a monolith, but still having separation of concerns with my services. And stateless service runners.. Fair enough I have the state in a single (mirrored) database. But this works perfectly fine for the medium sized app. Not sure why everything must be black or white.

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

#49

Post by pdpi »

More and more I think of OOP and services as the same thing at different scales. Objects are services, dependency injection is your service discovery/orchestration layer. Your monolith is already a microservice architecture.

In the end, extracting a microservice from a monolith built this way is just a matter of moving the implementation of the object to a separate application, and making the object a frontend for talking to that application.

The single biggest reason OOP gets a bad reputation is because lots of languages insist on treating OOP as the be-all end-all of code structure (Java and Ruby are particularly bad examples) and insist on trying to shoehorn this sort of logic into tiny dumb pieces of pure data.

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

#50

Post by verinus »

I'd sum up with: simplicity is your friend...

recently I am getting more and more thoughtful about "accidental" complexity we add to our solutions in form of dependencies on external libs/module, frameworks such as IoC, log services anyone ;) and on the architectural side microservices etc.

Post reply on HN