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

Why our team cancelled our move to microservices

steven-lemon182.medium.com

Post reply on HN
Print view View original

221–230 of 243 posts

Re: Why our team cancelled our move to microservices

#221

Post by dpark »

tomc1985 wrote: post #210
mrbungie wrote: post #194

Earlier quoted context omitted.

You're assuming engineers can't be victims of cargo cult, and we all know that's not globally true as it's been discussed multiple times on HN. Marketing teams know that as well, and they exploit that as much as they can.

> Marketing teams know that as well, and they exploit that as much as they can. They exploit this mercilessly , just as hard as they exploit our curiosity and desire for novelty as engineers. To the GP, your company's marketing/sales team may not drive internal technical decisions, but I can promise you that other companies' sales teams do . Why do you think they so persistently step on the heads up their first POC s…

This is very “everyone else is such an idiot”. I feel like you’re a half step away from saying that engineers shouldn’t be allowed to learn about new tech because they’re too stupid to know when not to apply it.

If your team of engineers is incapable of determining good engineering trade-offs, and you have too little influence on the team to steer them back to a reasonable choice, it’s not really marketing’s fault.

You’re probably going to tell me again that I’m too dumb to understand that marketing impacts engineers, so let me be clear, I am well aware that marketing impacts engineers, just as it influences everyone else. But engineers are not helpless fools incapable of making decent technical decisions just because someone tried to sell them on whatever latest serverless tech.

Re: Why our team cancelled our move to microservices

#222

Post by QuercusMax »

throwaway2037 wrote: post #196
QuercusMax wrote: post #173

Earlier quoted context omitted.

Here at Google, one of our most popular microservices frameworks enables microservices to be assembled into servers. If one microservice calls another one in the same assembly, it won't touch the network, and is quite optimized. There's no reason that microservices have to all run in separate binaries, but when it's useful it can be done easily enough without having to change your code.

Is the framework open source? And what language(s)? It sounds interesting!

Not open source; I've only used the java version, but there's support for c++ and go as well.

Re: Why our team cancelled our move to microservices

#223

Post by throwaway894345 »

ironmagma wrote: post #206
throwaway894345 wrote: post #197

Earlier quoted context omitted.

> One function cannot access the memory space of another function any less explicitly than one process can access the memory of another process. You're mistaken. The operating system largely prevents cross-process memory access. Of course, CPU vulnerabilities can circumvent these protections, but even then your micro services can run on distinct machines while monoliths can't. > The only way this would be helpful is…

> The operating system largely prevents cross-process memory access. As do programming languages. Yes, a few languages like C allow you to do anything that's physically possible, but most popular languages including Python and JavaScript make leaking function-internal memory to the outside world either very inconvenient or impossible. As for memory being shared among processes, it's not only not impossible but quite…

> Let's stay focused. There are so many implicit assumptions you're taking as granted, I'm starting to doubt this is even an argument in good faith.

I share your doubts that this is a good faith argument, in particular, you keep responding to arguments that I patently didn't make:

> For one, code is not secret.

I didn't claim code was secret, I claimed that we should secure secrets and prevent attackers from executing routines that they shouldn't have permissions to execute.

> Secondly, when was this discussion scoped to profitable organizations?

I didn't scope the conversation to profitable organizations, I mentioned that profitable organizations often secure their applications. I'm giving you an example and you bizarrely think I'm limiting the conversation only to that example. You do the same thing here as well (and suggest that I'm the one who isn't focused):

> This argument weakens the entire stance, because it shifts the goalpost from "this thing is good" to "this thing is legally required."

Again, I give "in some cases security is even required" and you take it as "we're no longer talking about other reasons for which security is beneficial".

Honestly, the "monolith vs microservice" question is interesting, but it's not interesting to debate someone who is bent on responding to arguments I clearly didn't make. :) Whether you're being obtuse on purpose or by accident, this conversation has become dull, and I'm ducking out of it.

Re: Why our team cancelled our move to microservices

#224

Post by throwaway894345 »

winternett wrote: post #211
throwaway894345 wrote: post #199

Earlier quoted context omitted.

> Many "Monoliths" can be run on something as simple as a desktop emulator. I'm not sure what a "desktop emulator" is, but a lot of micro services can run as native processes or in a VM. There's nothing about micro services that fundamentally restrict where they run--they're just application processes at the end of the day. > my use of the term "distributed means that if AWS East has your DB instance and your web ser…

FTR... A desktop emulator was a reference to something like WAMP or XAMPP... On which a monolith can be run, developed upon, and even tested entirely independent of any host or VM infrastructure. I'm not back pedaling, you're reading too closely and judging instead of looking at the discussion from an objective standpoint and simply seeking clarity and working towards truth. Here's what I posted in this same thread e…

> you're reading too closely and judging instead of looking at the discussion from an objective standpoint and simply seeking clarity and working towards truth

I think you're projecting here. Perhaps we can stick to the actual discussion instead of speculating on my motivations--as though you can understand someone's inner workings from half a dozen Internet comments :).

Anyway, we're no longer talking about microservices or monoliths so it would seem this thread has run its course. Enjoy your day!

Re: Why our team cancelled our move to microservices

#225

Post by ironmagma »

throwaway894345 wrote: post #223
ironmagma wrote: post #206

Earlier quoted context omitted.

> The operating system largely prevents cross-process memory access. As do programming languages. Yes, a few languages like C allow you to do anything that's physically possible, but most popular languages including Python and JavaScript make leaking function-internal memory to the outside world either very inconvenient or impossible. As for memory being shared among processes, it's not only not impossible but quite…

> Let's stay focused. There are so many implicit assumptions you're taking as granted, I'm starting to doubt this is even an argument in good faith. I share your doubts that this is a good faith argument, in particular, you keep responding to arguments that I patently didn't make: > For one, code is not secret. I didn't claim code was secret, I claimed that we should secure secrets and prevent attackers from executin…

> I claimed that we should secure secrets and prevent attackers from executing routines that they shouldn't have permissions to execute.

While this is obviously a noble goal, you mentioned restricting employee access to secrets in relation to restricting (employee) access to code as well. To me, this is throwing the baby out with the bathwater. We can obviously make things harder for attackers by making things harder for everyone, but to carry it out even farther, we may as well make the code fully immutable since then an attacker wouldn’t be able to do anything to it then. If you disagree with this, then surely you must agree that there’s a balance to be found and it depends on the needs of the organization?

> I mentioned that profitable organizations often secure their applications

Well, I never made the argument against securing applications, but assuming you meant that they use microservices, that’s great, although unfortunately it doesn’t mean anything about the overall appropriateness of microservices. Profitable companies are known for moving so slowly they are unable to adapt to anything even when it means their existence is at stake, and also for blindly following the path laid out for them by laws, shareholders, stakeholders, etc. almost as an automaton without brains. So this supporting point isn’t hugely convincing.

If your point is that in a very specific set of cases, microservices are appropriate, then we are in agreement. However this wasn’t the tone generated by the comments I was replying to.

Re: Why our team cancelled our move to microservices

#226

Post by withinboredom »

serial_dev wrote: post #220
withinboredom wrote: post #171

Earlier quoted context omitted.

There’s really not much coordination with a monolithic deployment. Merge your commit and get in line. Monitoring tools will ping you on slack if there’s any issues. It’s probably easier than micro services because all tooling and builds are centralized.

> Merge your commit and get in line. Much easier said than done, if there are 50+ devs working on the same service (monolith). Decisions are made much slower, improvements need to go through long discussions, deployments are much more risky, onboarding is a hassle, and so on. Sure, monoliths work very good for small teams (it's hard to define what "small" is), but I'd say that around 15-30 developers you can think ab…

Are you saying this from experience? From my experience working on a monolith every day with around 400-500 other devs, this is not the case. I don’t even need a code review for minor things. Just commit and get in line (about 2-3 minutes before my commit hits 100% of production).

Re: Why our team cancelled our move to microservices

#227

Post by BackBlast »

whimsicalism wrote: post #62
ironmagma wrote: post #59

Earlier quoted context omitted.

Examining behavior in the limit (a la physics) is interesting. Imagine a system where every function call goes out to a separate process. Suddenly you have a lot of processes waiting around to be called. Debugging requires special tools. Profiling becomes a nightmare. Even determining if the system is fully running becomes difficult. What have you gained?

> What have you gained? Separation of responsibilities? Easier to analyze because you only have so many inputs and outputs to a simpler system? Debugging something that touches a lot of paths in a monolith can be quite nightmarish as well.

If I'm in Java, JavaScript, or Python and there is a code fault, the system provides me a stack trace of the call structure that lead to the error. If I catch the error I can output more related data as I deem necessary. This comes effectively, out of the box.

How do I do a similar stack trace in microservices to understand the path that led to this state? I've used microservices at a couple of companies and their methods were effectively, look at the request id and trace it through this mass of log files for each microservice we are running. It was terrible and could take hours to compile the same information.

What tooling exists to solve this problem with microservices? Genuinely want to know.

Re: Why our team cancelled our move to microservices

#228

Post by karmakaze »

Twisol wrote: post #187
karmakaze wrote: post #153

Earlier quoted context omitted.

I came looking for this in the comments. Invalidates the rest of the post, really.

The post is very explicitly coming from a perspective of "we didn't know what we were getting ourselves into". The story begins after the decision to move to microservices was made, and the backstory of the decision isn't dwelt on (beyond allusions to top-down pressure from management). The important lessons here are on how they recognized the mistake before they had fully committed. Having worked on a team with a si…

I can certainly see how this happens. Points to how poorly all the chatter about microservices obscures important points. This post itself doesn't strongly enough highlight that 12 developers is a full-stop no microservices decision point.

Or to phrase it differently, it's like a horror film where a small/skinny person goes into a dark unknown basement by themselves. Sure there's a story to be had, but the important bits to know come before the decision. I suppose it could be useful how to best defend oneself in a rare situation but avoiding it altogether is better if easy to learn.

Re: Why our team cancelled our move to microservices

#229

Post by edude03 »

WatchDog wrote: post #139
edude03 wrote: post #116

Earlier quoted context omitted.

We are currently between 3-7 services per dev depending on how you count (~40 services developed in house, ~70 if you include third party micro services we run) It would likely be insurmountable if not for using kubernetes, we choice the idiomatic options (gke/GitHub actions/Argo/Prometheus/etc) so starting with micro services wasn’t too bad

Wow, that sounds like an utter nightmare.

I can imagine why you think that, but actually it works really well. I could write a blog post about it if there is some interest.

Re: Why our team cancelled our move to microservices

#230

Post by Tarucho »

The problem is in the hype.

For example, the tradeoff between centralized and distributed has been taken (mostly informally) by big institutions for years. It´s not possible for a large bank with multiple overlapping domains, hundreds or thousands of dev tems (some of them outsourced/offshored) to have all of it´s code in a single repo or a single executable. And not all of it´s applications have the same requirements (technical, scale, etc) either.

SOA came to aid in this case by putting a common integration pattern between the interested parts.

But at some point the idea was hyped, and even small teams with no diverse technical or scale problems started doing simple backends using full blown distributed systems without reason.

Basically: if you don´t have problems of scale (domain, technical or people related) going microservices first is probably not granted.

Post reply on HN