[HN Gopher] Microservices: Why Are We Doing This?
___________________________________________________________________
Microservices: Why Are We Doing This?
Author : htunnicliff
Score : 102 points
Date : 2022-03-21 19:38 UTC (3 hours ago)
(HTM) web link (michaeldehaan.substack.com)
(TXT) w3m dump (michaeldehaan.substack.com)
| blawson wrote:
| I wonder how much of this can be traced back to the proliferation
| of System Design interview stages, and resulting training
| material?
|
| From my experience all of these resources tend to direct you to
| think in microservices / uber-distributed architectures. I can
| easily imagine this causing folks to consider this as "the way we
| do systems now" and taking it to extremes.
|
| The low barrier as well for 1 engineer to decide they want to
| just get busy on a weekend on their own and build something is
| another way I've seen this proliferate.
| Nextgrid wrote:
| The reason why "we" are doing this is because in a lot of cases,
| the tech is no longer used as a means to solve a business problem
| - instead, the tech is the end-game itself and complexity is a
| desired _feature_.
|
| The market has been distorted by endless amounts of VC funding
| for very dubious ideas that would never be profitable to begin
| with, so now you have 2 solutions: you can spend a few hundred
| grand building a boring solution with a slim amount of engineers,
| realize it doesn't work and quit, or you can keep over-
| engineering indefinitely, keep raising more and more millions,
| enjoying the "startup founder" lifestyle while providing careers
| to unreasonable amounts of engineers with no end in sight because
| you're too busy over-engineering rather than "solving" the
| business problem, so the realization that the business isn't
| viable never actually comes.
|
| Which one do you pick? The market currently rewards the second
| option for all parties involved, so it's become the default
| choice. Worse, it's been going on long enough that a lot of
| people in the industry consider this normal and don't know any
| other way.
|
| I've commented/ranted about this before, see
| https://news.ycombinator.com/item?id=30008257,
| https://news.ycombinator.com/item?id=24926060 and
| https://news.ycombinator.com/item?id=30272588.
| Zababa wrote:
| That was an interesting insight that I haven't read before,
| thank you for sharing that.
| fdgsdfogijq wrote:
| I hate to tell you, but new technologies like react and
| microservices are very useful. Top tech companies regularly
| design whole systems using microservices. Its the legacy
| companies with legacy tech stacks that fail at it.
| Nextgrid wrote:
| I've never said that those technologies or processes have no
| use at all.
|
| However, in a lot of cases they could be considered premature
| optimisation.
|
| A bulldozer is also a useful tool, but in the real world
| nobody uses one for small jobs better suited to a shovel
| because of how expensive it is.
|
| In the tech industry however, VCs will be happy to bankroll
| the bulldozer for you so that it becomes cheaper than using
| the shovel. All else being equal, I too will pick the
| bulldozer at least as long as I'm not the one doing the
| maintenance it will inevitably require.
|
| Worse, give it enough time and the skill to use shovels will
| disappear, and now everyone will be using bulldozers for even
| the smallest jobs, with all the negative externalities
| attached to them. The only winners are the bulldozer
| manufacturers.
| yakshaving_jgt wrote:
| New? Are you sure?
|
| React is about a decade old.
|
| Microservices is between two and _seven_ decades old,
| depending on your definition.
|
| None of this stuff is _new_.
| fdgsdfogijq wrote:
| This is a good point. But actually, I would argue that
| people against these technologies still claim they are
| "new".
| amackera wrote:
| This take seems to be predicated on the idea that VCs are out
| there funding teams just because of the technical complexity of
| their codebase? This just doesn't seem like the reality to me.
|
| If it can be done better for cheaper, VCs will tend to fund
| that team.
| rwmj wrote:
| _> If it can be done better for cheaper, VCs will tend to
| fund that team._
|
| That might be true if there was a shortage of VC money so
| they had to choose their investments very carefully. The
| reality is there's a huge amount of money sloshing around
| with few good investment opportunities.
| vinyl7 wrote:
| I guess the question is then, would VCs give money to
| startups who say "We're using JQuery and PHP" or to startups
| who say something like "We're leveraging AI and machine
| learning to deliver product via MERN stack ontop of AWS to
| give us web scale architecture"
| Spivak wrote:
| I think this is a really warped view of VC funding who
| sorta kinda in a passing sense care about the tech stack
| but where the focus is almost entirely on the business
| side. I was at a company that bought a tiny little
| (originally) VC funded shop that actually was maybe 1K
| lines of PHP _total_. The secret sauce was they found a
| desperately underserved market that just needed _something_
| to collect and organize data between unconnected parties
| that took hours to do manually. Damn thing sold itself
| because it cost nothing to run, had essentially no
| maintenance costs, and _made_ their users about 10k
| /user/mo from the hours it bought them back.
| Nextgrid wrote:
| Businesses like the ones you speak of are gems in a sea
| of crap. They exist, and in that case tech stack
| definitely isn't important.
|
| But for the rest of the "crap", AI- & blockchain-powered
| crap is more shiny than other, more boring crap, at which
| point the tech stack might be more important.
| bcrosby95 wrote:
| Do VCs care or even know about tech stack a startup
| uses/intends to use?
|
| AI and ML is one thing - it can mean a product that
| couldn't exist without it. There's nothing about MERN vs
| PHP that indicates that though.
| mst wrote:
| I remember quite some years (somewhere between a decade
| and a decade and a half) ago having to do some truly
| horrific things to make things work on AWS that would've
| been trivial and far cheaper at the time if we'd just
| bought a decent server and stuck it in a colo somewhere -
| specifically because my customer's investors were all-in
| on AWS as the only possible way to do things.
|
| I'd note that today putting that workload on AWS would
| probably be a pretty pleasant experience - but yeah,
| sometimes investors absolutely -do- care in ways that
| you'd really rather they didn't and you just have to suck
| it up.
| Ekaros wrote:
| Do they pick up cheaper solutions, or the faster and bigger
| aiming with more marketable pitch?
| Nextgrid wrote:
| More marketability definitely helps with passing it on to
| the next sucker, so it's a valuable feature that shouldn't
| be overlooked. The next VC is likely to be more interested
| in the first AI- & blockchain-powered application running
| on AWS InfiniDash than boring Rails on Heroku & Postgres.
|
| Cheaper solutions would be a good pick for something that
| has a very good chance of success and thus doesn't need a
| "next sucker" nor media attention, but those are very rare
| as typically it would be bootstrapped and not involve VC to
| begin with.
| mst wrote:
| My mental model: The VC model is about making a spread of
| bets where at least one of them will produce a huge return,
| so the average investment will be in a company that's
| irrationally overambitious.
| phpnode wrote:
| I think this is a bit naive. Startup founders do not care about
| providing careers for engineers, and usually want to stop being
| a "startup founder" as soon as they possibly can - they are
| chasing huge exits and being a founder is incredibly stressful.
|
| The real reason that microservices are so prevalent is that
| they became fashionable, for exactly the same reason a
| particular item or brand of clothing becomes fashionable -
| influential people were seen using them and so regular people
| aspired to start using them too. At a certain point in the
| popularity curve, _not_ using microservices becomes a
| controversial viewpoint.
|
| They also suffer from what I call "conceptual crack". There is
| a certain kind of idea that really tickles some kinds of
| engineer's brains. Microservices seem like a such a clean
| solution, each service having its own single responsibility, so
| easy to draw on a whiteboard, so neat and tidy. Other ideas I
| place in this category are blockchain, redux, and V=f(s). Clean
| and tidy ideas that are compelling conceptually but result in
| nightmarish levels of hidden complexity when they're put into
| practice.
| michaelt wrote:
| _> Startup founders do not care about providing careers for
| engineers, and usually want to stop being a "startup
| founder" as soon as they possibly can - they are chasing huge
| exits and being a founder is incredibly stressful._
|
| Imagine you were the founder of a business you've now
| realised... isn't going to be the next Google.
|
| Your product hasn't failed! By some metrics it's very
| successful! You've got investors who value your company at
| $10 billion, and they're ready to loan you $1 billion.
|
| But also, you've never made a profit, you've tried the most
| likely routes to profitability without success, similar
| businesses have suffered sudden implosions, and you'd have
| gone bankrupt years ago if it weren't for the fact there's
| chumps who'll work for you for free. You've got no plan for
| how to pay back that $1 billion.
|
| But so long as you keep your mouth shut about that last
| paragraph, and accept the $1 billion? You get a high-status
| job, a thousand-person empire, and a fat compensation
| package.
|
| Why would anyone climb off that gravy train?
| philosopher1234 wrote:
| >they are chasing huge exits and being a founder is
| incredibly stressful.
|
| Are they really? I think they're workaholics chasing an
| escape. True success is the worst outcome they could imagine,
| because then they'd have to tend to the rest of their life.
| Why be a serial founder, if its so horrible and stressful?
| Why keep working yourself to death after your first $10M,
| $100M, or $1B? Why is it never enough?
|
| People have self-destructive instincts that are disguised in
| socially acceptable (or worse, praised!) forms. We shouldn't
| ignore the actions of founders when trying to make sense of
| their words.
| metadat wrote:
| What is V=f(s) ?
| phpnode wrote:
| View = Function(State), the original idea behind React. I
| use React every day, and I enjoy it, but it hides
| nightmarish complexity to preserve a semblance of this
| original, neat and tidy idea.
| [deleted]
| Nextgrid wrote:
| Startup founders don't care about providing careers per-se,
| but they care about the clout and connections that comes from
| founding a company with 100+ engineers mentioned at every
| cloud provider's conference as opposed to a scrappy garage
| with 3 greybeards hacking away Perl code running on rusty
| bare-metal.
|
| CTOs and engineering managers care about their own visibility
| at said cloud provider's conference so it gives them bonus
| points for their next gig.
|
| Individual contributors want to take the place of the
| aforementioned engineering manager/CTO so they'll double-down
| and learn the current stack and "best practices". They may
| not even be aware that there's any other way or how
| unefficient it is, as they've _started_ their career during
| this madness.
|
| If any of those people have stock options, keeping low and
| going with the flow is a sensible strategy if they don't want
| to lose them by getting pushed out for speaking against the
| groupthink.
|
| There's rarely explicit malice involved at any specific stage
| - it's a market-level problem. The music will stop at some
| point though and we'll see a readjustment.
| goodpoint wrote:
| > providing careers to unreasonable amounts of engineers with
| no end in sight because you're too busy over-engineering
|
| This is so spot on. The amount of unnecessary complexity is
| becoming ridiculous.
| preseinger wrote:
| This form of nihilistic cynicism is so dull because it's non-
| falsifiable.
| javajosh wrote:
| Generally agree, but it's not cynicism, it's pessimism.
| Specifically about human nature - e.g. that people will
| encourage complexity simply to protect their jobs. I think,
| at worst, people will NOT make an extra effort to reduce
| complexity. A sin, but a small one in the scheme of things.
| Gigachad wrote:
| I don't think any programmers are worried about job
| security right now. But I would say that having advanced
| and shiny tech is a very compelling feature to a job. I'm
| seeing generic Wordpress/php agencies really struggle to
| retain developers because no one wants to work on wordpress
| or php because it's not a long term career. So places which
| do the exact same websites in Rails and React are doing
| better because even though wordpress might be faster and
| easier, you have to pay people more than you would if you
| have cool tech.
| javajosh wrote:
| I feel like we're on the brink of nuclear war, and I'm
| thinking about asymptotic behavior of webapp stacks...and
| I'm okay with that!
|
| I would guess that both PHP and Rails/React (and Java,
| C#, Python) folk will have all the work they can stomach,
| if they can stomach it. Consider how in-demand COBOL
| programmers are these days!
| Nextgrid wrote:
| I don't believe it's malice per-se. The market sets the
| tone and everyone has to follow or be left behind. I've
| mentioned this in another comment:
| https://news.ycombinator.com/item?id=30760146
| philosopher1234 wrote:
| Falsifiability doesn't govern truth.
|
| If I claim you felt angry when typing this, can I falsify it?
| yakak wrote:
| It is time intensive but not particularly hard to collect
| data from job postings and types of exits start-ups
| eventually make. I find it hard to get a good quick
| estimation since it is hard not to think of key examples that
| fit my personal expectations.
| smegsicle wrote:
| it's nihilistic if you find meaning in microservices, and
| cynical if you don't think there's a weird tech VC bubble..
| throwaway894345 wrote:
| I think it's pretty absurd that you could in/validate many
| startup hypotheses with only a few hundred grand. You can
| _maybe_ pay for two engineers (plus overhead) working for a
| year for that price, but you 'll also need someone to do
| your accounting, legal, product, etc work.
| thinkharderdev wrote:
| To me the core point is just that all access to persistent data
| should be mediated through a service interface which implements
| access controls and restricts what operations available in the
| underlying data store are exposed to other clients. Whether that
| qualifies as a "micro service" seems like mostly just a semantic
| game.
| nawgz wrote:
| This really reads like a bad-faith interpretation of
| microservices. Of course microservices suck whenever someone
| starts a new one to do something that shares code or logic with
| already existing services. Likewise, of course monoliths suck
| when people just willy nilly add code and modules for each thing;
| low quality programming is low quality regardless of where it
| lives
|
| Real microservices implementations don't deliver so much from the
| proposed statement about synchronous web-tier request handling vs
| asynchronous compute workers in my experience. A few easy rules
| to guide this development are even touched on in the article, but
| treated like they could only ever be a tenet of monoliths.
|
| Very strange.
| bob1029 wrote:
| Honestly, we originally did microservices because it sounded like
| a fun idea and because it would look really cool in our marketing
| materials. At the time, this was a very shiny new word that even
| our non-tech customers were dazzled by.
|
| As oxidation and reality set in, we realized the shiny thing was
| actually a horrific distraction from our underlying business
| needs. We lost 2 important customers because we were playing type
| checking games across JSON wire protocols instead of doing actual
| work. Why spend all that money for an expensive workstation if
| you are going to do all the basic bullshit in your own brain?
|
| We are now back into a monolithic software stack. We also use a
| monorepo, which is an obvious pairing with this grain. Some days
| we joke as a team about the days where we'd have to go check for
| issues or API contract mismatches on 9+ repositories. Now, when
| someone says "Issue/PR #12842" or provides a commit hash, we know
| precisely what that means and where to go to deal with it.
|
| Monolithic software is better in literally every way if you can
| figure out how to work together as a team on a shared codebase.
| Absolutely no software product should start as a distributed
| cloud special. You wait until it becomes essential _to the
| business_ and even then, only consider it with intense disdain as
| a technology expert.
| ejb999 wrote:
| Couldn't agree more - just like NoSQL vs regular old SQL -
| don't assume you need a NoSQL solution, until you actually
| prove you need it. probably 90-97% of solutions will be better
| off with a relational database; boring yes, but they 'just
| work'. Choose NoSQL only when you need them, choose micro
| services the same way.
|
| If you 'think' you need NoSQL or a MicroService architecture -
| chances are you don't.
| CraigJPerry wrote:
| >> A Technical Solution To A People Problem
|
| I think the author has correctly identified the reason but the
| given explaination is wildly off base. There's a much better
| answer to this and interestingly it predates the term
| "microservice" by around 40 years!
|
| In 1968 the Conway, Melvin E. had his paper "How Do Committes
| Invent?" published, you can read it here:
| https://www.melconway.com/Home/pdf/committees.pdf (since the
| article author mentions Waterfall which also has an excellent
| paper behind it; this one, like that, is super readable and
| accessible).
|
| TL;DR "organizations which design systems (in the broad sense
| used here) are constrained to produce designs which are copies of
| the communication structures of these organizations"
| hoob0y wrote:
| glouwbug wrote:
| The last microservice architecture I worked on consisted of 7
| python repositories that shared one "standard library"
| repository. Something as simple as adding an additional argument
| to a function required a PR to 7 repos and sign off on each. When
| it came to release we had to do a mass docker swarm restart and
| spin up because the giant entanglement of micro-services was
| really just a monolithic uncontrolled Cthulhu in disguise.
|
| The business revolved around filling out a form and PDF
| generations of said form. I felt like I got no work done in a
| year and so I left
| abledon wrote:
| but boy could your pdf generator system scale. Boy could it
| scale...
| umpalumpaaa wrote:
| Have you considered not sharing code between services?
| glouwbug wrote:
| Yes, I came to learn that microservices would probably
| greatly excel at sending JSON strings back and forth. Then I
| wondered why we weren't just all using Erlang
| abledon wrote:
| One upside in dealing with this mess(and understanding all the
| intricacies, pains etc..) were in is being able to laugh at the
| kafkaesque situations people find themselves in now, like your
| story or other blogposts.
| root_axis wrote:
| > _I worked on consisted of 7 python repositories that shared
| one "standard library" repository. Something as simple as
| adding an additional argument to a function required a PR to 7
| repos and sign off on each_
|
| This is an engineering process failure, not a failure of
| microservices or shared dependencies. You should be versioning
| your shared library, that way you only need to make a
| deployment to the service that requires the update, leaving the
| others pegged at the previous version until a business or
| engineering need motivates the upgrade.
| paskozdilar wrote:
| While we're at the topic of engineering process failures - is
| there any research/literature about software engineering in
| general that describes all the hows and whys of large-scale
| programming like that?
| pkulak wrote:
| So... you worked on something terrible that people called a
| "microservice architecture"? Once a pattern gets popular,
| people start writing nasty code in the style, and then the
| pattern takes the reputation hit and people move on to the next
| thing (or just back to the last thing). Rinse, repeat.
|
| My company uses microservices; deploys restart one service and
| PRs are one repo at a time. There's a shared library, but it's
| versioned and there's nothing compelling you to keep on the
| bleeding edge.
| jmchuster wrote:
| Is this something a lot of people are missing with their
| microservice implementation? You need to be able to deploy
| each microservice independently of everyone else. If you have
| a change that's spread across multiple services, you should
| be able to just do them one-by-one in order. If you want to
| rollout a shared library, you should be able to just update
| your services one-by-one. If a coordinated rollout is
| required, then doesn't that kind of defeat the whole point of
| doing microservices?
| paskozdilar wrote:
| I have had similar experience building microservices that used
| shared repositories. The PR paperwork was so bad that at one
| point I've made all my services self-contained, just to avoid
| having to modify my own code in two different places and
| synchronize the changes.
|
| The whole problem, I think, comes from the "split the code"
| cargo-cult. We need to think about _why_ we 're splitting the
| code, and use that _why_ to figure out _when_ to split code.
|
| IMHO, code separation arises naturally from modular programming
| - once your code is mature enough, it becomes just a piece of
| glue around a set of libraries that you can just rip out and
| put in their own repos, provided that they're useful enough.
| sarks_nz wrote:
| I found microservices had the benefit of increasing release
| cadence and decreasing merge conflicts.
|
| Are there complications? Sure. Are they manageable? Relatively
| easily with correct tooling. Do microservices (with container
| management) allow you better use of your expensive cloud
| resources? That was our experience, and a primary motivator.
|
| I also feel they increase developer autonomy, which is very
| valuable IMO.
| BackBlast wrote:
| What is "correct tooling"? I haven't found anything that's
| remotely close to providing a nice stack trace, for example.
| How "micro" are your services? Can it manage to stand up a
| local dev environment? How do you deal with service interface
| versioning? Is this great tooling vendor tied?
| thebean11 wrote:
| The stack trace bit is hard. For local development, ideally
| there's some fancy service discovery where your local service
| can hit a development instance of another service if you
| don't have a version running locally.
| usefulcat wrote:
| If a merge conflict occurs, I'd much rather hear about it from
| git instead as opposed to some obscure breakage later in
| testing or production.
| dgritsko wrote:
| I agree. I think organizational scalability is an important
| benefit of microservices that doesn't always come up in these
| discussions. Having smaller, more focused services (and
| repositories) allows your organization to scale up to dozens or
| hundreds of developers in a way that just wouldn't be practical
| with a monolithic application, at least in my experience (I'm
| sure there are exceptions).
| mirekrusin wrote:
| Decreasing merge conflicts sounds more like muting and/or
| deferring problems.
|
| Microservice fanaticism seems to be coupled with this
| psychosclerotic view that world can exist in state of
| microservices or as monolith.
|
| From what I've seen in last 20+ years, if I had to pick one
| sentence to describe fit-all enterprise setup (and it's as
| stupid as saying "X is the best" without context) - it'd be
| monorepo with a dozen or two services, shared libraries, typed
| so refactoring and changes are reliable and fast, single
| versioned, deployed at once, using single database in most
| cases - one setup like this per-up-to-12 devs team. Multiple
| teams like this with coordinated backward compatibility on
| interfaces where they interact.
| monocasa wrote:
| 20% legitimate Conway's law concerns, and 80% cargo culting other
| orgs' Conway's law concerns in an effort to feel like you're a
| big boy org with big boy org problems.
| Philip-J-Fry wrote:
| I'm part of a team that is slowly breaking down our systems into
| microservices. Our old monoliths were a pain to maintain, the
| pain comes from overengineering rather than being a monolith. I
| don't fully buy that our business is better now because we use
| microservices. It just works well for us now that most of the
| business is moving to a new language.
|
| We managed to write more performant code even though we're
| calling off to 10+ services each request. Did microservices make
| our applications faster? Of course not, but they clearly exposed
| the issues with our monoliths. We could make the same
| applications even faster if we moved back to a monolith, but the
| worry is when does it get back to the state we were in before?
|
| It was not uncommon to have multiple pieces of code calling into
| the database to grab the same data in our monoliths. The fact is
| that it's way too easy to just DI a service where it doesn't need
| to be and boom, a pointless DB call. Do it in a few more places,
| add a bit of a spiderweb here and there, and you've just
| amplified the number of database requests doing the same thing.
| Yes, a lot of this comes down to fundamental issues with the
| architecture of the applications, things that have been stacked
| over years and years of tech debt. It's not an issue with a
| monolith, but rather how developers often treat them. There's a
| sense that everything is on the table because it's all in the
| same code base. A lot of developers don't care to think of the
| future implications of injecting a service where it doesn't
| belong, it does what they were asked and the person reviewing it
| thinks the same.
|
| With microservices it feels like the decisions and behaviour of
| them are more public and there's more eyes seeing what they're
| doing. If someone is doing something weird, it's easier to call
| out since these interfaces are public. Previously all the shit
| code got hidden in random pull requests. Now the shit decisions
| are out in the open. Everyone is interacting with the same
| microservices, a shit API is shit for everyone, a slow service
| slows everyone else's services down, people seem to care more and
| make better decisions. There's still those guys who just don't
| give a shit and make a microservice into a macroservice. But when
| that happens it's easier to see now, it's in our faces, it's not
| 500 lines of code hidden in a library, it's easier to call out.
|
| As time goes on I do long for a monolith again because personally
| I've learnt a lot from breaking down our systems into
| microservices. I know what touches what, I know what shouldn't
| touch what. The domain knowledge gained from this project would
| indefinitely lead to a better engineered monolith. But at the end
| of the day, microservices force these decisions into the open and
| less architectural mistakes are being made, which is good.
|
| This is also a big reason why I'm a fan of Elixir/Erlang, you're
| almost forced to think in microservices and that leads to better
| decisions.
|
| One mistake I think a lot of people make is creating a web of
| microservices. You want to keep the hierarchy as flat as possible
| so that each microservice is entirely independent of another.
| When you want to actually do work, you write an orchestrator that
| calls into each of these services to carry out the work. This
| orchestrator is not a consumable service, it's console app, it's
| a website, it's a product.
| eandre wrote:
| Whether you build microservices or just services, distributed
| systems are undeniably here to stay. In today's world there are
| very few products that can run on a single machine, whether it is
| for latency or availability or redundancy.
|
| That said, the challenges of building such systems are real, and
| the developer experience is universally quite awful compared to
| our monolithic, single-server past.
|
| It's for that reason that I've been building [1] for the past
| four years. Would love your feedback if the OP resonates with
| you.
|
| [1] https://encore.dev
| TameAntelope wrote:
| Some people just like to be countercultural for the sake of it,
| and apparently the author is one of those people. Is there a word
| for reverse cargo culting? Cargo hipstering?
|
| Not the apt, "The cargo is from a plane!" but rather, "We never
| needed any of these supplies to begin with! We were better off
| starving!"
|
| It's wholly unsurprising that the next series of topics the
| author plans to discuss are mental health. That makes _perfect_
| sense, given the rest of the article.
| tiberriver256 wrote:
| I really like the way Uncle Bob described Microservices in this
| article: https://blog.cleancoder.com/uncle-
| bob/2014/10/01/CleanMicros...
|
| He made the point that micro-services are a deployment method not
| an architecture. A good clean architecture shouldn't care how
| it's deployed. If you need to move from plugins to micro-services
| to be massively scalable your architecture shouldn't care. If you
| need to move from micro-services to plugins to make your app
| simple to host and debug, your architecture should also not care.
|
| This strategy has been implemented in frameworks like abp.io very
| successfully. You can start your application as a single
| collection of split assemblies deployed as a single application
| and move to deploying as micro-services when it's necessary.
| mirekrusin wrote:
| Also linked from that article [0] [1]
|
| [0]
| https://www.linkedin.com/pulse/20140604121818-6461201-seven-...
| (I think that's it, original link doesn't work anymore, this
| looks like a copy of it)
|
| [1] http://highscalability.com/blog/2014/4/8/microservices-
| not-a...
| master_yoda_1 wrote:
| I somewhat disagree with this article. Microservice is great for
| complex software modules. But some jokers in industry starts
| writing miscroservice for every small function/method in the
| code. It's better that microservice should be designed by
| experts.
| dastbe wrote:
| > If we think about resilient systems, the most resilient systems
| are the ones with the least number of moving parts. The same is
| true for the fastest systems.
|
| in some sense yes, in some sense no. a monolith with a denial of
| service vector in part of its functionality can suddenly take
| down your entire fleet because everything was exactly the same.
|
| in much the same that domestic bananas are more or less one
| virus/bacteria away from being wiped out (again), a monolith very
| susceptible to any kind of correlated failure because the blast
| radius is most likely the entire monolith.
| goodpoint wrote:
| > a monolith with a denial of service vector in part of its
| functionality can suddenly take down your entire fleet because
| everything was exactly the same.
|
| Just like a microservice can bring down the core functions of
| your service because a single component locks up under DoS
| zwieback wrote:
| If you're going to complain about something you need to present
| some data that backs up your point, this is just a bunch or
| rambling opinions.
|
| A lot of software engineering is about managing modularization,
| I've lived through structured programming, OOx, various
| distributed object schemes and now this. Basically all these
| mechanisms attempt to solve the problem of modularization and
| reuse. So, the fact that new solutions to the old problems appear
| just means that it's a hard problem worth working on. I'd say use
| every single technique when it's appropriate.
| vlunkr wrote:
| From the article: """
|
| If we think about the fastest way to execute some code, that is
| a function call, not a web request.
|
| If we think about the best way to make sure we detect problems
| at compile time, that is by using a library at a compiled
| language.
|
| If we think about the best way to understand why something
| failed, that is a full stack trace.
|
| If we think about resilient systems, the most resilient systems
| are the ones with the least number of moving parts. The same is
| true for the fastest systems.
|
| If we think about deployment and management and upgrades, the
| simplest systems to deploy and maintain also have the least
| number of moving parts. """
|
| You don't really need any data to back this up, it's all self-
| evident.
| edgyquant wrote:
| I see a lot of people acting like microservices are some
| conspiracy theory pushed on us engineers. I've never worked
| anywhere that pushed microservices, the places I've used them
| they tended to be additional functionality we could easily
| decouple from the standard backend. Even if they were I like the
| idea of microservices, having everything as abstracted away from
| each other as possible. Also would probably make code easier to
| onboard, just get a junior up to speed on one service at a time.
| paxys wrote:
| Incompetent teams and engineering organizations will find a way
| to mess up both monoliths and microservices. Great ones will pick
| what works best for their specific use case and be effective at
| it.
|
| The only correct answer is to not waste time with the decade+
| worth of pointless internet debates on the topic.
| simonw wrote:
| If you're going to embrace microservices, you need to be VERY
| confident that they solve real problems that you currently have
| and that they will result in an improvement to your engineering
| velocity within a reasonable time-frame.
|
| The additional complexity - in terms of code and operations - is
| significant. You need to be very confident that it's going to pay
| for itself.
| throwaway984393 wrote:
| If you don't really understand how they work, you get blog posts
| like this. Microservices add many design benefits that prioritize
| rapid independent work. Monoliths add many design benefits that
| prioritize simplification and tight integration, testing and
| releasing. Both exist for good reasons, and both have to be
| implemented properly. _Neither of them is a silver bullet._
|
| But the real reason we use microservices is they're just more
| popular. Nobody wants to recommend something obscure or old for
| fear they'll be laughed out of the office. Nobody can hire tech
| people to work on 'uncool' technology. People like to follow
| trends. That's why we are doing this.
| commandlinefan wrote:
| > teams want to make their own choices, dislike code review or
| overbearing 'architects' above them, and to a lesser extent want
| to use different and newer languages.
|
| I'm not sure this is 100% correct - or, at least, has never been
| the case in the 20 years or so I've been working with
| "microservice" architectures. There's always an architecture team
| dictating the form of the services themselves - usually much more
| so than a module in a monolithic application. Part of this
| standardization is usually a set of languages - you can use
| Python (with Django) or Java (with Spring Boot), but anything
| else has to be approved by the committee.
|
| That said, I agree with is ultimate conclusion that microservices
| haven't lived up to their promise. The usual justification for
| microservices was and continues to be "we can update one
| component without disturbing the others". I've never seen that
| actually happen. Every time one component changes, everything
| that depends on it has to be retested just to be on the safe side
| (and most of the time, something is found).
| pintxo wrote:
| Well, if you don't have tests to ensure a service adheres to
| it's original promises, then yes, you'll need to run the full
| integrated system (I would probably do it anyway, depending on
| the context).
|
| Reminds me of the fun time a major financial institution had
| one of their internal services provide fully 6 historical
| versions of it's api. Interestingly, they had not a single
| (automated) test for any of these.
| tootie wrote:
| > A Technical Solution To A People Problem
|
| I spend like 98% of my time dealing with people problems. I will
| trade technical optimization for communication optimization every
| single time.
| Jtsummers wrote:
| > If we think about the fastest way to execute some code, that is
| a function call, not a web request.
|
| No, the fastest way to execute some code is a goto. Be careful
| with arguments from performance, that's how you get garbage like
| a former colleague's monstrous 10k SLOC C(++) function (compiled
| as C++, but it was really C with C++'s IO routines). Complete
| with a _while(1)_ loop that wrapped almost the entire function
| body. When you need speed, design for speed, but you almost
| always need clarity first. Optimizations can follow.
|
| > If we think about resilient systems, the most resilient systems
| are the ones with the least number of moving parts. The same is
| true for the fastest systems.
|
| I suggest care with this argument as well. This would, naively
| interpreted, suggest that the most resilient system has 1 moving
| part (0 if we allow for not creating a system altogether). First,
| this is one of those things that doesn't have a clean
| monotonically increasing/decreasing curve to it. Adding a moving
| part doesn't automatically make it less resilient, and removing
| one doesn't automatically make it more resilient. There is a
| balance to be struck somewhere between 1 (probably a useless
| system, like _leftpad_ ) and millions. Second, there's a factor
| not discussed: It's the interaction points, not the number of
| moving parts themselves, that provides a stronger impact on
| resilience.
|
| If you have 500 "moving parts" that are linearly connected
| (A->B->C->D->...), sure it's complicated but it's
| "straightforward". If something breaks you can trace through it
| and see which step received the wrong thing, and work backwards
| to see which prior step was the cause. If you have 500 moving
| parts that are all connected to each other then you have
| 500(500-1)/2 interactions that could be causing problems. _That
| 's_ the way to destroy resilience, not the number of moving parts
| but the complex interaction between them.
| duped wrote:
| Stop talking about how inappropriate microservices are for
| applications that will never scale, they're a goldmine for
| consultants contracting with "CIOs" that every middling sized
| company decided they needed because they heard about ransomeware
| on Fox News. Billable hours out the wazoo, converting totally
| reasonable monoliths into microservices that can't be maintained
| by the clients and will always go over time and over budget.
| jedberg wrote:
| I'm a huge proponent of microservices, having worked on one of
| the earliest and largest ones in the cloud. And I absolutely
| think that they provide huge advantages to large companies --
| smaller teams, easier releases, independently scaling, separation
| of concerns, a different security posture that I personally think
| is easier to secure, and so on.
|
| It's not a surprise that most younger large enterprises use
| microservices, with Google being a notable exception. Google
| however has spent 10s, possibly 100s of millions of dollars on
| building tooling to make that possible (possibly even more than a
| billion dollars!).
|
| All that being said, every startup I advise I tell them don't do
| microservices at the start. Build your monolith with clean hard
| edges between modules and functions so that it will be easier
| later, but build a monolith until you get big enough that
| microservices is actually a win.
| foobarian wrote:
| > Build your monolith with clean hard edges between modules and
| functions so that it will be easier later,
|
| This is unfortunately very easy to override. Oh the rants I
| could write. If I could go back in time we would've put in a
| ton of extra linting steps to prevent people casually turning
| private things public* and tying dependencies across the stack.
| The worst is when someone lets loose a junior dev who finds a
| bunch of similar looking code in unrelated modules and decides
| it needs to be DRY. And of course nobody will say no because it
| contradicts dogma. Oh and the shit that ended up in the
| cookies... still suffering it a decade later.
|
| *This is a lot better with [micro]services but now the code
| cowboys talk you into letting them connect directly to your DB.
| vsareto wrote:
| I saw lots of churn working on microservices that were pre-
| production. When it's like this, things are more tightly
| coupled than the microservice concept would have you believe
| and that causes additional work. Instead of writing a new
| function at a higher version, you had to go change existing
| ones - pretty much the same workflow as a monolith but now in
| separate code bases. And there wasn't a need for any of these
| microservices to go to production before the front end product,
| so we couldn't start incrementing the versioning for the API
| endpoints to avoid changing existing functions. A monolith
| almost doesn't need API versioning for itself (usually
| libraries do that), but it's effectively a version 1.0 contract
| if translated to microservices.
| antihero wrote:
| Why would you advocate for microservices over services?
| eweise wrote:
| What's the difference?
| jedberg wrote:
| I grew up using unix where the philosophy is "do one thing
| and do it well" and I think that carries over well into
| microservices.
|
| But honestly I'm not sure there is much of a line between the
| two. I've seen microservices that just return True/False and
| ones that return 100 lines of json, which are arguably more
| web-services than microservices.
|
| I honestly think it's a distinction without meaning.
| abledon wrote:
| " Hi ___, i saw your profile on linkedin and wanted to
| reach to say our team is looking to hire a 'Senior Boolean
| Microservice Architect' "
| dastbe wrote:
| it really is a distinction only made by people trying to
| sell you something or sell you on something. service-
| oriented architecture is leveraging the power and the curse
| of being able to connect computers over a network to solve
| foundational scaling limits of hardware. How granular you
| want to make things is a design decision.
| goodpoint wrote:
| > most younger large enterprises use microservices
|
| Which ones? Amazon uses roughly 1-team-1-service, not
| 1-team-100-*micro*services.
|
| Facebook famously built their main service as a monolith.
| jedberg wrote:
| Younger. Netflix, Dropbox, Stripe, Slack, Pinterest, Reddit
| is working on it, Smugmug, Thumbtack, a lot more I can't
| think of off the top of my head. Also I'm pretty sure Amazon
| has teams that maintain multiple services.
| goodpoint wrote:
| Then I'm glad I keep dodging the "cool and hip" hype-fueled
| companies.
| jka wrote:
| > Build your monolith with clean hard edges between modules and
| functions so that it will be easier later, but build a monolith
| until you get big enough that microservices is actually a win.
|
| I'd like to see software ecosystems that make it possible to
| develop an application that seems like a monolith to work with
| (single repository, manageable within a seamless code editing
| environment, with tests that run across application modules)
| and yet has the same deployment, monitoring and scale up/out
| benefits that microservices have.
|
| Ensuring that the small-team benefits would continue to exist
| (comparative to 'traditional' microservices) in that kind of
| platform could be a challenge -- it's a question of sensibly
| laying out the application architecture to match the
| social/organizational structure, and for each of those to be
| cohesive and effective.
| littlestymaar wrote:
| > they provide huge advantages to large companies [...] every
| startup I advise I tell them don't do microservices at the
| start.
|
| I think you nailed it. Microservices are a solution for
| organizational problems that arise when the company grow in
| size, unfortunately it's not rare to see small startups with a
| handful of engineers and 5 to 10 times more services...
| closeparen wrote:
| In what way is Google an exception? Are you saying that only
| one or a small number of different binaries run on Google's
| production servers?
|
| Google famously has a mono _repo_ but that 's different from a
| monolithic service architecture.
| jedberg wrote:
| Yes, that is a fair distinction that I simplified over. You
| don't really get a lot of the gains of microservices if
| you're using a monorepo, so while they do have multiple
| binaries/services, you still have to check into a single repo
| and wait for all the tests/etc. To be fair I haven't visited
| Google in a while and maybe it's changed now, but at least
| decade ago it was very different from how everyone else did
| microservices.
| eweise wrote:
| The past few companies I was at, we discussed whether we
| wanted a single or multiple repos. But that was a separate
| conversation from microservices, so I don't think its
| unusual to have a monorepo with microservices.
| singron wrote:
| Each releasable unit can wait for whatever tests you want.
| Usually it's just the tests for that unit. Google is
| actually a good example of why monolith/microservices is a
| completely different concept to monorepo/multirepo.
|
| I.e. you can put your monolith in multiple repos, and you
| can put 100,000+ services in 1 repo.
| timmg wrote:
| > You don't really get a lot of the gains of microservices
| if you're using a monorepo
|
| I think the two are completely orthogonal.
|
| At Google, when you check in code, it tests against things
| it _could have_ broken. Not all tests in the system. For
| most services, that means just testing the service. For
| infrastructure code, _then_ you have to test many services.
| javajosh wrote:
| _>...you get big enough that microservices is actually a win._
|
| Can you speak more about the criteria here?
|
| You may be implying that microservices enforce Conway's law. If
| so then when the monolith divides, it "gives away" some of it's
| API to another name, such that the new node has it's own
| endpoints. This named set is adopted by a team, and evolves
| separately from that point on, according to cost/revenue. The
| team and its microservice form a semi-autonomous unit, in
| theory able to evolve faster in relative isolation from the
| original.
|
| The problem from the capital perspective is that you get a
| bazillion bespoke developer experiences, all good and bad in
| their unique and special ways, which means that the personal
| dev experience will matter, a guide in the wilderness who's
| lived there for years. The more tools are required to run a
| typical DX, the more tightly coupled the service will be to the
| developers who built it. This generally favors the developer,
| which may also explain why the architecture is popular.
| jedberg wrote:
| The first part of your comment is accurate (and beautifully
| poetic). But I don't believe the second part follows from the
| first.
|
| At most companies that do microservices well, they have a
| dedicated platform team that builds tools specifically for
| building microservices. This includes things like deployment,
| canaries, data storage, data pipelines, caching, libraries
| for service discovery and connections, etc.
|
| This leaves the teams building the services focusing on
| business logic while having similar developer experiences.
| The code might use different conventions internally and even
| different languages, but they all interact with the larger
| ecosystem in the same way, so that devs at the company can
| move around to different services with ease, and onboarding
| is similar throughout.
| javajosh wrote:
| _> they all interact with the larger ecosystem in the same
| way, so that devs at the company can move around to
| different services with ease, and onboarding is similar
| throughout._
|
| But big enterprises inevitably lose "stack coherence" over
| time, through drift but also acquisitions. Finding the
| lowest common denomenator to operate and modify it all,
| while maintaining a high level of service (uptime,
| security, data integrity, privacy, value), turns out to be
| a tricky problem - just defining the product categories is
| a tricky problem!
|
| Well I for one would love to see such a thing properly
| functioning. I've seen two attempts, but neither were
| successful.
| mathgladiator wrote:
| As I build out my infrastructure for Adama (my real-time SaaS for
| state machines), I'm leaning hard into a monolithic design. The
| key reason is to minimize cost and maximize performance.
|
| For instance, comparing Adama to the services needed to build
| similar experiences offered by AWS has interesting results. Adama
| costs 97% less than AWS ( https://www.adama-
| platform.com/2022/03/18/progress-on-new-da... ), and a key thing
| is that the microservice approach is amenable to metering every
| interaction which scales linear to demand whilst a monolithic
| approaches condenses compute and memory.
| fdgsdfogijq wrote:
| I think the real reason is that cloud software development has
| enabled microservices. Meaning, if you arent on AWS or GCP,
| forget it. But if you are, its a paradigm that fits very well
| with cloud software architecture. Those criticizing it for the
| complexity, probably just havent spent enough time in code bases
| where it makes sense.
___________________________________________________________________
(page generated 2022-03-21 23:00 UTC)