TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

You Don't Need Microservices

113 点作者 msaspence将近 3 年前

34 条评论

hericium将近 3 年前
Microservices are a great way to promote cloud vendors&#x27; offerings and complicate IT life with over-engineered &quot;standards&quot; like Kubernetes.<p>Big corp wins while their customers create DevOps and other buzzword teams and the majority of IT world loses the capability to actually administer systems and becomes users addicted to ever-changing vendor offerings that complicate learning useful stuff outside.
评论 #32251417 未加载
DoneWithAllThat将近 3 年前
I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.
评论 #32251866 未加载
评论 #32251806 未加载
评论 #32261587 未加载
评论 #32252009 未加载
评论 #32259102 未加载
评论 #32261447 未加载
评论 #32251750 未加载
评论 #32254689 未加载
taude将近 3 年前
I&#x27;d love to see more of these &quot;you don&#x27;t need microservices&#x27; type of articles be more prescriptive on when you might need them. 20 product scrum teams? 10 different team? Certain functional team separate (like you have a data infra team, search, payment processing)?<p>I always can&#x27;t help but to think most of these articles are written by engineers working at 30 people startups or something. And there&#x27;s definitely a lot of org-size and structure between the startup and a faang-sized tech giant.
评论 #32251480 未加载
blowski将近 3 年前
I’d argue bashing microsevices is more in vogue than microservices themselves. They’ve reached that point on the hype cycle where you can get a whole bunch of likes by saying “microservices bad amirite?!”
评论 #32251992 未加载
评论 #32251840 未加载
评论 #32251931 未加载
评论 #32271934 未加载
评论 #32254276 未加载
评论 #32251884 未加载
kristopolous将近 3 年前
Some people will make an incoherent mess out of anything.<p>A garbled knot of interdependent microservices with timing issues, bad extensibility, and unpredictable flow.<p>An ornate matroyshka set of wrapper functions calling each other spreading over multiple directories making any modification a large error prone effort.<p>Event systems, probably multiple, without any real difference between just a function call other than your debugger getting very confused by it.<p>Database schemas with table names that exude the narcissism of small differences with nitpicky rules that make it explode if any flexibility is demanded<p>Aws bill that&#x27;s 10x more than any reasonable expectation given the problem set.<p>An object oriented design that looks like some kind of fetishized exercise of every feature possible, where defects cascade to action at a distance and unintended consequences with tight coupling that can&#x27;t be extricated leading to a rewrite, just like it did last time<p>They are the people who create the waterfall of dozens of levels of div tags for no functional reason other than to accommodate their incompetency<p>They are the ones that want to pollute your entire day with needless meetings over irrelevant things that will not be acted upon.<p>Of course there&#x27;s no useful comments or tests or documentation. The git comment messages are single words like &quot;fix&quot; and &quot;rewrite&quot;. There&#x27;s no versions in the deploy or a reasonable approach to logging that allows a successful audit and the thing is too state dependent to reproduce bugs.<p>Then there&#x27;s dependencies, loads of them just picked seemingly at random, written by people who think like them with the same disregard for documentation, compatibility or testing. But they have very pretty websites which says they&#x27;re painless, simple and easy, so I guess it&#x27;s all ok right?<p>The problem with microservices is the same problem with anything else and changing paradigms won&#x27;t fix it. The approach needs to change, not the technique. It&#x27;s a different kind of budo.
评论 #32257498 未加载
评论 #32254608 未加载
softwarebeware将近 3 年前
&quot;You don&#x27;t need&quot; anything. You can walk to New York from San Francisco. But of course you&#x27;d rather fly. You may settle for driving.<p>The power of a concept isn&#x27;t in the need but in how well it optimizes the process.
api将近 3 年前
One of the benefits of being in this industry for a while is that you learn to spot and avoid fads. You even learn classes of fads.<p>Microservices instantly looked like a fad. Two classes of fad apply. One is a &quot;move stuff around and complexity will magically go away&quot; fallacy fad. The other is a &quot;way to promote vendor lock-in or higher cost&quot; fad.<p>Other major classes of fads are: consultant self promotion fads, re-invention fads of all kinds in which devs speed run the history of some aspect of computing to arrive at the same place, magic pixie dust fads where sprinkling some buzzword on things makes everything better, management &quot;methodology&quot; panacea fads, etc.<p>Avoiding fads is a superpower. It tends to save a whole lot of money and wasted time.<p>The test of whether something is a fad is whether it reduces incidental complexity, enables something categorically new, or genuinely boosts developer velocity.<p>Incidental complexity is the complexity that creeps into our designs that is <i>not</i> essential to the problem but an artifact of how we got there or some prior limitation in how things are done. A genuine innovation will make incidental complexity actually go away, but <i>not</i> by pretending that essential complexity doesn&#x27;t exist.<p>A categorically new thing would be e.g. deep learning or an actually practical and useful provably-safe language (Rust).<p>Boosting developer velocity means actually speeding up time to ship without doing so by adding a ton of technical debt or making the product suck.<p>If something doesn&#x27;t do at least one of those things well, it&#x27;s a fad.
评论 #32251946 未加载
评论 #32251921 未加载
评论 #32252533 未加载
revskill将近 3 年前
Microservice is to manage junior level programmers who don&#x27;t know how to make loosely coupling architecture. That&#x27;s it. Because your job is to manage low quality code produced by junior devs, you need to use microservice to prevent bad code to break the monothlic.<p>Edit: For more context, this opinion is more about &quot;the art of developer management&quot;, not much about infra, security, scalability stuff
评论 #32251791 未加载
评论 #32251372 未加载
评论 #32252243 未加载
评论 #32251858 未加载
评论 #32252134 未加载
评论 #32253153 未加载
评论 #32271981 未加载
goncalo-r将近 3 年前
Aren&#x27;t microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?
评论 #32251103 未加载
评论 #32251083 未加载
评论 #32251220 未加载
评论 #32251677 未加载
评论 #32251158 未加载
akoumjian将近 3 年前
Self-promoting a little utility I wrote that helps guide teams on whether your service boundary is a good idea: <a href="https:&#x2F;&#x2F;mulch.dev&#x2F;service-scorecard&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mulch.dev&#x2F;service-scorecard&#x2F;</a><p>The service scorecard asks a bunch of reflective questions about the ramifications of making some set of functions a unique service and points its benefits or lack thereof on a scale.
msaspence将近 3 年前
Why the monolith should remain the default choice for new, small, and medium-sized engineering teams. Considering how we can leverage the monolith to realize the benefits that microservices claim for themselves.
评论 #32251157 未加载
monksy将近 3 年前
You got to love the balant disregard for alternative architectures where this article has to advocate for monoliths again.<p>You can isolate pieces of your architecture and simplify them. A lot of issues with microservices inside the system (not user facing) comes from the expectations of what the microservice deals with, the enforced boundry of the microservice, intention of it, and the fact that anyone can connect to it.<p>Think about streaming data systems. These allow for multiple components connecting to durable queues (with maintence polices) that will process data and pass it along. This is more for data that may take longer, and shouldn&#x27;t be done in the same request.<p>Slight personal rant: The crap that I&#x27;ve seen people expect of microservices to do in a request is excessive. (If you&#x27;re doing more than taking a request, reading+writting into a database.. you&#x27;re doing too much and your performance is terrible) Additionally there is very little consideration about what happens when a microservice performs badly.
评论 #32251868 未加载
aarondf将近 3 年前
I wrote a library [1] for Laravel that lets you put a kind of &quot;microservice&quot; <i>inside</i> of your monolith.<p>It lets you develop, deploy, and execute AWS Lambda functions from your Laravel application.<p>The theory here is that sometimes you need some other language&#x2F;infrastructure beyond what you&#x27;re comfortable devops-ing yourself, and Lambda is actually quite good at providing you with an entire stack of stuff you don&#x27;t have to own.<p>So if you need a single Node, Python, or Ruby function you can put just that part on Lambda and still call it from Laravel as if it were a native PHP function. No API gateway or anything to muck about with, either.<p>Is it a true microservice? Not really, although who knows what that actually means. It does allow you to take advantage of <i>some</i> parts of microservices without the pain though!<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;hammerstonedev&#x2F;sidecar" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hammerstonedev&#x2F;sidecar</a>
评论 #32251676 未加载
pmelendez将近 3 年前
&gt;Modularize Your Monolith<p>It is true that probably any monolith can be break down into components, that won&#x27;t prevent the full redeployment (and all the risks that it brings) though.<p>I think in reality no one needs Microservices, or Monolith for that matter. You would pick the poison that adjust the best to your needs.
评论 #32251389 未加载
hatware将近 3 年前
Isn&#x27;t the devil in the details? Some problems are solved better as Microservices. Some problems are solved better as monoliths. Ultimately it is the lack of maintaining the solution we choose that leads to the &quot;grass is greener&quot; fad chase.
评论 #32272092 未加载
darrmit将近 3 年前
While I agree that there are definitely some cautionary tales regarding microservices, consistent and autonomous delivery across many teams with a complex monolith is equally if not more difficult than some of the cons that come with microservices.<p>I don&#x27;t think the answer is as easy as &quot;you don&#x27;t need microservices&quot;. I think the answer is &quot;you can effectively use both&quot;.
评论 #32272065 未加载
Rochus将近 3 年前
The article represents a reasonable position.<p>Monolith is an unfortunate term by which everyone seems to mean something different. So is any application whose parts do not communicate via network interfaces a &quot;monolith&quot;? Is an application where the majority of the function calls are not realized as a series of network transactions (like CORBA at that time) a less good application than one where different classes and modules on the same machine communicate directly with each other?<p>We should stop using the term, nor assigning blanket value attributes to it. &quot;Monolyth&quot; is not the antonym to &quot;Microservices&quot;, as suggested by the article. From a certain distance, every system looks like a monolith; that has more to do with the viewer than the system.
lasereyes136将近 3 年前
I don’t know if you will need microservices or not. I can tell you that many developers and teams will do microservices poorly and will not get an advantage out of it and will have an even more complex ball of mud to maintain.
declnz将近 3 年前
&gt; Odds are it is easier to resolve performance issues and bottlenecks in your monolith than it is to transition to a new architecture pattern.<p>I dunno but when I see <i>odds are $X</i> I read <i>unproved and perhaps unprovably, my opinion is $X</i>
physicsguy将近 3 年前
I’m working in a team right now that went through “CV driven development” with no oversight and has Django + micro services. One of them was written in Go, despite only one person knowing that language. The rest are a mess of unreliability - I found recently one of the services polls the main application’s internal API, and the script cuts off after 10 minutes of runtime and a new ECS container is launched. Why cron wasn’t preferable to this I will never know?!<p>We have something like 19 different components. Insane.
mbrodersen将近 3 年前
You have a problem. So you choose Microservices. Now you have N distributed problems and a system that is K times slower. Well done.
chaoz_将近 3 年前
&gt; Fault Isolation &gt; The ability for a single feature of your application to go down without taking the rest down with it is a big bonus of a properly designed microservices architecture.<p>Yes, but it also comes with a cost. Microservices might still fail in a cascade manner and bringing such system up under significant load is even more challenging.
评论 #32251400 未加载
JLuterek将近 3 年前
You are probably correct for small to medium sized tech teams building software. With that said, in 2022 I&#x27;d expect any company selling a SaaS product to be built with micro-services. Buying a SaaS I want all of the benefits, but no longer need to deal with the hard parts.
评论 #32272085 未加载
ReflectedImage将近 3 年前
You do need microservices because when when parts of you system are badly written or the requirements change, etc, etc..<p>You can just shoot a couple of the offending microservices dead and replace them with better implemented versions.<p>[Assuming there are at least 6 developers]
评论 #32272071 未加载
评论 #32259057 未加载
jmartrican将近 3 年前
Is this analogous to saying &quot;you dont need TDD cause you can always write your tests after the code is written&quot;? Or &quot;you dont need encapsulation because you can just ignore the parts of the code you should not be touching&quot;?
threesquared将近 3 年前
But honestly what do you do when your application monolith outgrows its relational database. This seems to be the main reason to split concerns into their own services. Relational DBs don&#x27;t scale horizontally.
drewcoo将近 3 年前
Was there historically so much resistance to other forms of loose coupling and high cohesion? Maybe from the anti-OOP crowd when OOP was first catching on?
评论 #32272137 未加载
评论 #32261501 未加载
wintorez将近 3 年前
Also, You Don&#x27;t Need Micro-frontends.
NHQ将近 3 年前
You don&#x27;t medium dot com either.
EGreg将近 3 年前
As someone who has built a monolith, full-stack (literally everything from MySQL to PHP+Node.js to the Web to Cordova) platform at <a href="https:&#x2F;&#x2F;qbix.com&#x2F;platform" rel="nofollow">https:&#x2F;&#x2F;qbix.com&#x2F;platform</a> I can still tell you, that microservices are great. But the average person isn&#x27;t going to fine-tune all those microservices. They need to install something that just works out of the box. An expert can be hired to fine-tune some parts of the stack (e.g. add a CDN or varnish cache) and not others. The layers (e.g. database, file system) already are separated and cloud services like Amazon can even scale them automatically (e.g. Aurora or Lambda).<p>The main problem isn&#x27;t microservices, it&#x27;s control and interoperability. Facebook decides it wants to turn into TikTok? Too bad for all its users, it&#x27;ll happen. &quot;Relax, breathe, we hear you&quot; is what Zuck said to all his outraged users after the first big rollout of newsfeed. Then a lot of scandals later (beacon, etc.) they are still at it. Google sunset Reader just like that. People are HOPING that Elon Musk adds a feature to Twitter. This is crazy.<p>Host stuff yourself, and not in the cloud. And for that, we need people to be able to &quot;just install&quot; something, like a Wordpress 5 min install on a hosting company.<p>I don&#x27;t want to make this comment long, so anyone who wants to read the full thesis can see it here: <a href="https:&#x2F;&#x2F;qbix.com&#x2F;blog&#x2F;2021&#x2F;01&#x2F;15&#x2F;open-source-communities&#x2F;" rel="nofollow">https:&#x2F;&#x2F;qbix.com&#x2F;blog&#x2F;2021&#x2F;01&#x2F;15&#x2F;open-source-communities&#x2F;</a>
评论 #32272161 未加载
ehutch79将近 3 年前
I just read yesterday, that not only does my blog need microservices, it needs microfrontends.
RickJWagner将近 3 年前
Wow. The pendulum has been going back and forth on this one for a long time.
mesozoic将近 3 年前
I don&#x27;t know who these articles are written for (having read this one in a dozen variations) Sure I agree they&#x27;re not always the right solution but do you think you&#x27;re going to convince someone who thinks they are at some small company from trying to roll them out?
mountainriver将近 3 年前
Just write regular sized services, we don’t need to all live on the edge