3 ms·

>It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. So how does Amazon manage this btw? I don't find AWS SDKs

by jayd16 5y ago

>It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. So how does Amazon manage this btw? I don't find AWS SDKs to be all that consistent or inconsistent. They are usually good _enough_. Is that all it takes? By contrast, Google seems to spend a lot of time on their single repo, build the world, approach. For the most part it seems beloved, or at least people try to recreate it outside google with things like Bazel. I feel like Google's approach is more popularized. Is that because its actually better, just advertised more, or simply consistent enough to explain? Can anyone shed light on Amazon's approach?

ketzo 5y ago
> I feel like Google's approach is more popularized I mean, the engineering architecture being described in this memo is, basically, microservices. That's certainly an extremely popular -- I would go so far as to say even vogue -- pattern for solving the problem of building software at scale.
- nivertech 5y ago
  No, they're just services - a service per team. Microservices usually overdoing it, when you have multiple microservices per team, and sometimes even per developer. Also, microservices sometimes implemented incorrectly, where they're still communicate via shared databases, instead of encapsulating them and exposing them via service APIs only. This Memo was born because of the real business need, while many modern microservices deployments are the result of cargo-culting GAFAMs/FANGs.
  - pjmlp 5y ago
    Indeed, hence "the network is the computer" footnote that used to be written on Sun manuals. Many cargo cult web services of today can be written in Sun RPC APIs. But yeah it is C and its IDL isn't as cool as gRPC proto files.
raverbashing 5y ago
For real, if AWS internal APIs are as good as their outside-facing ones I fear the complexity. Their APIs are... correct. But have things like usability as a last concern. You also find some things not behaving exactly as you would expect and some things that are barely explained.
shaicoleman 5y ago
I don't work in Amazon, but from everything I've heard and read Amazon values autonomy more than consistency. I think there's a saying there: "it's better to have two of something than none". This can often result in inconsistency and duplication. When that happens, a team would later be formed to unify things if needed.
Macha 5y ago
I've definitely been burned by inconsistency on Amazon API inconsistency. At least 3 years ago, Cloudformation, Data Pipeline and an EMR specific API all have three differing sets of params for defining an EMR cluster and just because something was supported in one of them didn't mean it was even in the others.
philwelch 5y ago
When I worked at Amazon there was a framework similar to gRPC for internal API’s. This was a few years before gRPC was released and the framework was already a few years old at this point.

by jayd16 5y ago

ketzo 5y ago

> I feel like Google's approach is more popularized I mean, the engineering architecture being described in this memo is, basically, microservices. That's certainly an extremely popular -- I would go so far as to say even vogue -- pattern for solving the problem of building software at scale.

nivertech 5y ago
No, they're just services - a service per team. Microservices usually overdoing it, when you have multiple microservices per team, and sometimes even per developer. Also, microservices sometimes implemented incorrectly, where they're still communicate via shared databases, instead of encapsulating them and exposing them via service APIs only. This Memo was born because of the real business need, while many modern microservices deployments are the result of cargo-culting GAFAMs/FANGs.
- pjmlp 5y ago
  Indeed, hence "the network is the computer" footnote that used to be written on Sun manuals. Many cargo cult web services of today can be written in Sun RPC APIs. But yeah it is C and its IDL isn't as cool as gRPC proto files.

raverbashing 5y ago

For real, if AWS internal APIs are as good as their outside-facing ones I fear the complexity. Their APIs are... correct. But have things like usability as a last concern. You also find some things not behaving exactly as you would expect and some things that are barely explained.

shaicoleman 5y ago

I don't work in Amazon, but from everything I've heard and read Amazon values autonomy more than consistency. I think there's a saying there: "it's better to have two of something than none". This can often result in inconsistency and duplication. When that happens, a team would later be formed to unify things if needed.

Macha 5y ago

I've definitely been burned by inconsistency on Amazon API inconsistency. At least 3 years ago, Cloudformation, Data Pipeline and an EMR specific API all have three differing sets of params for defining an EMR cluster and just because something was supported in one of them didn't mean it was even in the others.

philwelch 5y ago

When I worked at Amazon there was a framework similar to gRPC for internal API’s. This was a few years before gRPC was released and the framework was already a few years old at this point.