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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Amazon’s distributed computing manifesto (1998)

247 点作者 werner超过 2 年前

10 条评论

manv1超过 2 年前
This is one example of the CEO making something happen that essentially birthed AWS.<p>Bezos, of all people, was like &quot;make it happen.&quot; And it did. It was basically work for no reason except future proofing. Having someone up the food chain OK this much work for the future (and no hard dollar benefit) is highly unusual.<p>And besides that they&#x27;ve done some incredible things with their infrastructure, like authorization. Distributed authorization is really hard, but at AWS it&#x27;s completely invisible. Remove a permission from an IAM role and it moves through AWS really, really fast. It&#x27;s totally magic. Anyone who was abused by CORBA knows how hard that is to do well.<p>Their newer stuff (like Cognito) is sort of weird, but other things are surprisingly solid given how big AWS is. Small shops have trouble shipping feature complete software, and BigCorps can be even worse. AWS has gotten really good at it.
评论 #33635709 未加载
评论 #33635188 未加载
评论 #33630630 未加载
评论 #33631938 未加载
评论 #33633691 未加载
benhoyt超过 2 年前
I think this is a very interesting and clear manifesto, and almost certainly the right thing for Amazon at the right time (and presumably was part of what led to AWS). However, at one of the previous companies I worked at we got an ex-Amazon person as CTO and he grew the company from 50 engineers to 500 in 2 years, and pushed microservices everywhere. Very impressive, and I think all-microservices made sense at one level to handle that sort of growth, but it doesn&#x27;t make sense technically in a lot of cases.<p>Essentially I think we&#x27;ve gone too far: service-oriented architectures turned into &quot;micro&quot; services, which come with a lot of complexity and distributed systems issues. I think for most small companies monoliths are right, for medium-sized companies (say 50+) it makes sense to carefully introduce a few separate services, and only for large companies (say 300+) does many services (which may or may not be &quot;micro&quot;) start to pay off. I&#x27;ve heard it said that &quot;microservices solve a people problem, not a technical one&quot;, and I think that&#x27;s true.
评论 #33633329 未加载
评论 #33635708 未加载
PaulDavisThe1st超过 2 年前
As one of the main designers of the original system (but who had left by the time this architectural change was done), that is an interesting read. Always good to see the things that we missed in 1994&#x2F;1995, even though we believed we were thinking far, far ahead.
评论 #33630826 未加载
0xbadcafebee超过 2 年前
<i>&quot;And with every few orders of magnitude of growth the current architecture would start to show cracks in reliability and performance, and engineers would start to spend more time with virtual duct tape and WD40 than building new innovative products. At each of these inflection points, engineers would invent their way into a new architectural structure to be ready for the next orders of magnitude growth.&quot;</i><p>That last part, to me, is the key to success: getting the whole business to do things in a new way. That is fucking hard. If you can get your business to do it, you have an invaluable superpower. The more things that you can reinvent, faster, gives you more and more superpowers. It&#x27;s one thing to change your architecture. But also imagine getting every employee to change how they deal with vacations, suppliers, customers, finance, or involving entirely new industries. The easier it is to adapt and change, the longer you survive and the more you thrive. Evolution, baby.
评论 #33632457 未加载
评论 #33629234 未加载
kerblang超过 2 年前
&gt; All of this was being done before terms like service-oriented architecture existed.<p>I feel like the first time I heard the term was early 2000&#x27;s, and wasn&#x27;t it a mainframe thing first? Dunno, just wondering.<p>Anyhow, it&#x27;s nicely written, very concise, and worth noting how the original author focuses more on &quot;What kind of realistic options do we have?&quot; than winning the A vs. B vs. C argument in one fell swoop.
评论 #33636460 未加载
评论 #33628739 未加载
评论 #33628423 未加载
评论 #33628734 未加载
评论 #33629571 未加载
nevir超过 2 年前
&gt; We propose moving towards a three-tier architecture where presentation (client), business logic and data are separated. This has also been called a service-based architecture. The applications (clients) would no longer be able to access the database directly, but only through a well-defined interface that encapsulates the business logic required to perform the function.<p>It is really interesting to see a recent(ish) trend away from this three tier design and back towards tighter coupling between application layers. Usually due to increased convenience &amp; developer ergonomics.<p>We&#x27;ve got tools that &#x27;generate&#x27; business layers from&#x2F;for the data layer (Prisma, etc).<p>We&#x27;ve got tools that push business logic to the client (Meteor, Firebase, etc)
评论 #33630496 未加载
评论 #33630049 未加载
评论 #33630258 未加载
评论 #33630588 未加载
wging超过 2 年前
It’s interesting to think about how much of a perspective shift this must have been, especially the service oriented bits. Interestingly, I think it might not have even been made completely in the authors’ minds at the time of this proposal. (Which is understandable, of course. It’s a proposal, not a retrospective on already accepted ideas.)<p>For example,<p>&gt; In the case of DC processing, customer service and other functions need to be able to determine where a customer order or shipment is in the pipeline. The mechanism that we propose using is one where certain nodes along the workflow insert a row into some centralized database instance to indicate the current state of the workflow element being processed.<p>definitely doesn’t seem to reflect the hiding of a database behind an interface. (From a workflow node’s perspective, rows in that centralized database should be an implementation detail it has no knowledge of.)<p>Then again, this is part of their pitch for workflow processing, not service-oriented architecture.
评论 #33630542 未加载
epberry超过 2 年前
&gt; Currently much of our database access is ad hoc with a proliferation of Perl scripts that to a very real extent run our business.<p>There are companies started later than 2010 where this was still the case. Interesting to think about how shipping things quickly is so different than scaling them up.
npalli超过 2 年前
Seeing that Werner Vogels has submitted this entry, I wonder if he can comment how long it took to actually build this out. When did a form of this service oriented architecture work in production at Amazon?
viburnum超过 2 年前
I don&#x27;t think this is really from 1998.
评论 #33629451 未加载