5 ms·

I have to ask. Isn't this just microservices ? Also isn't this terrible for latency and debugging ?

eutropia 7y ago
This email from 2002 describes system design decisions which led to amazon developing AWS. I wasn't a professional programmer at the time, but as I understand it, I think service-oriented design patterns were rare, let alone microservices as a concept.
lmm 7y ago
> Isn't this just microservices ? Yeah it is (though not so "micro-": it's really one service per team, which is the scale that actually makes sense IMO). This is kind of a "seinfeld is unfunny" case: this memo was in 2002, and predated (arguably helped create) most of the modern microservice approach. > Also isn't this terrible for latency and debugging ? When two codebases are owned by different teams (and potentially in different languages), it's far better to have them separated by a network connection and a well-defined HTTP API than living in the same address space where they can corrupt each other. Since the interfaces are well defined, you can isolate any problem down to a request that's not getting the correct answer from the service it's calling, and then hand that over to the other team to investigate. Since the request and response are plain text, it's easy to see what's happening. If responding to a single request from the end customer requires chaining through several independent codebases maintained by different teams, you have bigger problems than request latency. Each team should own a piece of end-to-end functionality, not a horizontal layer.
- huherto 7y ago
  Agree. The "Micro" prefix is very miss leading. It should be one per (pizza) team. Otherwise you end up with too many, and it becomes a mess.
- I_AM_A_SMURF 7y ago
  Not only that, but you can also track performance/crash rate/etc of each service individually and over time, which is a really powerful tool to have. Infinitely better than a monolithic system at that scale.
wgjordan 7y ago
> I have to ask. Isn't this just microservices ? Considering 'microservices' wasn't a well-known term for another decade [1], maybe better to ask: isn't 'microservices' just this ? [1] https://trends.google.com/trends/explore?date=all&q=microservices https://trends.google.com/trends/explore?date=all&q=microser...
atombender 7y ago
"Microservice" is just a new name for something that has had many names throughout history. For as long as we've had networks, we've had small, loosely coupled networked apps communicating with each other. We've also had standards for communicating and for discovering nearby services — at one point it was DCE/RPC, later CORBA or DCOM, or Java RMI. Then people started with REST and Thrift, and these days it's more often gRPC and GraphQL. I think the core of the Amazon invention was to mandate that the API be a strict boundary around a service. No cheating by making assumptions about the internals of the implementation. Force teams to work off the published API documentation, and make teams the guardians of each service. Microservices probably aren't developed exactly like that in many companies.

This email from 2002 describes system design decisions which led to amazon developing AWS. I wasn't a professional programmer at the time, but as I understand it, I think service-oriented design patterns were rare, let alone microservices as a concept.

lmm 7y ago

> Isn't this just microservices ? Yeah it is (though not so "micro-": it's really one service per team, which is the scale that actually makes sense IMO). This is kind of a "seinfeld is unfunny" case: this memo was in 2002, and predated (arguably helped create) most of the modern microservice approach. > Also isn't this terrible for latency and debugging ? When two codebases are owned by different teams (and potentially in different languages), it's far better to have them separated by a network connection and a well-defined HTTP API than living in the same address space where they can corrupt each other. Since the interfaces are well defined, you can isolate any problem down to a request that's not getting the correct answer from the service it's calling, and then hand that over to the other team to investigate. Since the request and response are plain text, it's easy to see what's happening. If responding to a single request from the end customer requires chaining through several independent codebases maintained by different teams, you have bigger problems than request latency. Each team should own a piece of end-to-end functionality, not a horizontal layer.

huherto 7y ago
Agree. The "Micro" prefix is very miss leading. It should be one per (pizza) team. Otherwise you end up with too many, and it becomes a mess.
I_AM_A_SMURF 7y ago
Not only that, but you can also track performance/crash rate/etc of each service individually and over time, which is a really powerful tool to have. Infinitely better than a monolithic system at that scale.

wgjordan 7y ago

> I have to ask. Isn't this just microservices ? Considering 'microservices' wasn't a well-known term for another decade [1], maybe better to ask: isn't 'microservices' just this ? [1] https://trends.google.com/trends/explore?date=all&q=microservices https://trends.google.com/trends/explore?date=all&q=microser...

atombender 7y ago

"Microservice" is just a new name for something that has had many names throughout history. For as long as we've had networks, we've had small, loosely coupled networked apps communicating with each other. We've also had standards for communicating and for discovering nearby services — at one point it was DCE/RPC, later CORBA or DCOM, or Java RMI. Then people started with REST and Thrift, and these days it's more often gRPC and GraphQL. I think the core of the Amazon invention was to mandate that the API be a strict boundary around a service. No cheating by making assumptions about the internals of the implementation. Force teams to work off the published API documentation, and make teams the guardians of each service. Microservices probably aren't developed exactly like that in many companies.