7 ms·

Weren't Goodreads bought by Amazon a couple of years ago? If so, they might've been pushed to do the move (to microservices, s3, etc) to comply with corporate g

Weren't Goodreads bought by Amazon a couple of years ago? If so, they might've been pushed to do the move (to microservices, s3, etc) to comply with corporate guidelines/policy not because there wasn't a better/more efficient way to scale.

starchand 8y ago
Yeah 2013. You get goodreads info inside your profile section of the kindle apps.
- deleted 8y ago
  [deleted]
iamsomewalrus 8y ago
There’s no real policy that I’m aware of internally for teams to use microservices. Amazon has a lot of tooling to make it easy to spin up services, however. The first major project after being acquired was to make a pared down Goodreads experience available on the Kindle Paperwhite. Our first services came out of that initiative to provide a buffer between the Kindle traffic and the Goodreads Rails app. That being said I’ll be the first to caution small teams should avoid microservices at first for fear of creating a distributed monolith.
- mooreds 8y ago
  > That being said I’ll be the first to caution small teams should avoid microservices at first for fear of creating a distributed monolith. What is your heuristic for determining when it is the right time to look at microservices?
  - iamsomewalrus 8y ago
    That’s “the question”. I will do my best to bluff through it. Engineering team size: you have teams large enough (~3-4) to own and iterate on a subset of related functionality for the long term. Tooling: you have a builder tools type team that provides a tooling and observability happy path. Traffic scale: you have functionality that operates at 2 or more order of magnitude higher that the rest of your application. Decoupled: you have functionality that can be decoupled from your main app and, most importantly, isn’t required for your main app’s uptime. Like a search service or something. A combination of the above.
- toomuchtodo 8y ago
  Are internal Amazon projects cross charged for their AWS use? Or is it essentially free for internal use?
  - iamsomewalrus 8y ago
    Come join my team and I’ll be happy to spill all the beans!
    - deleted 8y ago
      [deleted]
    - jtloong 8y ago
      Do you guys have internships on the Goodreads team?
      - iamsomewalrus 8y ago
        Absolutely! We have internships in San Francisco and Seattle. Usually, they coincide with the summer, but we on occasion have Fall interns. Reach out to me feeneyj @ amazon if you'd like I can forward you to the right people.
    - deleted 8y ago
      [deleted]
  - ryanianian 8y ago
    Former Amazon employee here. They're cross-charged with lots of internal book-keeping. The rates teams "pay" internally are different from public pricing of course but expensive things externally are still expensive things internally. The cost-accounting used to be (3+ years ago) much more "just looking...no pressure to keep them down", but recently there's been huge efforts to bring internal AWS costs down, especially for EC2 usage. I heard rumors that much of the Prime Day fiasco this year could have been avoided if teams would have been permitted to spin up enough capacity.
    - 8y ago

starchand 8y ago

Yeah 2013. You get goodreads info inside your profile section of the kindle apps.

deleted 8y ago
[deleted]

iamsomewalrus 8y ago

There’s no real policy that I’m aware of internally for teams to use microservices. Amazon has a lot of tooling to make it easy to spin up services, however. The first major project after being acquired was to make a pared down Goodreads experience available on the Kindle Paperwhite. Our first services came out of that initiative to provide a buffer between the Kindle traffic and the Goodreads Rails app. That being said I’ll be the first to caution small teams should avoid microservices at first for fear of creating a distributed monolith.

mooreds 8y ago
> That being said I’ll be the first to caution small teams should avoid microservices at first for fear of creating a distributed monolith. What is your heuristic for determining when it is the right time to look at microservices?
- iamsomewalrus 8y ago
  That’s “the question”. I will do my best to bluff through it. Engineering team size: you have teams large enough (~3-4) to own and iterate on a subset of related functionality for the long term. Tooling: you have a builder tools type team that provides a tooling and observability happy path. Traffic scale: you have functionality that operates at 2 or more order of magnitude higher that the rest of your application. Decoupled: you have functionality that can be decoupled from your main app and, most importantly, isn’t required for your main app’s uptime. Like a search service or something. A combination of the above.
toomuchtodo 8y ago
Are internal Amazon projects cross charged for their AWS use? Or is it essentially free for internal use?
- iamsomewalrus 8y ago
  Come join my team and I’ll be happy to spill all the beans!
  - deleted 8y ago
    [deleted]
  - jtloong 8y ago
    Do you guys have internships on the Goodreads team?
    - iamsomewalrus 8y ago
      Absolutely! We have internships in San Francisco and Seattle. Usually, they coincide with the summer, but we on occasion have Fall interns. Reach out to me feeneyj @ amazon if you'd like I can forward you to the right people.
  - deleted 8y ago
    [deleted]
- ryanianian 8y ago
  Former Amazon employee here. They're cross-charged with lots of internal book-keeping. The rates teams "pay" internally are different from public pricing of course but expensive things externally are still expensive things internally. The cost-accounting used to be (3+ years ago) much more "just looking...no pressure to keep them down", but recently there's been huge efforts to bring internal AWS costs down, especially for EC2 usage. I heard rumors that much of the Prime Day fiasco this year could have been avoided if teams would have been permitted to spin up enough capacity.
  - 8y ago