[HN Gopher] Microservices aren't the problem. Incompetent people...
___________________________________________________________________
Microservices aren't the problem. Incompetent people are
Author : thunderbong
Score : 32 points
Date : 2023-11-08 19:43 UTC (3 hours ago)
(HTM) web link (nondv.wtf)
(TXT) w3m dump (nondv.wtf)
| zug_zug wrote:
| Enough things are wrong win the first paragraphs of this article
| that I can't be bothered to skim it.
|
| But the attitude that "X that fails at 9/10 companies isn't the
| problem, we just need to change millions of engineers" is a naive
| attitude.
| threeseed wrote:
| Enough things are wrong win this comment that I can't be
| bothered to skim it.
|
| If you're going to make claims that micro-services are failing
| at 9/10 companies you really should have a source.
| spandrew wrote:
| Agreed. This is like blaming the user for your bad UX. Nope,
| the solution increased the complications of a very complex
| problem set (scaling software development).
|
| There are no silver bullets that can solve this. Only well-
| designed systems accommodate for the flexibility of human error
| and hubris can do that.
| brodouevencode wrote:
| Yeah, it is a bit of a blanket statement, and it's quite common
| to headline with provocation, but there are some good things in
| here. He admits upfront that MS is his personal preference.
|
| > I understand it's a harsh title and at times a harsh essay.
| Such is life. All opinions are my own.
|
| Some takeaways you might have missed:
|
| * Use the right tool for the job - one-tool shops are bound to
| fail
|
| * (Similar to above) There is a tendency to find _a_ solution
| rather than the _optimal_ solution
|
| * The engineering halo effect is real and prominent
|
| Then the author goes on to provide some possible solutions:
|
| * Using the SOLID framework for building
|
| * Use services
|
| * KISS
|
| * Developer experience is very important
|
| * Protect your time and your work
|
| * Governance is required to enforce certain principals.
|
| I don't agree with all of these, but they are certainly worth
| considering.
| piva00 wrote:
| > But the attitude that "X that fails at 9/10 companies isn't
| the problem, we just need to change millions of engineers" is a
| naive attitude.
|
| It's even worse than naive, it's a literal fallacy, a "No true
| Scotsman" with technology.
|
| System resilience is important at scale, and resilience
| includes being resilient to the failures in the human component
| of development; if a system depends that every one developing
| it to be a master of the underlying foundation then you'll
| require lots of very specialised, competent people who mastered
| the technique. That is very costly, if microservices depend on
| high mastery then we should budget the cost of the talented
| people _required_ to run it.
|
| My experiences with how to successfully deploy microservices
| include much the opposite: giving tooling to incompetent people
| to avoid the worst footguns, training them in best practices
| over time while designing an architecture that is somewhat
| resilient to their inevitable failures, one that is easy to be
| fixed when they've learned how to best use it.
| drekipus wrote:
| > "incompetent people are"
|
| Yep, which is why it's the problem. You will always have
| incompetent people.
| mad_vill wrote:
| Bingo. Design for incompetence. There are few codebases in this
| world that don't need incompetent people to contribute to them.
| (This is typically driven by business incentives)
|
| If you get to work on one of those codebases ... good for you.
| The rest of us are just trying to gatekeep piles of shit from
| getting in while being pushed by management to open the flood
| gates.
| devbent wrote:
| Everyone is stupid at 3am when the on call alert goes off and
| a critical service is down.
|
| Write code and design systems so 3am you can fix them!
| cirgue wrote:
| There are a lot of things in life that would be trivial if
| everyone was really good at what they did, had the most perfectly
| pure of intentions, and were omnisciently aware. Unfortunately
| that's not the world we live in, and even farther from the
| companies most of us work for. Good technology is about figuring
| out shortcuts around hard problems, and "large groups of people
| trying to coordinate their activities across space and time" is a
| _hard_ fucking problem.
| apatheticonion wrote:
| I feel like there is an unfair sentiment of competence elitism in
| the software engineering world.
|
| I don't think you can stop less experienced engineers (or
| experienced but still bad engineers) from contributing to
| projects - especially at the scale of a lot of these large
| organisations.
|
| After all, for people early in their careers, being bad is the
| first step to being good and it's impractical (or impossible) for
| organisations to exclusively hire "premium" engineers.
|
| There's also nothing wrong with engineers who program exclusively
| to collect a paycheck and aren't actually passionate about their
| work. I believe this is an inevitable side effect of the
| accessibility of programming today.
|
| Project architects should instead strive to design their systems
| such that they expect low quality contributions and limit the
| potential damage those contributions can have. Systems should be
| able to take a low quality contributions and if the need arises,
| have the capacity for those circuits to be optimised at a later
| date without rewriting the entire thing.
|
| I personally find the argument that "bad engineers make
| microservices bad" to be silly. Bad engineers would poison any
| poorly architected project, be it a monolith, microservice or
| otherwise. Microservices are just an architectural optimisation
| with trade offs that some organisations find value in.
| PH95VuimJjqBqy wrote:
| they're called juniors and every other industry has seniors to
| help guide them and ensure they don't make major mistakes.
|
| Except in our industry. In our industry the juniors often are
| the ones making the decisions.
| fallingknife wrote:
| Inexperienced engineers aren't the problem. Juniors will submit
| spaghetti code messes, but those can be cleaned up without too
| much trouble. The real problem is incompetent people higher up
| that can make large scale architecture and design decisions.
| e.g. somewhere I used to work there was a VP that decided to
| hand roll an ORM instead of just using Django.
| jayceedenton wrote:
| This article seems to be trying to get in way too much, but I
| appreciate the initial sentiment.
|
| The sad truth is, a smart team can do well with any architecture.
| A weak team will fail with any architecture. And maybe it's not
| really too sad.
|
| I've seen organisations that really kick ass using microservices,
| and I've seen some microservices horrorshows too. The difference
| is having teams that are talented enough to get the benefits of
| any given technique and mitigate the drawbacks well. Those teams
| will execute any architecture to its maximum benefit.
| Veuxdo wrote:
| > There's also another category of people. Good (sometimes
| brilliant, even) engineers who know exactly what they're doing
| but who simply don't care enough to do the right thing.
|
| Sometimes not doing the right thing is the right thing to do.
| SoftTalker wrote:
| I don't know how CS is taught these days. In the 1980s I learned
| a lot about data structures, algorithms, and programming
| languages, virtually none of which I ever directly used in my
| later career. I've never had a job that required leetcode
| knowledge. I've never had to write a sort or a search or a tree
| balancing algorithm from scratch. There are libraries for
| anything you might want to do (and if there aren't, that's often
| a big red flag that you're doing something wrong).
|
| I learned almost nothing about engineering. It took me quite a
| while on the job to learn and appreciate the practices that
| result in long-lived, maintainable systems. Overly complex,
| fragile systems with inscrutable interdependencies using esoteric
| frameworks are often the product of smart people who don't
| understand engineering principles (yet we often call them
| "engineers").
| wvenable wrote:
| In the late 90's and early 2000's I learned all that data
| structure stuff but that was mostly in the first 2 years.
| Beyond that many classes were about software engineering,
| project management, etc. I learned Agile (then in it's infancy)
| as well as doing a complete waterfall project (which turned out
| poorly -- as expected). But even at that time most other
| schools did not offer those kinds of courses in their CS
| education.
| devbent wrote:
| In contrast, I've worked on 2 UI frameworks and knowing all
| about tree traversal was super useful.
|
| I've sat next to the engineer who had to write various sort
| algorithms for the embedded runtime I helped design.
|
| I've witnessed a file system get implemented from scratch.
|
| I have walked through the Windows' kernel source code and
| knowing my fundamentals sure as heck helped to keep me
| grounded.
|
| > (and if there aren't, that's often a big red flag that you're
| doing something wrong).
|
| Or that you've chosen a career building the layers that
| underpin everything else.
|
| I've found that life is more enjoyable when I understand how
| things work at a base level, and remembering my fundamentals
| opened up doors to work on cool projects.
| safetytrick wrote:
| An under-rated solution to this problem is saying No and having
| quality retrospectives.
|
| Microservices adoption has largely become a cargo cult thing. It
| is a part of being cool like FAANG.
|
| Instead of being cool, focus on solving your problems.
| willsmith72 wrote:
| > Instead of being cool, focus on solving your problems.
|
| This needs repeating to every dev every week. Myself included
| tdeck wrote:
| Microservices are a solution to an organizational challenge:
| how do we set clear boundaries of ownership within a complex
| system? From a technical perspective there are pros and cons.
|
| Unfortunately, I don't see a wealth of other ready-made
| practices for companies to copy when they grow and need to
| solve this problem. I once worked on an enormous Rails monolith
| that was very well organized and had layered on several
| additional patterns to improve modularity and maintainability.
| Still, a SEV in a minor product area could (and did) bring down
| the whole system, and they were in the process of dismantling
| it.
| willsmith72 wrote:
| what a ramble
|
| > Not being smart is totally fine (I certainly am not one). We
| just need to avoid being stupid.
|
| > Let's face it, engineers, most of us aren't smart
|
| > most people don't give enough shit to improve
|
| Barely even makes sense, and is just a bunch of random opinions
| obviouslynotme wrote:
| Microservices are Resume Driven Development, the leading paradigm
| of our industry and others. People will always optimize for the
| incentive structures of their environments.
|
| The most important person in every company is the CEO. He sets
| down the culture of the company and creates these incentives
| either directly or indirectly. The only solution to RDD is for
| the CEO to be tech oriented, avoid hiring people who jump
| companies every couple years, build a great work environment, and
| compensate people well.
| mschuster91 wrote:
| > avoid hiring people who jump companies every couple year
|
| You don't get many of those people any more, because just about
| every other employer has burned that bridge to the ground.
| People, especially the young ones who entered their careers
| around the 2008ff megacrisis, have _zero_ trust left in anyone.
|
| When companies don't care and ditch us at the first sign of
| problems (easy, because we were the freshest hires), why should
| we show any sign of loyalty in return? If you want loyalty, pay
| us.
| alex_lav wrote:
| There can be two problems.
| deanCommie wrote:
| Competent engineers never understand why others are not as
| competent as them. It'd be cute if they didn't then write
| thoughtleadership about how it's really simple to get rid of the
| cloud - you too can run your own datacenter, and custom
| kubernetes orchestration competitor. Just hire competent people!
|
| Looking at ya, DHH.
|
| And of course, it's the same thing here:
|
| > The real problem, I think, is the lack of engineering
| competence and the lack of "giving a shit" in companies
|
| OOOOH they should just hire competent people? I guess they never
| thought of that...
| readthenotes1 wrote:
| X isn't the problem, people are.
| andrewstuart wrote:
| Ah, it's not a problem with the phone, "you're holding it wrong".
___________________________________________________________________
(page generated 2023-11-08 23:02 UTC)