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

91–100 of 468 posts

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

#91

Post by yawnxyz »

woutr_be wrote: post #66

Doesn’t this highly depend on your use case? For example, right now I’m building a system that will take in a URL, crawls the webpage, and does some processing on the data. The whole process takes a good 10 seconds. I designed this as a micro service, simply because I know URLs will need to be queued up. Should this have been done as a monolith? Or am I right that micro services was actually the right approach?

I did something like this too, and figured I'd rather do it for free as a lambda running under Vercel rather than create a droplet or something else and pay for it...

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

#92

Post by stepbeek »

vbezhenar wrote: post #84
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…

Kek. Auth: nobody knows IP address of our server anyway, don't bother with that. And for extra security we have secret port number. Monitoring? Well, we have our clients for that. They'll call us if something happens. Deploy? Copy .war file and restart tomcat. Rollback? What's rollback? Outdated packages? We call those stable packages. I wish I would work in a miracle world you describe.

This sounds dreadful. I don’t think microservices are with talking about with these basics figured out.

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

#93

Post by bspammer »

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 “distributed monolith” like it’s a dirty phrase but I’ve found it actually a very pleasant environment to work in.

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

#94

Post by solididiot »

microservices are such a bad idea for most companies out there. Specially for companies doing onprem SW that suddenly want to "go to the cloud with microservices" without realising that micorservices is the end destination of a long journey involving serious DevOps and a mentality radically different from onprem.

It is just so easy to get it or implement it plainly wrong that it is a disservice to most company to suggest ms without a huge warning sign.

But...it the CV zeitgeist as Design Patterns and SOLID were a decade ago. These days if you don't do ms and don't deploy to k8s you're not worth your salt as a dev. And if you're a company doing monolith you're not worth the time and money of worthy investors. Our field is pop culture. It's all about belonging and plain averse for history. Which is why we go in endless cycles of dogma/disillusionment.

I'm sorry if I sound cynic but you get some cynicism when you see the same movie about the great silver bullet the 3rd or 4th time around.

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

#95

Post by varjag »

verinus wrote: post #29
kkjjkgjjgg wrote: post #22

Maybe I'm too old, but I don't even want to have to worry about all that. I think in terms of functions and I don't care if they are being called remotely or local. That was the promise back in the day of J2EE, and it seems to me Microservices are just a rehash of that same promise. Which never really worked out with J2EE - it was mostly invented to sell big servers and expensive consultants, which is how Sun made mo…

I wholeheartedly agree on most parts, with DevOps being the exception. Devs only focusing on developing/writing source code is certainly not the way to produce sustainable, high quality software- at least in my opinion...

If we were interested in ops we would be sysadmins.

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

#96

Post by woutr_be »

baash05 wrote: post #83
woutr_be wrote: post #66

Doesn’t this highly depend on your use case? For example, right now I’m building a system that will take in a URL, crawls the webpage, and does some processing on the data. The whole process takes a good 10 seconds. I designed this as a micro service, simply because I know URLs will need to be queued up. Should this have been done as a monolith? Or am I right that micro services was actually the right approach?

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).

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

#97

Post by paul_f »

vbezhenar wrote: post #84
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…

Kek. Auth: nobody knows IP address of our server anyway, don't bother with that. And for extra security we have secret port number. Monitoring? Well, we have our clients for that. They'll call us if something happens. Deploy? Copy .war file and restart tomcat. Rollback? What's rollback? Outdated packages? We call those stable packages. I wish I would work in a miracle world you describe.

I cannot tell if this is satire or not. Entering Poe's Law territory

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

#98

Post by Joeri »

marginalia_nu wrote: post #68
usrbinbash wrote: post #56

All ideas that are good in principle, become absurd the moment they are elevated to a kind of dogma, applied to every problem, no matter if it makes sense to do so or no. Microservices are no exception from that rule, and often repeat the same mistake as OOP did with its promise of "reusable code". Does it sometimes make sense to break some larger services up in smaller ones? Yes. Does it make sense to "factor out" e…

I've seen organizations that have hundreds of developers organized in 5-10 man teams, each managing their microservice. I think it tends to happen when a large organization decides to get down with the kids and start to do microservices. Conway's law enters into it in a lot of ways. Because of the way the people are organized into tiny isolated teams, the code shares that shape too. There is an event horizon one team…

Going for microservices without a central director role is indeed madness and leads to inefficiency.

My employer has a landscape like that, hundreds of microservices each managed by a different team (some teams manage multiple). However, we have an enterprise architecture group whose job it is to keep an overview and make sure every microservice is meaningful and fulfills a clear role for the organization. Every project presents their architecture to this group as well as a group of peers and this often results in changes that increase cohesion and avoid redundant work. We had a few semi-interconnected monoliths before, and from what I’m told (I joined after the microservice transition) the new way is better.

However, I still wouldn’t recommend microservices to a new team / org starting from scratch. IMHO microservices only make sense when the system grows so vast it cannot be understood in its entirety by a single person.

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

#99

Post by KronisLV »

vbezhenar wrote: post #84
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…

Kek. Auth: nobody knows IP address of our server anyway, don't bother with that. And for extra security we have secret port number. Monitoring? Well, we have our clients for that. They'll call us if something happens. Deploy? Copy .war file and restart tomcat. Rollback? What's rollback? Outdated packages? We call those stable packages. I wish I would work in a miracle world you describe.

It's easy to be snarky and dismissive about these things, but i've stood in the offices of a governmental org and have looked at people who are unable to receive their healthcare services queueing up because some similarly neglected system refused to work. One that also had a lot of the basics left out.

Figuring out what was wrong with it was hard, because the logging was inconsistent, all over the place in where it logged and also insufficient.

The deployments and environments were inconsistent, the sysadmins on clients's side manually changed stuff in the .war archives, all the way up to library versions, which was horrendous from a reproducibility perspective.

The project was also severely out of date, not only package wise, but also because the new versions that had been developed actually weren't in prod.

After ripping out the system's guts and replacing it with something that worked, i became way more careful when running into amateur hour projects like that and about managing the risks and eventual breakdown of them. I suggest that you do the same.

Don't put yourself at risk, especially if some sort of a liability about the state of the system could land on you. What are you going to do when the system gets breached and a whole bunch of personal data gets leaked?

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

#100

Post by [deleted] »

usrbinbash wrote: post #56

All ideas that are good in principle, become absurd the moment they are elevated to a kind of dogma, applied to every problem, no matter if it makes sense to do so or no. Microservices are no exception from that rule, and often repeat the same mistake as OOP did with its promise of "reusable code". Does it sometimes make sense to break some larger services up in smaller ones? Yes. Does it make sense to "factor out" e…

[deleted]
Post reply on HN