7 ms·

Having worked at both places for ~4 years each, I would say Amazon is much more of a product company, and a platform is really a collection of compelling produc

Having worked at both places for ~4 years each, I would say Amazon is much more of a product company, and a platform is really a collection of compelling products. Amazon really puts customers first. Their platform and organization are made up of small teams that own services with well-defined interfaces, accountable for customer metrics. All profits are reinvested, so resources and perks are scarce, efficiency matters, and management is tight. The platform emerged because internal teams thought of their infrastructure services as products with customers. Google really puts ideas (or technology) first; it aims to hire the smartest people and rewards them for launching new things and solving complex problems rather than optimizing UX or making customers happy. Resources are ample and management is loose, so individual contributors can try new things with greater leisure. It's been compared to grad school. But simplifying customer experience is less of a priority, so the internal infrastructure was notoriously complex and hard to use. They're now learning to prioritize customers, but it's hard to change culture. Of course, both companies are huge and diverse and evolving, so you'll find plenty of variance. App Engine wasn't evidence of Google being a product company, nor does it exemplify the company's strategy. It was a grassroots project that for years didn't receive much leadership support, but was still allowed to launch and grow.

findjashua 10y ago
"rather than optimizing UX or making customers happy" as someone who's dabbled a bit w both, I found GCP UI/UX to be far simpler than dealing w AWS
mathattack 10y ago
Great point on simplifying the UI being a priority. This takes a lot of coordination and willingness to say "We will drop features A, B and C to make the overall experience easier." This is ultimately both an organizational and cultural issue. Some companies optimize on centralization (historically Apple) while others have a more decentralized "empower the individual" ethos. This article from the same source highlights how Apple's centralized org is core to it's view of product integration. https://stratechery.com/2016/apples-organizational-crossroads/ https://stratechery.com/2016/apples-organizational-crossroad... When dealing with a platform, this user experience coordination becomes much more important. (Think the old Apple ecosystem versus all the crap that came pre-installed on the Wintel systems)
Rapzid 10y ago
AWS has fallen flat in the past with cross-service initiatives. Tagging and IAM keys come to mind. I haven't personally used Google much but from what I hear their stuff is a bit more cohesive.. This new Org stuff might be a recent exception though; I haven't read through it all and tested it to know. Hopefully.
- dzhiurgis 10y ago
  Reading GCP documentation is a delight. Reading AWS documentation feels like reading Salesforce's documentation.
  - Rapzid 10y ago
    Haha, I have never read Salesforce docs.. I must say though that I'm pretty happy with their docs. Sure, they are dense. However, they have most of what you need if you spend the time to read them. I MUCH prefer comprehensive docs to those that are lacking..
btilly 10y ago
I would state the tradeoff very differently. Amazon gives each team independence. Therefore it is virtually impossible to insist on consistency between what different teams do. Each team makes sense on its own, but the whole can be very, very confusing. Google has a process that results in much greater internal consistency. It may not be a great UX, but it is consistent. Inside and out. For small systems, Amazon is going to give a better UX. But for a complex system, I prefer what Google will produce.
- skynetv2 10y ago
  as a long time Google user, I find it pretty ironic to use consistency and Google in the same sentence. If consistency exists internally at Google, none of it made in to their products unfortunately.
  - spiderfarmer 10y ago
    It's improving, but you still run into some of the interfaces that were designed 8 years ago. But Microsoft is far worse in that department.
- serge2k 10y ago
  > But for a complex system, I prefer what Google will produce Having worked there in teams near to their tablets I really think Amazon would have a hard time producing software of the complexity of Android or Chrome.
  - newjersey 10y ago
    I have a question. Do you think this Amazon culture is the cause or the result of service-oriented architecture at Amazon? Or maybe am I completely off the mark here. I found this quote from SEC filings. Jeff Bezos says: > Service-oriented architecture -- or SOA -- is the fundamental building abstraction for Amazon technologies. This was in 2010. https://www.sec.gov/Archives/edgar/data/1018724/000119312511110797/dex991.htm https://www.sec.gov/Archives/edgar/data/1018724/000119312511... It sounds like they have been committed to it at least since 2005? https://s3.amazonaws.com/aws001/trailhead/MigratingAmazonComToAWS.PDF https://s3.amazonaws.com/aws001/trailhead/MigratingAmazonCom... I'd imagine internally it'd have to be a lot sooner than that because I think they were ready to release AWS by 2006. Sorry, I don't mean to start a holy war. I just wonder if there's any connection... What do you think?
user5994461 10y ago
> App Engine wasn't evidence of Google being a product company, nor does it exemplify the company's strategy. It was a grassroots project that for years didn't receive much leadership support, but was still allowed to launch and grow. App Engine was a precursor that came 5 years too early. The hype about serverless is only starting now.
- iainmerrick 10y ago
  Was it really just "too early"? I always thought App Engine was a fantastic idea, and I wondered why it never seemed to catch on. Choice of languages -- initially just Python and Java? Fiddly APIs, different from competing platforms but not actually super-simple for simple tasks? Lack of a straightforward way of running background tasks (still a bit of a mess)? Lack of management support? Maybe just underpowered at first for large sites, and insufficiently compelling for small sites to build a loyal fanbase? I just built a new, very small project in App Engine (Python, standard environment). It works fine but the tools are quite fiddly. There are plenty of docs but they're a bit of a trainwreck, in the classic Google "the old way is deprecated, but the new way is still in beta" way (e.g. standard versus flexible environments).
  - acdha 10y ago
    App Engine seems to me like the classic Google product: some cool ideas but the initial experience was clunky and the pricing model scared people, especially since you were locking yourself into a proprietary architecture. Google engineers could point to various things it did to help with future scaling needs and took the advantages of things like the NoSQL data model for granted but everyone I knew who didn't work for Google was generally asking questions like “How long would it take to migrate if they cancel the service?” or “What's my coping strategy if they have another major outage?”. I think a little time invested on customer service and user experience would have gone a long way.
    - iainmerrick 10y ago
      I just realised there was another problem: no internal customers. If there had been an important team inside Google keen on using App Engine, that might have helped them figure out the right feature set. But instead they were just guessing at what users outside Google might want. (Compare to Gmail, which was and is very heavily used inside Google.)
ben_jones 10y ago
App engine is the biggest enigma. On paper it is a near perfect cloud experience. It has a huge range of services covering the needs of most web applications: task queues, caching, RDBMS, storage, monitoring, logging, a fantastic dashboard; the list goes on and the scope of GCP and GAE in general is truly massive. At first glance the documentation is exhaustive, support quick, and you get the feeling that the product has the full backing of Google with many hundreds of engineers continually improving and iterating. Yet then you get into the trenches of it and (IMO) you realize the sum of its parts is much less then the value of the individual pieces. You feel the pain of the documentation writers who had to transcribe examples and helper libraries to ten languages, "beta" features that have been out for years, "examples coming soon" in README's that are two years old. Want to use python3? That's cool, use the flexible environment. But it doesn't support taskqueues or many other features. Need websockets? Thats cool, we kinda have this socket API and similar for some languages and environments. It doesn't really work in the flexible environment though sorry :X. All our python examples are in framework X, that's sufficient for everyone using framework Y, right? Don't get me wrong, my company uses GAE and its benefits outweigh the costs for us. But there is a very real "Googliness" to the failings of the platform. The shear breadth and requirements of "fixing" and iterating on GAE must not be a very fun project to work on.
- waprin 10y ago
  > All our python examples are in framework X, that's sufficient for everyone using framework Y, right? I work on GCP on the Python samples. We generally pick Flask, since our thinking is that for many API calls, it is pretty much identical code in other frameworks, and Flask has minimal boilerplate. We have quick starts for Django for all our platforms. I think Flask + Django covers a huge chunk of Python frameworks people are using. If you think we are missing important Python samples, you can file an issue here: https://github.com/googlecloudplatform/python-docs-samples https://github.com/googlecloudplatform/python-docs-samples There are a lot of potential samples to write, so any guidance on which ones people want is always helpful to us.
  - ben_jones 10y ago
    Thanks for your comment and I want to say, though my comment was rather pointy, I respect the work all of you are doing and I do see a lot of improvement in the platform. I keep a local branch of the python-docs-sample repo and just took a gander to refresh my memory. Specifically I see a quite a few examples using class based views based from the webapp2 package. I don't think it's unreasonable to have this as a major reference point, but it does require some extra documentation reading when converting to say, function based views in Flask. Our personal use case is python3 in the flexible environment and I'd like to point out two notes while I have you here (if it's appropriate): 1) Are task queues coming to GAE Flexible environment - python? (and more over is feature parity coming between the google.appengine and google.cloud packages) 2) It's undocumented that the flexible environment of python requires a specific configuration variable to be set in order to make a connection to cloudSQL. I raised a support ticket for it a few weeks ago and the documentation hasn't been changed. It took me a few hours to debug it personally and I would like to save others the effort, can users make a pull request on the docs directly? For reference the variable is "beta_settings: cloud_sql_instances:" in app.yaml (it's present in the python-docs-samples but has no comment explaining its significance/requirement). EDIT: I can no longer edit my original comment, but it seems GAE flexibly environment for python does support web sockets, though I would question the effectiveness of stateful servers in GAE. Of course thats an implementation problem and not one with GAE.
jimbokun 10y ago
"Their platform and organization are made up of small teams that own services with well-defined interfaces, accountable for customer metrics." You are using the terminology of products and platforms with the exact opposite meaning of the article's author. Those "services with well-defined interfaces" become a platform others can use to build their own products. Similarly with the e-commerce and fulfillment infrastructure third party sellers can use. And maybe the transportation infrastructure in the future. I also think you vastly underestimate the quality of Google's UX. Type any thing you can think of into one simple box, and you get surprisingly useful auto-completions, relevant spelling corrections, and almost always find the answer to the question you had when you started typing. There are any number of complex back end services working in parallel to resolve your query, with results gathered, ranked, merged, and rendered in a fraction of a second. Pretty hard to beat that user experience. This is how the author defines product focus, emphasis on combining many components internally to provide an outstanding end user experience, without necessarily making the components available to be used by others to create their own user experience for their customers.
- seregine 10y ago
  Products and platforms overlap quite a bit, e.g. many enterprise products can be thought of as platforms, or AdSense and Android. That's why I think it's less useful to contrast the two companies on a product vs. platform axis, and why I find the cultural differences more interesting. Google does make great products, especially when it's a matter of presenting a simple elegant interface to a complex internal system. I'm a big fan of Google Search and Maps UX, and Google Now. But the UX of a product isn't just its immediate interface, it's also all the interactions you have with support, documentation, and change over time, and trust. The cultural differences are more evident there, though some teams at Google are getting pretty good at these things as well.
mdani 10y ago
This is changing - I got a call from Google Cloud sales/support today. I am just using the GCP for prototyping so I have spent maybe $50 on it so far. Looks like they're stepping up their gane and really trying to be helpful and willing to listen to customers.

findjashua 10y ago

"rather than optimizing UX or making customers happy" as someone who's dabbled a bit w both, I found GCP UI/UX to be far simpler than dealing w AWS

mathattack 10y ago

Great point on simplifying the UI being a priority. This takes a lot of coordination and willingness to say "We will drop features A, B and C to make the overall experience easier." This is ultimately both an organizational and cultural issue. Some companies optimize on centralization (historically Apple) while others have a more decentralized "empower the individual" ethos. This article from the same source highlights how Apple's centralized org is core to it's view of product integration. https://stratechery.com/2016/apples-organizational-crossroads/ https://stratechery.com/2016/apples-organizational-crossroad... When dealing with a platform, this user experience coordination becomes much more important. (Think the old Apple ecosystem versus all the crap that came pre-installed on the Wintel systems)

Rapzid 10y ago

AWS has fallen flat in the past with cross-service initiatives. Tagging and IAM keys come to mind. I haven't personally used Google much but from what I hear their stuff is a bit more cohesive.. This new Org stuff might be a recent exception though; I haven't read through it all and tested it to know. Hopefully.

dzhiurgis 10y ago
Reading GCP documentation is a delight. Reading AWS documentation feels like reading Salesforce's documentation.
- Rapzid 10y ago
  Haha, I have never read Salesforce docs.. I must say though that I'm pretty happy with their docs. Sure, they are dense. However, they have most of what you need if you spend the time to read them. I MUCH prefer comprehensive docs to those that are lacking..

btilly 10y ago

I would state the tradeoff very differently. Amazon gives each team independence. Therefore it is virtually impossible to insist on consistency between what different teams do. Each team makes sense on its own, but the whole can be very, very confusing. Google has a process that results in much greater internal consistency. It may not be a great UX, but it is consistent. Inside and out. For small systems, Amazon is going to give a better UX. But for a complex system, I prefer what Google will produce.

skynetv2 10y ago
as a long time Google user, I find it pretty ironic to use consistency and Google in the same sentence. If consistency exists internally at Google, none of it made in to their products unfortunately.
- spiderfarmer 10y ago
  It's improving, but you still run into some of the interfaces that were designed 8 years ago. But Microsoft is far worse in that department.
serge2k 10y ago
> But for a complex system, I prefer what Google will produce Having worked there in teams near to their tablets I really think Amazon would have a hard time producing software of the complexity of Android or Chrome.
- newjersey 10y ago
  I have a question. Do you think this Amazon culture is the cause or the result of service-oriented architecture at Amazon? Or maybe am I completely off the mark here. I found this quote from SEC filings. Jeff Bezos says: > Service-oriented architecture -- or SOA -- is the fundamental building abstraction for Amazon technologies. This was in 2010. https://www.sec.gov/Archives/edgar/data/1018724/000119312511110797/dex991.htm https://www.sec.gov/Archives/edgar/data/1018724/000119312511... It sounds like they have been committed to it at least since 2005? https://s3.amazonaws.com/aws001/trailhead/MigratingAmazonComToAWS.PDF https://s3.amazonaws.com/aws001/trailhead/MigratingAmazonCom... I'd imagine internally it'd have to be a lot sooner than that because I think they were ready to release AWS by 2006. Sorry, I don't mean to start a holy war. I just wonder if there's any connection... What do you think?

user5994461 10y ago

> App Engine wasn't evidence of Google being a product company, nor does it exemplify the company's strategy. It was a grassroots project that for years didn't receive much leadership support, but was still allowed to launch and grow. App Engine was a precursor that came 5 years too early. The hype about serverless is only starting now.

iainmerrick 10y ago
Was it really just "too early"? I always thought App Engine was a fantastic idea, and I wondered why it never seemed to catch on. Choice of languages -- initially just Python and Java? Fiddly APIs, different from competing platforms but not actually super-simple for simple tasks? Lack of a straightforward way of running background tasks (still a bit of a mess)? Lack of management support? Maybe just underpowered at first for large sites, and insufficiently compelling for small sites to build a loyal fanbase? I just built a new, very small project in App Engine (Python, standard environment). It works fine but the tools are quite fiddly. There are plenty of docs but they're a bit of a trainwreck, in the classic Google "the old way is deprecated, but the new way is still in beta" way (e.g. standard versus flexible environments).
- acdha 10y ago
  App Engine seems to me like the classic Google product: some cool ideas but the initial experience was clunky and the pricing model scared people, especially since you were locking yourself into a proprietary architecture. Google engineers could point to various things it did to help with future scaling needs and took the advantages of things like the NoSQL data model for granted but everyone I knew who didn't work for Google was generally asking questions like “How long would it take to migrate if they cancel the service?” or “What's my coping strategy if they have another major outage?”. I think a little time invested on customer service and user experience would have gone a long way.
  - iainmerrick 10y ago
    I just realised there was another problem: no internal customers. If there had been an important team inside Google keen on using App Engine, that might have helped them figure out the right feature set. But instead they were just guessing at what users outside Google might want. (Compare to Gmail, which was and is very heavily used inside Google.)

ben_jones 10y ago

App engine is the biggest enigma. On paper it is a near perfect cloud experience. It has a huge range of services covering the needs of most web applications: task queues, caching, RDBMS, storage, monitoring, logging, a fantastic dashboard; the list goes on and the scope of GCP and GAE in general is truly massive. At first glance the documentation is exhaustive, support quick, and you get the feeling that the product has the full backing of Google with many hundreds of engineers continually improving and iterating. Yet then you get into the trenches of it and (IMO) you realize the sum of its parts is much less then the value of the individual pieces. You feel the pain of the documentation writers who had to transcribe examples and helper libraries to ten languages, "beta" features that have been out for years, "examples coming soon" in README's that are two years old. Want to use python3? That's cool, use the flexible environment. But it doesn't support taskqueues or many other features. Need websockets? Thats cool, we kinda have this socket API and similar for some languages and environments. It doesn't really work in the flexible environment though sorry :X. All our python examples are in framework X, that's sufficient for everyone using framework Y, right? Don't get me wrong, my company uses GAE and its benefits outweigh the costs for us. But there is a very real "Googliness" to the failings of the platform. The shear breadth and requirements of "fixing" and iterating on GAE must not be a very fun project to work on.

waprin 10y ago
> All our python examples are in framework X, that's sufficient for everyone using framework Y, right? I work on GCP on the Python samples. We generally pick Flask, since our thinking is that for many API calls, it is pretty much identical code in other frameworks, and Flask has minimal boilerplate. We have quick starts for Django for all our platforms. I think Flask + Django covers a huge chunk of Python frameworks people are using. If you think we are missing important Python samples, you can file an issue here: https://github.com/googlecloudplatform/python-docs-samples https://github.com/googlecloudplatform/python-docs-samples There are a lot of potential samples to write, so any guidance on which ones people want is always helpful to us.
- ben_jones 10y ago
  Thanks for your comment and I want to say, though my comment was rather pointy, I respect the work all of you are doing and I do see a lot of improvement in the platform. I keep a local branch of the python-docs-sample repo and just took a gander to refresh my memory. Specifically I see a quite a few examples using class based views based from the webapp2 package. I don't think it's unreasonable to have this as a major reference point, but it does require some extra documentation reading when converting to say, function based views in Flask. Our personal use case is python3 in the flexible environment and I'd like to point out two notes while I have you here (if it's appropriate): 1) Are task queues coming to GAE Flexible environment - python? (and more over is feature parity coming between the google.appengine and google.cloud packages) 2) It's undocumented that the flexible environment of python requires a specific configuration variable to be set in order to make a connection to cloudSQL. I raised a support ticket for it a few weeks ago and the documentation hasn't been changed. It took me a few hours to debug it personally and I would like to save others the effort, can users make a pull request on the docs directly? For reference the variable is "beta_settings: cloud_sql_instances:" in app.yaml (it's present in the python-docs-samples but has no comment explaining its significance/requirement). EDIT: I can no longer edit my original comment, but it seems GAE flexibly environment for python does support web sockets, though I would question the effectiveness of stateful servers in GAE. Of course thats an implementation problem and not one with GAE.

jimbokun 10y ago

"Their platform and organization are made up of small teams that own services with well-defined interfaces, accountable for customer metrics." You are using the terminology of products and platforms with the exact opposite meaning of the article's author. Those "services with well-defined interfaces" become a platform others can use to build their own products. Similarly with the e-commerce and fulfillment infrastructure third party sellers can use. And maybe the transportation infrastructure in the future. I also think you vastly underestimate the quality of Google's UX. Type any thing you can think of into one simple box, and you get surprisingly useful auto-completions, relevant spelling corrections, and almost always find the answer to the question you had when you started typing. There are any number of complex back end services working in parallel to resolve your query, with results gathered, ranked, merged, and rendered in a fraction of a second. Pretty hard to beat that user experience. This is how the author defines product focus, emphasis on combining many components internally to provide an outstanding end user experience, without necessarily making the components available to be used by others to create their own user experience for their customers.

seregine 10y ago
Products and platforms overlap quite a bit, e.g. many enterprise products can be thought of as platforms, or AdSense and Android. That's why I think it's less useful to contrast the two companies on a product vs. platform axis, and why I find the cultural differences more interesting. Google does make great products, especially when it's a matter of presenting a simple elegant interface to a complex internal system. I'm a big fan of Google Search and Maps UX, and Google Now. But the UX of a product isn't just its immediate interface, it's also all the interactions you have with support, documentation, and change over time, and trust. The cultural differences are more evident there, though some teams at Google are getting pretty good at these things as well.

mdani 10y ago

This is changing - I got a call from Google Cloud sales/support today. I am just using the GCP for prototyping so I have spent maybe $50 on it so far. Looks like they're stepping up their gane and really trying to be helpful and willing to listen to customers.