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

Microservices are a tax your startup probably can't afford

nexo.sh

Post reply on HN
Print view View original

211–220 of 272 posts

Re: Microservices are a tax your startup probably can't afford

#211

Post by PaulHoule »

asim wrote: post #2

> Microservices only pay off when you have real scaling bottlenecks, large teams, or independently evolving domains. Before that? You’re paying the price without getting the benefit: duplicated infra, fragile local setups, and slow iteration. For example, Segment eventually reversed their microservice split for this exact reason — too much cost, not enough value. Basically this. Microservices are a design pattern for…

I've tended to use microservices in limited cases where the system had to serve a few requests that had radically different performance requirements, particularly memory utilization. I had a PHP server for instance that served exactly one URL for which PHP was not a good fit and a specialized server in another language for that one URL gave like 1000x better performance and money savings in terms of not needing a much bigger PHP server.

Using Spring or Guava in the Java world it is frequent that people write "services" that are simply objects that implement some interface which are injected by the framework. In a case like that you can imagine a service could have either an in-process implementation or an out-of-process implementation (e.g. via a web endpoint or some RPC.) Frameworks like that normally are thinking at the level of "let's initialize one application in one address space at a time" but it would be nice to see something oriented towards managing applications that live in various address spaces.

Trouble is that some people get this squee when they hear they can use JDK 9 for this project and JDK 10 for another project and JDK 11 for another project and they'd rather die than eschew the badly broken Python 3.5 for something better. If you standardized absolutely everything I think you could be highly productive with microservices because you wouldn't have to face gear switching or deal with teams who just don't know that XML serialization worked completely differently in JDK 7 vs JDK 8 thus the services they make don't quite communicate properly, etc.

Re: Microservices are a tax your startup probably can't afford

#212

Post by wild_egg »

roguecoder wrote: post #180
djtango wrote: post #119

Earlier quoted context omitted.

Could you elaborate on how functional programming relates to people's relationship with Microservices?

Sure! Functional programming precludes encapsulation, so it doesn't scale indefinitely the way fractal paradigms can. Eventually, the complexity becomes overwhelming. One effective solution to that is introducing microservices: programmers can still write entirely functional code, but have encapsulation in the form of services. They have to be micro, though, because conventionally-sized services are still big enough…

> Functional programming precludes encapsulation

Since when? Maybe we have different definitions of "encapsulation" but this clause seems nonsensical to me. FP is huge on encapsulation

Re: Microservices are a tax your startup probably can't afford

#213

Post by gavmor »

sergiotapia wrote: post #159
gavmor wrote: post #99

Earlier quoted context omitted.

Ha! I always feel more than a little embarrassed when it happens, but I can't sit idly by while TDD is slandered, especially from so seemingly oblique an angle! While I agree with you regarding microservices (eg language abstractions provide 80% of the encapsulation SOA provides for 20% of the overhead) and I readily acknowledge that 100% test coverage is a quixotic fantasy, I really can't imagine writing reliable so…

i didn't say i don't write tests. i trashed tdd, the practice of tdd is dogma, impractical and unrealistic.

> Or, do you simply wait until after the program is written to [observe] its [behavior]?

How is that even possible?

Re: Microservices are a tax your startup probably can't afford

#214

Post by mvdtnz »

The opposite of "microservices" is not "monoliths". The organisation I work at has something like 250-300+ microservices all in a monolith. This is the best of both worlds for large applications, in my opinion.

(It's no coincidence that this company was largely loaded up with ex-Googlers in the early days).

Re: Microservices are a tax your startup probably can't afford

#215

Post by bunderbunder »

jayd16 wrote: post #45
actionfromafar wrote: post #11

Earlier quoted context omitted.

This is true, but monkey patching is scary. If you can switch over a monolith, and keep a rollback in case of trouble, do that. Make small changes in the monolith a time, though.

Btw, do any good, modern CI tools support incremental rollout of multiple in-flight changes on monoliths? As in patch A is live, team B wants to rollout A+B and team C wants to rollout A+C. Ideally, A+B+C will eventually go live. Do cloud/paas providers deeply support this flow anymore? Every dashboard would need to compare across multiple live versions and I haven't tried that in a while.

I'd say this is a job for feature flags. That way you always have exactly one live version of the code, but still retain the ability to hide WIP from users until it's ready.

If you're instead doing this with feature branches or something like that, then by definition you don't have CI. You have NI: Never Integration.

Because, to an approximation, there's never any point in time where all of the code you're working on is integrated together so that everyone has a chance to see how what they're doing interacts with what everyone else is doing. And yes, it is possible for a branch to successfully auto-merge and produce something that compiles and passes all automated tests, and still introduce a horrible regression defect because of an unanticipated interaction between two different changes on two different feature branches. I don't see it happen often, but when it does it usually creates such a big production SNAFU that even once every 5 years is still way too often for my taste.

Re: Microservices are a tax your startup probably can't afford

#216

Post by quesera »

JackSlateur wrote: post #196
roguecoder wrote: post #164

Earlier quoted context omitted.

I haven't seen a broken build in at least nine years, not since I left the company with a merge process built out of bash scripts that took three hours and required manual hand-holding. I am genuinely curious what situations you are seeing where builds are making it through CI and then don't compile. It isn't always worth investing in quality, but when it is it is entirely possible to write essentially bug-free softw…

You are absolutely right. Of course, if people wrote bug-free code, then there would be no bug ! Bug-free code in the actual code, or bug-free code in the test code, this is the same story. If you write stuff and never have any bug, then either: - you are lying - you do not write much - you only write really simple things - you are Jesus, came back from heaven to shine his light on us, poor souls The more complicated…

This seems a bit much.

In the DVCS era, we have inexpensive branching. Do as thou wilt on your topic or epic branches. Rebase them against main/master before merging upwards. Fix what must be fixed first.

Main/master branch should never fail CI. If it does, there is something seriously wrong with your branch lifecycle and/or deployment process.

Re: Microservices are a tax your startup probably can't afford

#217

Post by antonvs »

abirch wrote: post #30
mindcrash wrote: post #9

I know about a org with ~2-3 devs who decided microservices would be cool. I warned not to go that way because they would surely face delivery and other issues which they wouldn't have when building the solution based on a architecture archetype which could be a better fit for the team and solution, which I evidently decided should be a modular monolith. (the codebase at that point was already a monolith, in fact, bu…

Microservices are GREAT when 1 team owns each service. I haven't seen a good use case when you have 1 team supporting multiple microservices.

I’m guessing you’re thinking of a certain kind of application (web apps perhaps?), where a monolith can make sense. But that’s but the only kind of application.

We have dozens of service components that are all largely independent of each other - combining them together would be purely a packaging decision, and wouldn’t really simplify much. In some cases, it wouldn’t make sense or even be possible at all.

An example is our execution agent, which executes customer workflows - that’s completely independent both conceptually and from a security perspective. Each agent instance executes a single flow at a time, for resource consumption and security reasons, which entails an ecosystem of services to manage that - messaging, data ingestion at scale (100K flows per day, multi-petabyte “hot” datastore for active data), orchestration, and other supporting services such as data access and network routing.

All of our teams support multiple services, and many of them qualify as microservices.

Re: Microservices are a tax your startup probably can't afford

#218

Post by antonvs »

roguecoder wrote: post #180
djtango wrote: post #119

Earlier quoted context omitted.

Could you elaborate on how functional programming relates to people's relationship with Microservices?

Sure! Functional programming precludes encapsulation, so it doesn't scale indefinitely the way fractal paradigms can. Eventually, the complexity becomes overwhelming. One effective solution to that is introducing microservices: programmers can still write entirely functional code, but have encapsulation in the form of services. They have to be micro, though, because conventionally-sized services are still big enough…

You’re suffering from a misunderstanding there. Functional programming is all about encapsulation, starting at the individual function boundary (closures can encapsulate state) and then at every layer above that.

Functional languages have some of the most rigorous module systems available. In fact Java adopted such a system recently, showing the weaknesses in its previous support for encapsulation via classes and packages.

Re: Microservices are a tax your startup probably can't afford

#219

Post by bossyTeacher »

roguecoder wrote: post #158
codr7 wrote: post #149

Earlier quoted context omitted.

Integration testing? Less mocking, more bang for the buck.

I am so mad that the mockists stole the word "unit test" for their thing. The original definition of a unit test was writing "integration" tests for each of the sub-components of a system. (Mockist tests are fine for people who really want them, as long as you delete them before checking in the code.)

i thought mockist tests are written in a separate test module

Re: Microservices are a tax your startup probably can't afford

#220

Post by satvikpendem »

gavmor wrote: post #213
sergiotapia wrote: post #159

Earlier quoted context omitted.

i didn't say i don't write tests. i trashed tdd, the practice of tdd is dogma, impractical and unrealistic.

> Or, do you simply wait until after the program is written to [observe] its [behavior]? How is that even possible?

Write the program, run the program, observe. Or, write the program, write the tests, run the program, observe for breakages. Neither are TDD, the practice of writing tests first before any actual implementation is written, which I agree with the parent is dogma, impractical, and unrealistic.
Post reply on HN