29 ms·

> While the third point makes all the difference in the world, what Amazon really did get right that Google didn’t was an internal communication system designe

by xyzzyz 7y ago

> While the third point makes all the difference in the world, what Amazon really did get right that Google didn’t was an internal communication system designed to make all the rest possible. > Having teams acting like individual APIs and interacting with one another through interfaces over the network was the catalyst of a series of consequent actions that eventually made possible the realization of AWS in a way that couldn’t have been possible otherwise. Google has worked this way since time immemorial. That’s what protocol buffers are for: to create services and pass data between them using well defined interfaces.

defen 7y ago
> Google has worked this way since time immemorial. Do internal Google services exclusively use the Google Cloud Platform APIs? The implication is that internal Amazon services exclusively use AWS APIs. I've never worked at either company though, so I don't know if it's true. Perhaps someone could clarify.
- hello_moto 7y ago
  > The implication is that internal Amazon services exclusively use AWS APIs. Untrue. Some even use older version of AWS "core" services (S3), not the latest and greatest version of AWS services.
  - dastbe 7y ago
    though in some cases I can think of, the "legacy" service is now just a facade over an AWS service.
- xyzzyz 7y ago
  No, because internal APIs for the same backends are more powerful and easier to integrate with. It's not easy to make the external APIs as useful and powerful as internal ones: for one, you can trust your users more to do the right thing and not try to exploit you for profit, it's much less committment to offer certain functionalities, since it's easier to roll them back if only users are internal, etc. Google is slowly getting there in feature parity, but so much effort has been invested in Google internal ecosystem even before GCP has even existed that, as good as GCP is, nobody wants to bet on it when obviously superior alternative is available.
  - triceratops 7y ago
    > for one, you can trust your users more to do the right thing and not try to exploit you for profit, it's much less committment to offer certain functionalities, since it's easier to roll them back if only users are internal, "Organizing into services taught teams not to trust each other in most of the same ways they're not supposed to trust external developers." - from Steve Yegge's Platforms Rant[1] 1. https://gist.github.com/chitchcock/1281611 https://gist.github.com/chitchcock/1281611
  - foxtr0t 7y ago
    Define "nobody." If you check earnings you'll be surprised to see GCP is quickly growing, even if it is a few years behind AWS. For large customers, their deployments are increasingly becoming platform agnostic, meaning they shop for price, not platform. Yegge's post, while relevant to almost every cloud customer at the time, is less relevant to large customers that can avoid lock-in today.
    - xyzzyz 7y ago
      I am talking about people working inside Google, not customers, as should be apparent from context.
gowld 7y ago
A protocol buffer is a serialized data object, not a service API. It doesn't (and didn't) prevent anyone from using shared memory, shared database, or shared flat files to communicate. Also, 2002 is time immemorial. Google was founded in 1998.Protocol buffers were invented in 2001.
- username90 7y ago
  Protocol buffers are both serialized data objects and service API's. https://developers.google.com/protocol-buffers/docs/proto#services https://developers.google.com/protocol-buffers/docs/proto#se...
- atombender 7y ago
  Protobufs were invented for Stubby, the RPC layer which is apparently used for absolutely everything inside Google. It's existed since at least 2001, and uses protobufs as the RPC serialization. gRPC is based on Stubby (though not the actual implementation).
  - repolfx 7y ago
    Yeah. Google is actually a much better example of this mentality than Amazon is, if I'm reading the thread right. Google Cloud isn't behind AWS because of some service architecture nonsense. It's behind because Google started later, and it started later because for the longest time (I was there) the senior management had the following attitude: "Why would we sell our cloud platform? We can always make more money and have higher leverage by running our own services on it and monetising with ads; merely selling hardware and software services is a comparatively uninteresting and low margin business." Selling Google's platform (and it really is a platform) is an obvious idea that occurred to everyone who was there. It didn't happen because of explicit executive decision, not because Bezos was some kind of savant. I think Google could have really dominated the cloud space if they'd been a bit more strategic. The problems were all cultural, not technological. For instance they are culturally averse to trusted partnerships of any kind (not just Google of course, that's a tech industry thing). There are only two levels of trust: - Internal employee, nearly fully trusted. - External person or firm, assumed to be a highly skilled malicious attacker There's nothing in between. So if your infrastructure can't handle the most sophisticated attack you can think of, it can't be externalised at all. If it can't scale automatically to a million customers overnight, it can't be externalised at all. There's really no notion in Google's culture of "maybe we should manually vet companies and give them slightly lower trust levels than our employees in return for money". It's seen as too labour intensive and not scalable enough to be interesting. But it'd have allowed them to dominate cloud technology years earlier than AWS or Azure.
closeparen 7y ago
Lots of places will use APIs between teams, but the APIs aren’t primary. An integration still starts with a document and a kickoff meeting. You might need to post config or even code changes to the platform, which the platform team will review and deploy at their own pace, before the endpoint is usable. Interfaces and schemas have use case specific fields in them. It’s not at all like using an AWS service.

by xyzzyz 7y ago

defen 7y ago

> Google has worked this way since time immemorial. Do internal Google services exclusively use the Google Cloud Platform APIs? The implication is that internal Amazon services exclusively use AWS APIs. I've never worked at either company though, so I don't know if it's true. Perhaps someone could clarify.

hello_moto 7y ago
> The implication is that internal Amazon services exclusively use AWS APIs. Untrue. Some even use older version of AWS "core" services (S3), not the latest and greatest version of AWS services.
- dastbe 7y ago
  though in some cases I can think of, the "legacy" service is now just a facade over an AWS service.
xyzzyz 7y ago
No, because internal APIs for the same backends are more powerful and easier to integrate with. It's not easy to make the external APIs as useful and powerful as internal ones: for one, you can trust your users more to do the right thing and not try to exploit you for profit, it's much less committment to offer certain functionalities, since it's easier to roll them back if only users are internal, etc. Google is slowly getting there in feature parity, but so much effort has been invested in Google internal ecosystem even before GCP has even existed that, as good as GCP is, nobody wants to bet on it when obviously superior alternative is available.
- triceratops 7y ago
  > for one, you can trust your users more to do the right thing and not try to exploit you for profit, it's much less committment to offer certain functionalities, since it's easier to roll them back if only users are internal, "Organizing into services taught teams not to trust each other in most of the same ways they're not supposed to trust external developers." - from Steve Yegge's Platforms Rant[1] 1. https://gist.github.com/chitchcock/1281611 https://gist.github.com/chitchcock/1281611
- foxtr0t 7y ago
  Define "nobody." If you check earnings you'll be surprised to see GCP is quickly growing, even if it is a few years behind AWS. For large customers, their deployments are increasingly becoming platform agnostic, meaning they shop for price, not platform. Yegge's post, while relevant to almost every cloud customer at the time, is less relevant to large customers that can avoid lock-in today.
  - xyzzyz 7y ago
    I am talking about people working inside Google, not customers, as should be apparent from context.

gowld 7y ago

A protocol buffer is a serialized data object, not a service API. It doesn't (and didn't) prevent anyone from using shared memory, shared database, or shared flat files to communicate. Also, 2002 is time immemorial. Google was founded in 1998.Protocol buffers were invented in 2001.

username90 7y ago
Protocol buffers are both serialized data objects and service API's. https://developers.google.com/protocol-buffers/docs/proto#services https://developers.google.com/protocol-buffers/docs/proto#se...
atombender 7y ago
Protobufs were invented for Stubby, the RPC layer which is apparently used for absolutely everything inside Google. It's existed since at least 2001, and uses protobufs as the RPC serialization. gRPC is based on Stubby (though not the actual implementation).
- repolfx 7y ago
  Yeah. Google is actually a much better example of this mentality than Amazon is, if I'm reading the thread right. Google Cloud isn't behind AWS because of some service architecture nonsense. It's behind because Google started later, and it started later because for the longest time (I was there) the senior management had the following attitude: "Why would we sell our cloud platform? We can always make more money and have higher leverage by running our own services on it and monetising with ads; merely selling hardware and software services is a comparatively uninteresting and low margin business." Selling Google's platform (and it really is a platform) is an obvious idea that occurred to everyone who was there. It didn't happen because of explicit executive decision, not because Bezos was some kind of savant. I think Google could have really dominated the cloud space if they'd been a bit more strategic. The problems were all cultural, not technological. For instance they are culturally averse to trusted partnerships of any kind (not just Google of course, that's a tech industry thing). There are only two levels of trust: - Internal employee, nearly fully trusted. - External person or firm, assumed to be a highly skilled malicious attacker There's nothing in between. So if your infrastructure can't handle the most sophisticated attack you can think of, it can't be externalised at all. If it can't scale automatically to a million customers overnight, it can't be externalised at all. There's really no notion in Google's culture of "maybe we should manually vet companies and give them slightly lower trust levels than our employees in return for money". It's seen as too labour intensive and not scalable enough to be interesting. But it'd have allowed them to dominate cloud technology years earlier than AWS or Azure.

closeparen 7y ago

Lots of places will use APIs between teams, but the APIs aren’t primary. An integration still starts with a document and a kickoff meeting. You might need to post config or even code changes to the platform, which the platform team will review and deploy at their own pace, before the endpoint is usable. Interfaces and schemas have use case specific fields in them. It’s not at all like using an AWS service.