[HN Gopher] Don't microservice, do module
___________________________________________________________________
Don't microservice, do module
Author : thunderbong
Score : 98 points
Date : 2024-05-24 13:09 UTC (9 hours ago)
(HTM) web link (yekta.dev)
(TXT) w3m dump (yekta.dev)
| gostsamo wrote:
| Yet another self righteous person on the internet teaching us the
| errors of our thinking. Everything wrong with micro services is
| an issue with micro services and everything wrong with modules is
| a skil issue of the person doing the modules.
|
| > Once the interface is established, each team can operate
| independently, just like in microservices, as long as they adhere
| to the defined bounds.
|
| Where I was lost laughing.
|
| I'm sorry, but the hords of spaghetti monsters that I battle on a
| daily bases are spawning because communication is hard the more
| people are involved in it and the more someone is in a hurry to
| deploy their feature. Not even talking for the fun when you need
| to update a third party dependency and you discover that half of
| the code base depends on a now removed feature, so expect
| migration in 5 to 12 years time.
| Joel_Mckay wrote:
| Microservices can destroy DevOps teams used to kludging
| polyglot stacks together.
|
| The issue is hardly limited to training, but rather ignorance
| of ones own bad habits.
|
| Author probably heard the buzzword off someone else's CV. =)
| graypegg wrote:
| I feel like at this point in my career I've worked in all four
| quadrants of the spagehtti/encapsulation plane
| ^ monolith |
| | <- spaghetti ----+------ clean ->
| | | independent services
| v
|
| I really feel like it doesn't correlate. I think the real cause
| of spaghetti monsters is *mismatching* microservices to
| applications that are actually a single project under the hood,
| or monoliths to applications that are actually multiple
| applications under the hood.
| solidasparagus wrote:
| If you turned that into a heatmap of all software projects, I
| bet there would be hotspots. Probably would need to filter by
| project size or you would just end up with clusters at the
| top-right and bottom-left though
| m_2000 wrote:
| Having an opinion on something doesn't make the speaker a self
| righteous person.
|
| Regarding the topic, I assume that with "the hords of spaghetti
| monsters" you mean lack of software perfection. In our
| profession, it's mostly about how to manage the lack of
| software perfection, and the answer does not always have to be
| a microservive. They are great for controlling hardware
| resources in a cloud-deployment, but then I see tech-dudes
| dockerizing everything anytime without asking why.
|
| It's a decision every dev team have to make for themselves.
| gostsamo wrote:
| Opinions are like asses - everyone has one. Self righteous
| people are those who think that only their opinions matter
| and try to present them as facts, rolling over any reasonable
| objection with hand waving and insulting the other party for
| not understanding things.
| immibis wrote:
| This comment is also your opinion, which you think is the
| only one that matters, and you present as fact.
| HL33tibCe7 wrote:
| As I've grown older I have developed a heuristic, which is that
| people who talk/write like this, i.e. being completely convinced
| that one way of doing things is always wrong and one way of doing
| things is always right, and that people doing things the other
| way are just ignorant/stupid/wrong, usually have no idea what
| they are talking about.
| zdw wrote:
| I feel the same way about people who are "Everything needs to
| be containerized in K8s". Sure, it's useful in some cases, but
| it isn't some universal panacea.
|
| Understand the problem space, understand the solution space,
| and try to find a fit, don't just grab your favorite hammer and
| start whacking away.
| Art9681 wrote:
| The k8s evangelists are operating under the assumption that
| if your product or service is successful, you're probably
| going to want to scale it, and if you believe in that vision,
| then you're probably going to want to think about k8s early
| in your project, not when you've grown it to millions of
| users worldwide.
|
| But I get what you mean.
| alemanek wrote:
| I know you are advocating that position. But, I have seen
| lots of failed projects because of that thinking. They
| failed to get to customer #1 because they were building
| something to handle customer #1,000,000.
|
| Unless you are building something that can kill people if
| it goes wrong just get it out the door and be as
| disciplined as you can along the way. If it is successful
| then you have the money to split it up into a SoA when you
| need it.
| Muromec wrote:
| There are some none obvious ways to kill people with bad
| API design even if you don't work in a medical industry
| and don't deal with heavy machinery. Corners being cut
| here and there, context gets lost, then it gets reused in
| a (non)obviously inappropriate and suboptimal way and
| somebody indeed dies.
|
| Please take effort and do quality stuff as if your life
| depends on it.
| marcosdumay wrote:
| That assumption that you will want to scale does not always
| hold;
|
| The assumption that you want to scale into millions of
| users do not always hold;
|
| The assumption that you need kubernetes to scale into
| millions of users (or that you will even want it) does not
| always hold;
|
| The assumption that solving that problem from the start
| leads to a better outcome than waiting that the problem
| appears has "winning the lottery" odds of not being the
| opposite of the truth.
| rswskg wrote:
| It's not about everything fits, it's just much easier for
| orgs to have a consistent environment for developers to use.
| Google does this to great success, getting out of the box
| logging, metrics, a universal way to define a system, access
| secrets. A whole class of decisions stop being made all the
| time. Anyone in the org can look in a repo and understand
| what and where everything is deployed. It's simple stuff like
| this that make it compelling.
| frenchman99 wrote:
| I agree with you. And at the same time, I often feel like it is
| more difficult being heard when being nuanced. It seems like
| what gets discussed most are strong opinions.
| outofpaper wrote:
| Maybe we need to work on Sound bites
|
| - The only thing every project has in common is that they are
| all different projects.
|
| - Success in one project doesn't guarantee success in
| another.
| josephg wrote:
| Yep. It's easier for a simple message to be carried by the
| wind.
|
| But the process of growing up is one of increasing capacity
| for discernment. Ie, you learn more subtlety discerning when
| thing A or B is a better idea in any given moment. Will a
| hard or soft approach work better? Use my old tools or learn
| this new framework? Make a long term or short term decision
| here?
|
| It's hard to communicate because this kind of learning takes
| a lifetime to accumulate.
| mattgreenrocks wrote:
| Yeah, so it presents a real conundrum. If you read the
| article, then he still presents arguments in favor of
| microservices.
|
| > I often feel like it is more difficult being heard when
| being nuanced. It seems like what gets discussed most are
| strong opinions.
|
| I really resent this phenomenon. It traps us in poor local
| maxima because our systems optimize for engagement over
| actual development of complex, nuanced opinions. It feels
| like the dopamine-addled end up indirectly pulling the levers
| on how we talk even if they're less interested in the actual
| craft.
| onehair wrote:
| The hardest part is when you're being nuanced and people
| misconstrue it as you being indecisive xD
| exe34 wrote:
| could you give an example? my approach is usually something
| like "I've come up with three options here, I think the
| first two are equally good, I'm mentioning the third for
| completeness, but I don't think we should do it
| because...."
| _heimdall wrote:
| I've definitely seen that happen, and in my opinion its just
| a sign of bad culture or bad leadership. That's not to say
| its toxic or widespread, maybe its just a poorly run meeting,
| but nuance should be a focus of any important discussion
| rather than the voice that goes ignored.
| tpmoney wrote:
| My approach is to have strong opinions (weakly held), and ask
| if people have objections to the tradeoffs. That tends to
| keep the focus on specific reasons to choose a given path
| rather than you and someone else just having different
| preferences. Doesn't always work, but it's a lot easier than
| fighting over whether option A or option B is just
| universally better.
| bloppe wrote:
| Depends on your audience. Maybe you need to dumb it down for
| some people sometimes. That's life. I just try to stay in
| situations where the audience appreciates nuance if I can
| deepsun wrote:
| I.e. every architectural question in IT is answered by "It
| depends".
|
| PS: And every single problem is a "problem in communication".
| josephg wrote:
| While true, but that's totally devoid of information. People
| still need to make decisions. Even people who lack the wisdom
| to make them well.
| _heimdall wrote:
| That's really where "it depends" is important though. First
| the decisions need to be what matters and what to
| prioritize. With that context its much easier to decide on
| the best technical implementation _for your needs_.
|
| The problem is conversations often end up being "we're
| starting this shiny new project, what tech stack should we
| use?"
|
| What is really needed is a shortlist of priorities, from
| scaling concerns to types of users and how frequently
| content/data may change. Without that its just a grab bag
| of tools people are familiar with and the latest hype
| trend.
| themgt wrote:
| _There's a Persian proverb, which is a shorter form of a poem
| by Saib Tabrizi, which says "don't microservice". We don't live
| forever, do we? Laying the first brick correctly is the first
| step to avoid building a crooked wall._
| rgrieselhuber wrote:
| The best advice I got early in my career on this topic was:
| "Nobody serious is going to take you seriously if you give one
| option as the 'way it has to be.' Everything has trade-offs,
| you will be much more effective as a communicator if you list a
| few options, along with their trade-offs (and be honest about
| these). You can even have your preferred / recommended option
| but it also must come with trade-offs."
| hakunin wrote:
| One of the problems I often see is that when trying to
| explain one of the possible options, people don't understand
| it. When that happens, you try to explain it to them harder.
| Your explanation is then mistaken for pushing for that
| option. It's important to carefully navigate around this
| perception. People should understand that first you just want
| to be on the same page what your options are, and then
| discuss the best one.
| rgrieselhuber wrote:
| Very true. It can be hard to properly articulate a position
| without feeling like you're being too aggressive, I
| struggle with this a lot.
| _heimdall wrote:
| My approach to that has always been to make sure I'm
| calling my assumptions with a possible option, usually
| that's either the use cases we care about or the
| scaling/infrastructure concerns.
|
| I learned pretty early on that its really easy for that
| context to be lost and that miscommunication go missed. Its
| so much easier to catch miscommunication early when a few
| extra seconds or minutes are spent calling out the context
| and assumptions that make one option best.
| hakunin wrote:
| This is good sometimes, other times it risks losing the
| audience. Extra info works better when they're ready
| (i.e. asked for it). This is why it's such a difficult
| balancing act. You don't want to preemptively answer
| questions that people didn't realize they should ask yet.
| Atotalnoob wrote:
| I usually have my assumptions written, so I can flip to
| them quickly if there is any confusion
| _heimdall wrote:
| For sure, I was mainly thinking about later stage
| discussions where decisions like tech stack,
| architecture, or infrastructure should really be made.
|
| Early on its often all about use cases and users you're
| trying to reach. If microservices versus monoliths
| becomes much of a debate that early engineering is
| probably getting too far ahead of the product IMO.
| dpacmittal wrote:
| I do this instinctively but I feel like I'm coming across as
| confused and unsure.
| citrin_ru wrote:
| Well, you mileage can vary. I see trade-off almost everywhere
| but many managers are not exited to hear about trade-offs and
| want to get a perfect solution when you don't need to
| sacrifice anything. Though it is not as bad as a manager who
| already made a decision ignoring trade-offs of different
| options.
| carimura wrote:
| Same. Basically an inverse relationship between certainty and
| knowledge. Sort of like those stories told by entrepreneurs
| about why their startups were successful.
| alemanek wrote:
| Yep, I used to be that guy as well. It is easier to see things
| as black and white because then you don't need to dive deep and
| it is easier to sell to management. The really strong
| engineers/architects I have known can explain the trade offs of
| the various approaches.
|
| For small teams or early stage development I love a well
| architected modular monolith. Grow past a couple of teams and
| maybe add some dedicated ops people and service oriented
| architectures start making more sense. Get real big and have
| the capacity to handle the monitoring and orchestration
| challenges and microservices enable that.
|
| It's all trade offs and recognizing that allows you to evolve
| with your operational and organizational needs.
| seabrookmx wrote:
| I much prefer "service oriented architecture" terminology to
| "microservice" because services need not be the same size.
| Have a daemon listening to a queue to send emails? Sure,
| microservice! Have 10 REST endpoints that are backed by the
| same interconnected data? Sure you could have 10 lambdas or
| something but.. why?
| Brajeshwar wrote:
| I've worked on quite a few defining products with a friend,
| business partner, and all-round designer-engineer genius. About
| a decade ago, we decided to answer, especially in the early
| stages, that anything that needed our opinion was - "It
| depends."
|
| There isn't one silver bullet for most problems or situations;
| it all depends on several factors.
| _heimdall wrote:
| My only real question when I have interviewed anyone for a
| senior level role or similar is to find out whether they'll
| start with "it depends" or similar.
|
| I'll lay out what sounds like a pretty clear algorithm or
| infrastructure scenario but skip some key assumptions that
| are needed. What I want to see is follow-up questions related
| to users, scaling, data retention, etc. Its a big red flag
| for me if a candidate jumps right into a solution.
| onetimeuse92304 wrote:
| Yeah, I am also suspicious about people with radical opinions.
| Truth is _USUALLY_ somewhere not at the end of scale.
|
| BUT, have you noticed yours is also a radical opinion?
|
| The reality is that sometimes, a radical opinion is actually a
| correct one.
|
| Which is to say heuristics are useful but they still do not
| replace critical thinking.
|
| The problem with Microservices is actually that IMO most
| developers simply have no time, willingness, experience or
| mental capacity to think critically about all that stuff.
| People frequently need to make decisions _efficiently_. The
| theory of efficient decisionmaking I have is that frequently
| enough it is more important to make a decision than to make a
| perfect decision.
|
| And it kind of makes sense because I also suspect majority of
| the population (and that includes developers) are simply unable
| to think critically or retrospect about their own performance.
|
| And what you do when you have little experience in the field
| and can't yet think critically about things? You use training
| wheels.
|
| In case of IT (and business in general), a powerful training
| wheel is imitation.
|
| So what happens is that somebody at some company will publish a
| paper about how they solved a problem and suddenly a bunch of
| people will try to jump on that bandwagon ("you can't go wrong
| if they succeeded with it") but without the hassle of having to
| actually think through it, understand what were the
| circumstances at that other company, how those circumstances
| are different from own use case, etc. They will imitate what
| others have done before but without realising a lot of
| important things about the problem. Which is how we got to this
| whole microservices mess.
|
| Anyway, I am personally rolling back microservices
| implementations pretty much every project I join. People do not
| realise how much time they spend solving problems that are
| simply due to the fact they have partitioned large application
| into hundreds of small services which need to each be
| maintained separately. We have dedicated teams to do stuff that
| is simply unnecessary (they usually call them "devops", but
| really they are just ops because more frequently than not they
| are not actively developing the functionality). All the
| performance problems, all that inefficiency usually vanishes
| when you roll all that functionality into a single application
| and just scale that one application instance over multiple
| servers.
|
| My current team is even more funny. The microservices were
| originally meant to allow teams to work independently, but at
| my current team they work hard to bind all of the development
| process into a single stream of work. So there is some 80
| people in 10 different teams all working on same set of
| environments, applications, with the same monthly release
| process, coordinating their work everywhere. But there is about
| 1 service maintained for each developer which means people
| spend half the time dealing with complex configuration. And the
| other half of the time figuring out how to improve performance
| of an application which copies all of its data from service to
| service.
| podgorniy wrote:
| Your comment reads like you did not read beyond the title. In
| the article they provide analysis and contexts in which
| microservices are usable. Article does not fit in your
| description of "ignorant" or "completely convinced of one way".
| lolinder wrote:
| > Let's do a 1:1 comparison of microservices and modules.
| Spoiler alert: the argument favors modules, as there is
| little to be said in support of microservices when pitted
| against modules!
|
| This is the introduction to their argument and it definitely
| accurately captures the tone of the rest of the article. As
| for ignorance, you get frequent sections like this:
|
| > With a monolithic architecture, your system is either UP or
| DOWN, with no in-between. With microservices, you need to
| monitor every service. All the services need to be UP, and
| they need to be able to communicate with each other, all for
| you to be able to say the system is UP. If even one out of
| your 888 services is down, the system can no longer be called
| UP!
|
| The author manages to take one of the most compelling uses of
| microservices and turn it into a negative thing. Somehow in
| their mind switching from a model where you're either UP or
| DOWN to a model where you can be partially UP is _worse_ ,
| which suggests to me that they don't have very much
| experience operating either type of architecture. Managing an
| incident during a partial outage is infinitely less stressful
| than managing a complete outage. Whether you can officially
| label the entire system as UP is immaterial in a real ops
| context if the impact of the isolated service that is DOWN is
| minimal.
| solidasparagus wrote:
| In smaller/earlier projects, there may not be such a thing
| as partially up or partially down. Every module/service can
| be on the critical path. And if that's the case, it's
| easier to not be dealing with a distributed system (or to
| have a minimally distributed one).
| lolinder wrote:
| I mean, yeah, don't use microservices if you're in a
| small or early project. That's a totally valid argument
| that I 100% agree with. Microservices solve a specific
| category of problems that you don't have until you reach
| a certain scale (either organizationally or
| operationally).
|
| But again, this is their thesis statement:
|
| > Let's do a 1:1 comparison of microservices and modules.
| Spoiler alert: the argument favors modules, as there is
| little to be said in support of microservices when pitted
| against modules!
|
| Their essay leaves very little room for legitimate
| technical reasons for a service to be split out from the
| monolith. Even their section titled "When Should You
| Consider Using Microservices?" basically boils down to
| "if you already have microservices, if you absolutely
| must use a different language, or if you're an
| irresponsible idiot".
| solidasparagus wrote:
| Oh yeah I'm not gonna defend the article. I was only
| really responding to this line.
|
| > Somehow in their mind switching from a model where
| you're either UP or DOWN to a model where you can be
| partially UP is worse, which suggests to me that they
| don't have very much experience operating either type of
| architecture.
| lolinder wrote:
| Ah, got it. Yeah, I can imagine someone coming to their
| conclusion if the only system they've ever worked with
| doesn't have any major components that aren't on the
| critical path.
| ryandvm wrote:
| Yup. Anybody that doesn't understand that most problems are
| complicated doesn't understand most problems.
| __0x01 wrote:
| The author did provide an exception:
|
| > Unless your specific use case demands the unique advantages
| of microservices, it is wiser to stick with a well-structured
| monolith.
|
| The author also has a section in the article called "When
| should you consider using microservices?".
| _heimdall wrote:
| The only right answer when asked "should we use (X)" is "it
| depends."
|
| I really dislike using react and can easily say off-hand that
| people just shouldn't use it, _but_ that 's because I also
| dislike working on exactly the types of projects that react is
| a good fit for. There's a time and a place for everything, if
| not then why would anyone have bothered to build and maintain
| the thing?
| gilbetron wrote:
| To quote the movie Four Rooms: "The less a man makes
| declarative statements, the less apt he is to look foolish in
| retrospect."
| hackan wrote:
| Yep, this post is awful in many aspects, throwing rants here
| and there w/o ever making a point. I have no idea how this got
| so many upvotes!!.
| lolinder wrote:
| It got upvoted because microservices are currently sliding
| into the trough of disillusionment. It's trendy right now to
| hate on them, and the author is fully on the mindless hate
| bandwagon right along with a lot of HN readers.
|
| In a few years we'll hopefully be out onto the slope of
| enlightenment, with microservices applied where they're
| useful and not applied where they're not. If we don't get
| there, then we'll just run the whole hype cycle over again
| with yet another rebrand of the same concept.
| whack wrote:
| > being completely convinced that one way of doing things is
| always wrong and one way of doing things is always right, and
| that people doing things the other way are just
| ignorant/stupid/wrong
|
| > people who talk/write like this usually have no idea what
| they are talking about
|
| According to your heuristic, you have no idea what you're
| talking about?
|
| In all seriousness though, your comment comes across as
| unnecessarily personal. I disagree with the OP's conclusion,
| but he raises some interesting arguments on an interesting
| topic. I came to the comments to see a technical discussion
| around the pros/cons of microservices. It's off-putting to see
| that the top comment is an ad-hominem attack
| lolinder wrote:
| I think you might have misread OP. The first quote you
| extracted isn't their description of the author, it's their
| description of what the author is conveying in TFA, and
| that's honestly a pretty accurate way to capture the piece.
| TFA's section giving the reasons why you might consider a
| microservice architecture basically boils down to "if you
| already have microservices, if you absolutely must use a
| different language, or if you're an irresponsible idiot".
| That's not the attitude of someone who is open to the idea
| that someone reasonable might make a different choice than
| they would.
|
| What OP _actually_ has to say about the author themselves is
| that people who write like that "usually have no idea what
| they are talking about", which is also absolutely true in
| this case. There are _many_ tells throughout the essay that
| give away that the author has very little experience
| operating any type of system, microservices or otherwise.
| richardfey wrote:
| You are absolutely spot on.
| yanis_t wrote:
| I wish we had more articles not about what good practices are, or
| how things should be designed in theory, but rather about how to
| enforce those practices in a large organization, when you are not
| necessary a guy who makes decisions.
| Joel_Mckay wrote:
| Unfortunately, the "wisdom of the tribe" cannot be written down
| for the laymen.
|
| Most juniors can't look at a design-pattern, and somehow
| immediately understand why it is good or inappropriate.
|
| Almost all recent grads are similar to the following fellow:
|
| https://en.wikipedia.org/wiki/Eddie_the_Eagle
| red_admiral wrote:
| > when you are not necessary a guy who makes decisions
|
| I think a lot of it comes down to: if the guys who do make
| decisions make them badly, stuff is going to suck. You need the
| right people at the top.
| CuriouslyC wrote:
| While I hate the cargo culting of microservices, there is one use
| case they handle very well - reusable services with obnoxious
| dependencies that don't really need to be integrated in with the
| rest of your codebase. I would much rather take a docker image of
| a whisper or text-to-speech service and add it to my compose file
| and call it via HTTP than try to wrestle a CUDA build and get
| whisper/TTS bindings working for every language where I might
| need them.
| mind-blight wrote:
| A similar case for me has been processing large files. It's
| really nice to be able to scale up the memory of the file
| processing server when there are large files being processed,
| they scale it back down for normal usage
| _heimdall wrote:
| Microservices can also be a great fit for certain team/org
| structures. Its not ideal to pick the tech based on the team
| structure, but that's life.
|
| I've also found it micro services helpful for heavy data
| processing projects. A micro service architecture driven by
| events as data is processed and moved through different steps
| can be a surprisingly simple setup to reason about and debug.
| alephxyz wrote:
| The author seems to be assuming that microservices are only used
| to break down a single application into different services, in
| which case their arguments are valid. If you instead consider
| that a single service can in fact be used by multiple
| applications, most of their arguments are plain wrong.
|
| For example: >Why would you ever want to allocate more resources
| to one particular part? It's not like the other parts will eat up
| the extra resources. If your system needs more RAM, it needs more
| RAM. Why would you care about which part needs more RAM?
| icholy wrote:
| There's a benefit of microservices that I don't hear talked
| about. At my workplace, there's absolutely no respect for api
| boundaries. Devs will monkey patch and reach into other module's
| internals without a second thought. I can't imagine the
| monstrosity that would exist if the network boundary wasn't there
| to stop them ...
| duxup wrote:
| Microservices (like a lot of things) might just be there to
| solve human developer problems as much as anything else.
|
| There are times where I'm all "No the authentication service is
| doing great, leave it alone!!!".
| aitchnyu wrote:
| We can enforce module boundaries in code with tooling.
|
| An example for Python: https://github.com/gauge-sh/tach
| NoGravitas wrote:
| That's just another way of saying that microservices don't
| solve a technical problem, they solve an organizational
| problem.
| BillyTheKing wrote:
| yes - and writing code also doesn't solve a technical
| problem, a computer runs fine with 0s and 1s, no need for
| code, in fact code produces a performance overhead - but it
| solves a human abilities problem, namely that 0s and 1s
| aren't particularly expressive for us. Almost everything we
| do solves for communication, some things on an individual
| scale, like programming languages, and other things on an
| organisational scale like micro-services (I'm also not
| blindly advocating for micro-services, but I do get why if
| done somewhat competently it's easier to organise a team of
| 1000 developers into 50 teams of 20 each responsible for one
| service rather than 1000 developers responsible for
| everything)
| kgeist wrote:
| >Devs will monkey patch and reach into other module's internals
| without a second thought. I can't imagine the monstrosity that
| would exist if the network boundary wasn't there to stop them
| ...
|
| We have a tool in our modular monolith, which is like a linter
| which checks architectural violations like that. If someone
| tries to bypass the API layer of a module and peek directly
| into the internals, it refuses to build (and CI/CD refuses to
| deploy/release). No need to replace a basic linter with a
| network boundary...
| 10000truths wrote:
| You don't need network level separation for that, UNIX sockets
| and pipes are just as effective at enforcing those boundaries.
| vilunov wrote:
| What's stopping them from violating network boundaries?
| huygens6363 wrote:
| Microservices are not solving a technical problem. This is
| related to another issue: many technical people think tech is the
| hard part. Technology is the easy part. If you think the tech is
| hard, you have no idea how hard The Rest is. I know it sucks, but
| the sooner you learn this the better.
| twelfthnight wrote:
| So true. Communication is insanely difficult. Hiring competent,
| motivated engineers is insanely difficult. Working around
| short-term thinking executives is insanely difficult. Iterating
| until you stumble on a success product is insanely difficult.
|
| How often does anyone talk about these problems in meetings?
| It's wild, I feel like all I ever do is argue over mostly
| irrelevant technical minutia.
| huygens6363 wrote:
| Exactly! It's this huge elephant in the room and all we want
| to talk about is our editors and how Java is faster than Go
| or whatever.
|
| I'm sitting in this meetings thinking "Guys, using XML or
| JSON truly, truly does not matter here. You have already
| wasted months on this shit and the value meter is still at
| $0. I'm telling you we can make this work with either Scala
| or 6502 assembly or anything in between. What matters is that
| we need a coherent vision, formulate actionable goals and
| work on improving our communication and keeping it there."
|
| Maybe I need to go into management? (/s ?)
| anon64765446 wrote:
| It's almost as if you are describing the meetings in my
| company (and my previous)
|
| I think focusing on technical trivialities is a symptom of
| what type of experience the developers have and how the
| current workplace is organized.
|
| In traditional companies, the developers are at the tail of
| a process that they have limited participation in. Most of
| the product decisions has been done by others and the
| developers often don't have enough contact with the
| business side to make any real impact.
|
| You end up with an isolated group that can only influence
| technical desicions, so that's what they will focus on.
|
| Choosing tech X vs tech Y is actually only 1 choice in a
| long chain of product, design and business choices that has
| led to the Jira ticket. From their point of view, it seems
| like the most important desicion because it is taken out of
| context.
|
| This is where experience is actually a good thing, because
| it increases the chance that you have been exposed to "the
| other side". They will also know that these types of
| decisions are not likely to be the reason why they fail.
|
| By participating from the beginning you also tend to be
| more motivated by outcome. Technical discussions that don't
| have a real impact become less interesting.
| twelfthnight wrote:
| This resonates with me, although I would go a step
| further to say the makeup/experience of the developers is
| a product of the competency of leadership. Most leaders
| wind up in their positions out of pure luck and
| chicanery. I can't tell you how many lay offs I've been
| through where the best people are let go and the worst
| are kept on and unintentionally sabotage the entire
| engineering team.
| twelfthnight wrote:
| I for one would love to have a boss that cares about those
| things.
| hakunin wrote:
| Trying to solve a communication problem with more code and
| infra is often a mistake. This is something many engineers
| don't realize they're essentially doing. Some communication
| problems can be somewhat alleviated by processes and technology
| enforcing those processes, but you must always consider the
| cost, and weigh it against alternatives that don't require
| engineering overhead. In almost every case like this,
| increasing the amount of code and infrastructure is the wrong
| option.
| from-nibly wrote:
| Yes, but Conway is not wrong
| hakunin wrote:
| Yes, but his law is descriptive, not prescriptive. Just
| because it tends to happen doesn't mean it should happen,
| or happens for good reasons.
| gilbetron wrote:
| Not wrong, but also not a Law.
| mattgreenrocks wrote:
| > If you think the tech is hard, you have no idea how hard The
| Rest is.
|
| If people/orgs _really_ believed this, they 'd keep headcount
| as minimal as possible.
| DowagerDave wrote:
| Don't they? The only experience I've had where this isn't the
| case is startup mania, where gasoline is poured over open
| flame.
| mattgreenrocks wrote:
| It really depends on where you work I suspect. Some places
| incentivize having lots of direct reports and hiring can
| outpace the ability to dole out work. Currently some of
| those places seem to be seeing how few developers they
| actually need to keep the lights on. In both cases the
| decision isn't made from a technical POV but more just
| following the current fashions.
| red_admiral wrote:
| I always thought microservices did solve a technical problem,
| but one that only appears when you're the size of Twitter or
| similar. I would agree with you for the huge majority of
| companies that don't build their own datacenters.
| huygens6363 wrote:
| It's an organizational pattern. I've seen it being used at
| very small companies to good effect. It matched their
| (dysfunctional) culture: islands, little communication, etc.
| Working on a monolith together is a nightmare if you hate
| each other.
| zelphirkalt wrote:
| It depends on what kind of tech we are talking about. Making a
| truly good and flexible tech product is truly hard. There will
| always be someone arguing YAGNI at inappropriate moments,
| influencing design negatively in ways, that will usually never
| be overthrown again, because of the additional mindset of not
| wanting rewrites and mindset of not wanting to change a
| (halfassed) working system.
| intelVISA wrote:
| Many vogue tech decisions are over-engineered band-aids for
| organizational dysfunction.
| skwirl wrote:
| There certainly are many cases where microservices are used where
| they are not actually appropriate, but this entire post just
| betrays a lack of experience working in a large monolithic
| codebase with many engineers.
| Octokiddie wrote:
| > Microservices are the Wrong Answer
|
| The author never states the question. This makes it impossible to
| evaluate the answer, which presumably is stated in the title. The
| article would be much stronger with a clear statement of the
| perceived problem that microservices solve and why modules are a
| superior solution.
| DeathArrow wrote:
| Probably the author never worked on large projects that need to
| scale. Almost no one of his objections does make sense. Imagine
| Facebook, Uber, AirbNB, Google as monoliths.
| dave1999x wrote:
| His LinkedIn is on the article. He has 3 years of
| professional/non academic experience so you're highly likely to
| be correct.
| nasmorn wrote:
| OTOH I only know micro services from 5-20 dev teams where they
| made no sense whatsoever.
| netdur wrote:
| got it, I will not build micro services, I will build just
| regular one.
| tombert wrote:
| Honestly I never really understood the hatred that people on HN
| have for microservices. Everyone acts like "OMG THEY'RE SO
| COMPLEX!!!!", but a) that's not unique to microservices, b)
| monoliths aren't somehow immune from this complexity, and c) most
| big systems end up getting pretty complicated regardless of the
| model.
|
| Yes, Kubernetes is a pain in the ass, and libraries getting out
| of sync can be real problem, and distributed systems are
| inherently difficult, but I think that the benefits of something
| like event-sourcing with lots of individual, self-contained, "I
| don't care where this data came from" services outweigh a lot of
| the complaints. It's not like most of us are reinventing Paxos
| every day; we're using well-tested off the shelf components like
| Kafka and Consul and RabbitMQ.
|
| Also, I don't really understand the author's point about
| individual scaling _not_ being a good thing. It can be very hard
| to measure things like memory usages for individual components of
| a huge service; the smaller and more atomic the service is, the
| easier it is to find out how many resources it actually needs.
| With a big ol ' monolith, it seems like people just go off
| intuition (AKA self-righteous guessing).
|
| I dunno, even for home servers, I still basically do the
| microservice model. Maybe I'm weird.
| solidasparagus wrote:
| > I never really understood the hatred that people on HN have
| for microservices.
|
| If you're an early stage company and just trying to ship
| something with a small team, the overhead of microservices
| (testing, deployment, monitoring, platform infra such as k8s,
| etc) can be pretty obnoxious (like an order of magnitude more
| time than the work to actually deliver business value). And
| microservices give you enough rope for one overly clever person
| to hang the whole team, so there are definitely some
| traumatized developers out there.
|
| If you are doing something simple enough, throw it in a single
| docker container and spend your time focused on building
| something useful.
| hubraumhugo wrote:
| This parody sums up the issues with mircoservices very well:
| https://www.youtube.com/watch?v=y8OnoxKotPQ
| c0balt wrote:
| Tbh, the best way to do this is likely the hybrid model adopted
| by, e.g., gitlab rails and Grafana Loki etc.. air usually let's
| the operator select if they want to run as a monolith, service
| with multiple components where some are instanced, and full micro
| service mode.
|
| For small deployments you can just use the monolith and be done
| with a single "service" while you still have the ability to scale
| out for large deployments. This gets even better when they allow
| you to do an in between where one component does A and B while
| only C is handled by micro services.
| nallerooth wrote:
| > Self-confidence is good. On the other hand, too much self-
| confidence means disaster. - His holiness the Dalai Lama
|
| I guess it's true for microservices as well.
| rswskg wrote:
| I lol'd when I got to 'Why would you ever want to allocate more
| resources to one particular part? It's not like the other parts
| will eat up the extra resources. If your system needs more RAM,
| it needs more RAM. Why would you care about which part needs more
| RAM?' and stopped reading.
| didip wrote:
| Microservice design is a solution to scaling up people in a large
| organization.
|
| Regardless what HN people believe, some people like & proficient
| in a few languages that may not match the existing codebase. Eg.
| 50% of the team is Go enthusiasts in a Java/Python shop.
|
| Microservices solve that. If your company is tiny, you don't win
| much using microservices.
| elktown wrote:
| It's also an excellent way to create large organizations due to
| the complexity chain reaction it seems to kick off.
| norman784 wrote:
| I would love the day when WASM + WASI fulfill their promise and
| let us write our modules against an interface so you can easily
| swap the underlying implementation without changing something in
| your app, this way I can care less if I'm running a microservice
| or a module, let that decision to the devops/management team.
| immibis wrote:
| C FFI and machine code already accomplish this. The reasons you
| wouldn't use C FFI and machine code are the same reasons you
| wouldn't use WASI and WASM.
| brunoarueira wrote:
| The main problem with adopting microservices is the hype and many
| times the person who defends it doesn't have enough data! "We'll
| rewrite this into technology X, because this doesn't scale", but
| sometimes anyone measured it, tested or doesn't have a good
| knowledge about. Another common pattern is if a module is buggy,
| you start to listen people screaming that this need to be a
| microservices. My basic thought is to write modules and when non
| core features evolve in such a way that the team needs to be
| splitted, demanding more allocated people, this features needed
| to move somewhere and at that point the projects will benefit!
| rcleveng wrote:
| Separation is a critical part, and that could be modules that
| form a separate microservice, or split off into it's own
| "macroservice", the mechanics are the same.
|
| I've seen many cases where there is a service that does like 3
| things. 2 of them are low importance and one of them super
| critical. A low importance one will have a bug, crash, introduce
| latency regression, etc and take down the critical one.
|
| Time to separate the critical one into it's own deployment to
| isolate and improve reliability.
|
| The other is on trade-offs, super important that every decision
| makes has them, just respect that and realize the answer is often
| "it depends".
| fire_lake wrote:
| The fault tolerance aspect is underplayed here. Different modules
| might have different reliability and uptime requirements. I don't
| want an unreliable module without SLAs running on the same
| instance as something on the critical path for users.
| basfo wrote:
| > Why would you ever want to allocate more resources to one
| particular part? It's not like the other parts will eat up the
| extra resources. If your system needs more RAM, it needs more
| RAM. Why would you care about which part needs more RAM?
|
| Looks like resource isolation and avoiding a non performant piece
| of code to bring your whole system down is overrated.
|
| Just scale vertically! Get a bigger instance!
| rcleveng wrote:
| > Just scale vertically! Get a bigger instance!
|
| That works great until it suddenly and unexpectedly stops
| working.
| kgeist wrote:
| We use a microservice architecture at the company and like
| every second incident is a cascade failure which is actually
| harder to monitor and manage... And having microservices
| doesn't help.
|
| Things like, someone forgot to batch the events when posting
| to the event bus so a large tenant generating many events
| suddenly overflowed RabbitMQ which ran out of memory and
| started blocking producers who are holding DB connections and
| so we're out of DB connections now and the whole thing goes
| down. The only difference is that when it's going down it's
| harder to understand who's calling who in all this mess
| (compared to a single beefy server).
| intelVISA wrote:
| Behold: the distributed monolith.
| steve_adams_86 wrote:
| I've yet to see an article which explores the pros and cons of
| different strategies and demonstrates each with examples rather
| than picks one and insists it's better for arbitrary reasons.
|
| I've used microservices, monoliths, serverless, and other similar
| permutations based around different core architectures (event
| buses, peer to peer, client-server). Some aspects of each were
| awesome. Some weren't. Knowing why and how/when to leverage each
| is far more interesting than demoting or excluding a solution
| because you like another one more.
|
| There are some suspicious ideas in here. "If your system needs
| more RAM, it needs more RAM. Why would you care about which part
| needs more RAM?" I suppose. But what if I only spin up a service
| once per day, and it needs far more ram than the rest of my
| system? I should use those resources for the 23 hours of the day
| that I don't need them and pay for them nonetheless? It I don't
| own my hardware, that's an insane waste of money. Sometimes
| ephemeral services are a huge cost saver even for smaller
| teams... And it isn't strictly due to poor communication. It's a
| legitimate challenge presented by resource and finance
| constraints.
|
| "Microservices introduce a lot of overhead in terms of
| communication latency" - sometimes this is perfectly acceptable.
| Say you have jobs you need done, and sometimes it goes from ten
| at a time to perhaps 100. A monolith would get bogged down
| severely. The client's expectation of having the job done is
| likely not instantaneous if it's something that needs to be sent
| to a queue. In this case, ephemeral job runners make sense. They
| can take on however many jobs they can at once, and if they're
| maxed out, spawn another worker. This does not work well with
| monoliths in my experience. The communication overhead doesn't
| matter here, as it could be worse if the monolith is bogged down
| while working anyway.
|
| There's more I don't agree with, but I don't claim to be a seer
| or anything. Maybe I'm just old and incapable of learning (though
| I do like the module approach as well).
| nijuashi wrote:
| To be frank, this is a terrible advice. I'm certain this person,
| given enough time, will come to the same conclusion as he/she is
| exposed to different projects and organizations.
|
| As many posters here state, there are many instances where
| services _are_ loosely coupled, developed by different team and
| /or at different time, and makes no sense to make into a
| monolith.
|
| As you may not benefit from shoehorning a well-maintained
| monolith into a microservice, the opposite is true.
| rysertio wrote:
| Am I the only one who uses microservices to deploy small
| monolithic projects?
| whack wrote:
| My intuition is that at a certain scale, microservices are
| preferable to a monolith. Two principled reasons:
|
| - Autonomy over deployment rollbacks. If your team owns a
| microservice, and you noticed that you deployed buggy code, you
| can easily and autonomously do a rollback. Your rollback doesn't
| impact other teams. It isn't visible company-wide. This allows
| teams to take more risks with fewer downsides and more
| psychological safety
|
| - Isolation of secrets, api-keys etc. If one module has access to
| an api-key, then it's effectively made visible to every single
| module in the monolith. Other teams can decide to bypass your API
| entirely and read directly from your database, making it
| impossible for you to abstract away your implementation details
|
| Problems solved by microservices that could in theory be solved
| in a monolith:
|
| - Build/test times. A big monolith will have a huge build time
| and a large number of CI/CD tests. In theory you could
| parallelize your build/test-suite to make it infinitely fast, but
| I'm not sure how practical this is
|
| - IDE slowness. A monolith will make your average IDE run much
| more slowly. In theory also solvable, but would require major IDE
| changes and investments
|
| - Code ownership by specific teams. In theory you can use things
| like regex-CODEOWNERs to enforce code-ownership of individual
| modules, but it's easier with microservices
|
| - Migrating to better languages/frameworks. If your original
| monolith was written in perl or on a bad framework, it's very
| hard to move away from it. With microservices, each microservice
| can be independently and incrementally migrated, allowing the
| company's tech stack to evolve gracefully.
|
| Any others I missed?
| lolinder wrote:
| One that I don't think a monolith can solve is partial
| availability.
|
| A monolith is either available or it isn't, which is fine as
| long as you can guarantee that nothing ever takes down the
| monolith, but we all know that that's not something you can
| guarantee.
|
| If you split out services that live outside the critical path,
| then when _those_ services go down you can still engineer your
| system to keep going and gracefully degrade the functionality
| provided by those currently-down services.
|
| This makes incident response much less stressful because
| there's less urgency, which in turn leads to fewer mistakes
| during the response and faster recovery times.
|
| (Yes, there are some pieces of functionality that will always
| be in the critical path, like authorization, but many things
| don't have to be.)
| intelVISA wrote:
| Modulith is the underrated happy middle ground imo.
| elktown wrote:
| Not sure if there's any other profession than software that has
| such a hard time with proportionality. We can seemingly with a
| perfectly straight face argue that yes this massive Rube Goldberg
| machine was required to avoid that small nuisance that feels
| wrong but actually isn't something that consumes time at all.
|
| Imagine if a carpenter or plumber acted like this; having self-
| fulfillment as prio 1, 2, 3 in all cases, not outcome. They'd
| never get hired again.
___________________________________________________________________
(page generated 2024-05-24 23:02 UTC)