[HN Gopher] Amazon's distributed computing manifesto (1998)
___________________________________________________________________
Amazon's distributed computing manifesto (1998)
Author : werner
Score : 156 points
Date : 2022-11-16 16:03 UTC (6 hours ago)
(HTM) web link (www.allthingsdistributed.com)
(TXT) w3m dump (www.allthingsdistributed.com)
| faangst wrote:
| tillmannhgl wrote:
| viburnum wrote:
| I don't think this is really from 1998.
| wging wrote:
| The blog post is recent, but it describes much older work, so I
| think the "(1998)" tag is right.
|
| "Distributed Computing Manifesto
|
| Created: May 24, 1998"
| thomastjeffery wrote:
| The blog post (what the OP link takes you to) is from 2022,
| but the manifesto itself (the substance of the post) is from
| 1998; so both dates should be used:
|
| > Amazon's distributed computing manifesto (1998) (2022)
| wging wrote:
| 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.)
|
| For example,
|
| > 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.
|
| 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.)
|
| Then again, this is part of their pitch for workflow processing,
| not service-oriented architecture.
| ajkjk wrote:
| Anecdotally, it was at least 2015 before the DC processing
| system was actually mostly operating against service-oriented
| interfaces (when I left in 2016 we had a few old tools left
| that still talked to the databases directly :/ ).
| 0xbadcafebee wrote:
| _" 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."_
|
| 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'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.
| bwestergard wrote:
| "But also imagine getting every employee to change how they
| deal with vacations"
|
| Interesting example. Why would changing distributed computing
| architecture have an impact on vacation policy?
| 0xbadcafebee wrote:
| I'm saying architecture is just one way of changing an
| organization. Other ways of changing an organization,
| separate from anything technical, might include changing
| people's schedules or vacation policy, or who you hire, or
| where, or how. Another would be how you store parts, make
| orders, assemble products. Or starting work in an entirely
| new industry.
|
| Maybe you work at a company that sometimes works with the
| government. As a result, the whole company might develop a
| hiring process which is very slow, very detailed, and
| excludes certain people from being hired. But probably only a
| very small number of employees actually have to conform to
| those government requirements. You can apply them to all new
| hires "for simplicity", but it makes it harder to hire for
| non-government positions. So changing how you hire, to make
| it easier and faster to hire people of a wider background,
| benefits your organization. If your org can't easily make
| those changes, it will be disadvantaged.
| epberry wrote:
| > Currently much of our database access is ad hoc with a
| proliferation of Perl scripts that to a very real extent run our
| business.
|
| 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.
| kerblang wrote:
| > All of this was being done before terms like service-oriented
| architecture existed.
|
| I feel like the first time I heard the term was early 2000's, and
| wasn't it a mainframe thing first? Dunno, just wondering.
|
| Anyhow, it's nicely written, very concise, and worth noting how
| the original author focuses more on "What kind of realistic
| options do we have?" than winning the A vs. B vs. C argument in
| one fell swoop.
| fiddlerwoaroof wrote:
| Yeah, the buzzwords have changed, but some version of the
| concept has been in the air at least since I was learning
| Delphi in the 90s
| awithrow wrote:
| I remember seeing the term around the mid to late 2000s. But it
| was also used primarily in the context of enterprisy J2EE,
| weblogic servers and various IBM hardware that made the
| everything way more complicated than it needed to be.
| qqtt wrote:
| Things like Java RMI existed beforehand and there was the
| elements of industry moving towards server-based partitioning
| of services - the big difference is none of it was formalized
| and there was little consistent language of which to speak
| about these paradigms. At the beginning yes, people would
| discuss having one mainframe call another mainframe but today
| that would be SoA.
| numbsafari wrote:
| It was definitely pre-2000. First "SoA" firm I worked for, I
| started at in 99, and they had been doing it for 2 years
| already and most of the crew brought if from a prior gig.
| PaulDavisThe1st wrote:
| 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/1995, even though we believed we were thinking far, far
| ahead.
| asim wrote:
| I'm sure it would have been nice to have that tech in 94 and
| yet at the same time I get the feeling it had to play out the
| way it did for Amazon to succeed. Without the first part of the
| journey Amazon would not have gone on to build AWS.
| [deleted]
| oscholz wrote:
| Cool!
| EGreg wrote:
| What makes it so cool?
| oscholz wrote:
| cool!
| nevir wrote:
| > 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.
|
| 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 &
| developer ergonomics.
|
| We've got tools that 'generate' business layers from/for the data
| layer (Prisma, etc).
|
| We've got tools that push business logic to the client (Meteor,
| Firebase, etc)
| ajkjk wrote:
| For what it's worth, Amazon's architecture for the core retail
| business has, if anything, moved even further up in
| abstraction. Tighter coupling is something that simple usecases
| can afford. Large scale but low-complexity can be closely
| coupled. High-complexity can't be.
|
| The thing about Amazon's systems is that they are horrendously
| complex. In ~2016 I was working on the warehousing software,
| and it was a set of some hundreds of microservices in the
| space, which also communicated (via broad abstraction) to other
| spaces (orders, shipments, product, accounting, planning, ...)
| which were abstractions over 100s of other microservices.
|
| So what I observed at the time was a broad increase in
| abstraction horizontally, rather than vertically. This
| manifesto describes splitting client-server into client-
| service-server; the trend two decades later was splitting <a
| few services, one for each domain> into <many services, one for
| each slice of each domain>, often with services that simply
| aggregated the results of their subdomains for general
| consumption in other domains.
|
| I'm sure things have only gotten more complicated since then
| (in particular, a large challenge at the time was the general
| difficulty in producing maintainable asynchronous workflows, so
| lots of work was being done synchronously or very-slightly-
| asynchronously that should have been done in long-running or
| even lazy workflows).
| tsss wrote:
| Nowadays you separate service by business capability and not by
| "layer". Layers just lead to a dependencies and dependencies
| lead to bad reliability and terrible development speed.
| derefr wrote:
| What Amazon were describing here is simply the division
| between a frontend web gateway service (or, in modernity,
| client-delivered SPAs); an API backend service to serve the
| XHRs of the web-gateway / SPA; and some kind of DBMS where
| user-visible query schema is separable from storage
| architecture via e.g. views. I don't think there's any modern
| system that _doesn 't_ have those things, no?
| amcvitty wrote:
| A big part of the difference has to be that if you have a small
| number of developers (esp. n=1) and you can deploy everything
| at once, then those layers just get in the way of fast change.
| It seems Amazon were optimising for the ability to distribute
| data because they had big volume, and hide its form so they
| could change it without having to change lots of applications.
|
| Of course, there's some cargo culting around services where
| people jump to that architecture before they need it, but for
| most apps YAGNI. it's cool that their architecture was driven
| by clear needs "just in time" to allow them to continue to
| scale
| [deleted]
| manv1 wrote:
| This is one example of the CEO making something happen that
| essentially birthed AWS.
|
| Bezos, of all people, was like "make it happen." 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.
|
| And besides that they've done some incredible things with their
| infrastructure, like authorization. Distributed authorization is
| really hard, but at AWS it's completely invisible. Remove a
| permission from an IAM role and it moves through AWS really,
| really fast. It's totally magic. Anyone who was abused by CORBA
| knows how hard that is to do well.
|
| 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.
| p_l wrote:
| It's easy till you break IAM itself with your policy complexity
| and random services start dying because other AWS components
| few layers deep cnst get IAM to parse
| another_devy wrote:
| Intriguing, can you share details or overview why it failed
| for you. Will be kind of gotchas for me
| anonymousDan wrote:
| Can you (or anyone) say a bit about how the auth service is
| implemented from a distributed systems perspective? For example
| is it some kind of custom KV store?
___________________________________________________________________
(page generated 2022-11-16 23:00 UTC)