Don't start with microservices – monoliths are your friend
arnoldgalovics.com
Don't start with microservices – monoliths are your friend
1–10 of 468 posts
Re: Don't start with microservices – monoliths are your friend
#2Nice 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 need containerization whether you are on Microservices or Monolyth architecture
- Kibana, Prometheus, Zipkin are not required. But I think you need both logs aggregation and monitoring even if you have just a Monolith with horizontal scalability.
Also, all this is assuming you are not using out of the box Cloud solutions.
Re: Don't start with microservices – monoliths are your friend
#3the main issue with micro-services these days is that people write small applications and think they have a micro service. whereas in reality, they have SOA. a true micro service is a mere worker to process a queue, like send emails. create thumbnails for uploaded images. or delete obsolete data from database. so the truth is in the middle - have a monolith and if one machine can no longer handle your workers' load, move them out into separate MICRO services.
Re: Don't start with microservices – monoliths are your friend
#4Nice 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.
Re: Don't start with microservices – monoliths are your friend
#5I can't understand why a blog has cookies and has facebook hooks at this point in time but then teaching architecture undermining whatever the main argument was at the moment of landing.
Re: Don't start with microservices – monoliths are your friend
#6Nice 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.
DB is needed period, unless you want to go blockchain, DHT route, which is not the way to go with most applications.
Re: Don't start with microservices – monoliths are your friend
#7Nice 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.
I'd see a "distributed something" that takes an input, processes it in multiple ways, possibly passing it around to some APIs or queuing it somewhere without ever needing to store it in its own dedicated area to be a good idea.
That could probably the best instance of something that can be built outside of the monolith and can be manipulated separately.
Re: Don't start with microservices – monoliths are your friend
#8Nice 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.
You misunderstand their point. Not all microservices need persistence at any level. Very often, microservices are just processing things.
Re: Don't start with microservices – monoliths are your friend
#9There 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 http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice.
Did you write a 150 repo application that can not be deployed seperatly anyway? welp thats a monolith.
You can also build a microservice ecosystem without kubernetes on your local network. We have done it for years with virtual machines. Software defined networking just makes things more elegant.
So dont stop using microservices because its "hard" or start writing monoliths because its "easy", because none of that is true in the long run.
What is true is that you have a group of people trying to code for a common goal. The way you reach that goal together defines how you organize your code.
Re: Don't start with microservices – monoliths are your friend
#10Microservices aren't implemented to solve technical problems,
rather they are used to solve organizational problems. Having 10 developers working on a single monolith? Probably fine. 100? Good luck managing that.
Yes they add technical complexity. But they reduce organizational complexity.