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

Starting with microservices

arnoldgalovics.com

Post reply on HN
Print view View original

131–139 of 139 posts

Re: Starting with microservices

#131

Post by sime2009 »

withinboredom wrote: post #100
blakehaswell wrote: post #77

Earlier quoted context omitted.

What exactly do you mean by multiple entry points? Do you have multiple processes which run independently but are co-located in the same repository or are you talking about something else?

You can have more than one Main function, just pick which one to use when you compile. In our case it’s PHP, so the API entry point uses a different index than jobs, for example. They can be deployed differently and scaled differently, but operationally it’s just deploying the same code/configuration everywhere and the only difference is routing. When you are writing code, you very, very rarely have to worry about wh…

We've been doing this too for some "logical" services. For example, we might have a service which has a REST API and but also needs to do long running processing in response to requests via said REST API. The code for both lives in one repo and can share code, data structure definitions, databases etc. One container is made but we deploy it twice with different args. One is set to run the REST API,and the other runs the processing. Both are closely related, but in the cloud we can scale and monitor them separately. It gives a lot of the benefits of "standard" microservices with much less of the code and repo level screwing around. It relaxes the general microservices approach that: one service == one git repo == one database == one container == one deployment in GCP/etc.

Re: Starting with microservices

#132

Post by jayd16 »

bob1029 wrote: post #120
kitd wrote: post #116

Earlier quoted context omitted.

It's not as stupid as you make it sound. It is after all how normal manufacturing works. What you build is constrained by your assembly line. If you want to build something new, start off with redesigning your assembly line. It's time well-invested that pays back in heaps later on.

> If you want to build something new, start off with redesigning your assembly line. It's time well-invested that pays back in heaps later on. We applied this ideology to our software project. Our build/deploy toolchain is 100% in-house code. Turns out, there's actually not a lot of it required because you can build a monster .net project into a single exe distribution with 1 simple command line operation. This appli…

Sounds like the only hard part is a nice interface to select the customer IDs. You can just pass along that data to select build configs or what have you.

How is the rest of the process not applicable to GH or Jenkins?

Re: Starting with microservices

#133

Post by monocasa »

scottious wrote: post #123
monocasa wrote: post #32

I've come to the conclusion that microservices as usually implemented are simply a Conway's law concern. We haven't had a great track record defining the semantics of component boundaries, but http is both simple enough that it constricts code flow in a particular way leaving a lot of misunderstandings and bike shedding discussions off of the table, and is the ligua franca for external services owned by other orgs so…

There are plenty of monoliths that scale in terms of number of contributors and organizational changes. For example, the Linux kernel. I've worked on massive monoliths that were 20 years old and changed hands and org structures tons of times and nobody ever thought "this needs to be microservices!" Microservices are not the only way to modularize code. Also, there is TONS of bike-shedding with regard to HTTP. Which H…

> There are plenty of monoliths that scale in terms of number of contributors and organizational changes. For example, the Linux kernel. I've worked on massive monoliths that were 20 years old and changed hands and org structures tons of times and nobody ever thought "this needs to be microservices!"

> Microservices are not the only way to modularize code.

Nobody said that it was the only way to modularize code.

However, but to be frank, most of those require greater discipline than most of the engineering teams going to microservices have. These teams don't do a great job at microservices, but probably would do a worse job with a monolith.

> Also, there is TONS of bike-shedding with regard to HTTP. Which HTTP method do you use? How do you structure your paths? What does the body of the request look like? How to we translate failures into the various HTTP error codes? Do you send a 200 or a 201 status for this particular request? I could go on and on... Even among well established HTTP APIs, there are differences.

You can bike shed anything, that's why it's called bikeshedding. Referring to nobody being able to contribute to the design review of a nuclear reactor so the committee just fights over the color of the bikeshed. That being said, the state space of an HTTP API is strictly smaller than a local library's API, and you can generally expect backend engineers to at least know what complete the state space of options looks like and what the tradeoffs are.

> This is very much a double edged sword. I've seen this happen and people just tend to avoid services in languages/frameworks that they don't know. And even if they don't avoid them, they are less productive in them. We have a critical services written in Rust and one guy at the company knows Rust. We have 2 services written in a particular Java reactive framework which only a few people know how to use. Any newcomers to these services have to spend a lot of time learning a new thing.

The other end I've seen is that having the whole org on one tech stack is a single organizational point of failure. It's not an issue for smaller orgs, but if you have more than say, 200 devs working on the same product, you want a little experimentation and a lower barrier to new technology. If something is abandoned you can simply replace it, since it's not your literal entire stack. And forcing your devs to be polylingual I've found makes them better in all of the language they use, even their primary language.

Re: Starting with microservices

#134

Post by dmux »

One problem I've never seen mentioned regarding microservices is what happens when the organization that produced them has moved from growing to stagnation and finally into decline. If microservices ship the org-chart, what happens when that organization fails to attract engineers?

I worked for a company that microserviced themselves into a pit. We had a huge layoff which completely killed the morale of the remaining engineering staff. Over the next 3 years, more and more engineers left and the company refused to replace them. What started out as teams (~5 people) responsible for ~3 microservices ended up as teams of ~3 people responsible for ~6 microservices.

It was kind of cool to be responsible for more architecture and see how it all fit together, but the sad reality was that too many of the microservices that had been stood up were stitching together disparate data from other microservices to then perform what a single SQL query against a RDBMS was doing.

Re: Starting with microservices

#135

Post by Nextgrid »

heavyset_go wrote: post #66
mcv wrote: post #35

Earlier quoted context omitted.

I notice there's a lot of comments here saying this exact same thing, and it's also what seems most sensible to me. Yet microservices are getting all the hype. Should be hype a thorough modular design more?

Yes, but microservices maximize cloud vendors' revenue compared to monoliths.

They also maximize the number of engineers and managers needed to oversee the whole thing. People are unlikely to speak against something that guarantees their employment.

Re: Starting with microservices

#136

Post by Nextgrid »

JamesSwift wrote: post #129
twic wrote: post #112

Earlier quoted context omitted.

Even this premise is fundamentally mistaken. If you have a monolith, and the LoginModule is overloaded, you add more hardware, and it's the LoginModule which makes use of the additional resources. The AppointmentModule isn't going to suddenly start using more resources just because they're available.

Not really, the load gets spread out across your nodes so if you go from 1 -> 2 then the new AppointmentModule is handing 50% of the previous load. Thats just CPU. RAM tends to be stickier and you can easily cost yourself a lot more than "needed" to overprovision in this manner.

How/why would the AppointmentModule suddenly start using CPU? Where does it get called from? Unless a web request comes in that requires it, it shouldn't be called at all. If all your incoming requests call the LoginModule, the AppointmentModule shouldn't enter the picture.

Re: Starting with microservices

#137

Post by jamesfinlayson »

dm3 wrote: post #97
jamesfinlayson wrote: post #86

Earlier quoted context omitted.

A company I worked at went all in on option c - there was a random number service (that just wrapped a random number generation library), and sending an email was split across multiple services - one to pull the email request from the database, one to generate the email from the template, one to actually send the email and one to save the templated email to the database.

How did it work out? Very curious, as such granularity of deployable units seems absurd unless it's deployed into a single runtime...

In reality it worked - each service only talked to the next so in that sense it was okay. But each service was its own binary running in its own container (someone went to a conference and heard that S3 was made up of 500 microservices, to they decided we needed as many microservices as possible). The bit where it didn't work so well was making changes and testing those changes - the original developers hacked it together then didn't want to touch it after that, so there was no dev environment (just staging environments to hijack) and no functional/e2e tests.

Re: Starting with microservices

#138

Post by JamesSwift »

Nextgrid wrote: post #136
JamesSwift wrote: post #129

Earlier quoted context omitted.

Not really, the load gets spread out across your nodes so if you go from 1 -> 2 then the new AppointmentModule is handing 50% of the previous load. Thats just CPU. RAM tends to be stickier and you can easily cost yourself a lot more than "needed" to overprovision in this manner.

How/why would the AppointmentModule suddenly start using CPU? Where does it get called from? Unless a web request comes in that requires it, it shouldn't be called at all. If all your incoming requests call the LoginModule, the AppointmentModule shouldn't enter the picture.

The load balancer routes requests to all nodes. So each node will have some load (approximately 50% of the prescale load as I said)

Re: Starting with microservices

#139

Post by diordiderot »

KronisLV wrote: post #115
diordiderot wrote: post #102

Earlier quoted context omitted.

Could you explain this more??

> PHP, hear me out, each file is basically an independent hot swappable 'service'. I think that what the OP is referring to is the fact that you can map URLs to PHP files pretty easily and therefore changing what an endpoint does can be as simple as just swapping out a single file for another one. However, that tends to fall apart with most modern frameworks, like Symfony, Laravel, Lumen and Slim, where you will typi…

Thanks for the reply!
Post reply on HN