Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon’s distributed computing manifesto (1998)

allthingsdistributed.com

Post reply on HN
Print view View original

11–20 of 61 posts

Re: Amazon’s distributed computing manifesto (1998)

#11

Post by awithrow »

kerblang wrote: post #3

> 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.

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.

Re: Amazon’s distributed computing manifesto (1998)

#12

Post by qqtt »

kerblang wrote: post #3

> 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.

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.

Re: Amazon’s distributed computing manifesto (1998)

#14

Post by bwestergard »

0xbadcafebee wrote: post #10

"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 pa…

"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?

Re: Amazon’s distributed computing manifesto (1998)

#15

Post by 0xbadcafebee »

bwestergard wrote: post #14
0xbadcafebee wrote: post #10

"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 pa…

"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?

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.

Re: Amazon’s distributed computing manifesto (1998)

#17

Post by epberry »

> 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.

Re: Amazon’s distributed computing manifesto (1998)

#18

Post by numbsafari »

kerblang wrote: post #3

> 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.

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.

Re: Amazon’s distributed computing manifesto (1998)

#19

Post by nevir »

> 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)

Re: Amazon’s distributed computing manifesto (1998)

#20

Post by manv1 »

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.

Post reply on HN