Do other (Silicon Valley) companies do the same?
The 2002 mandate for internal communication systems at Amazon
121–130 of 187 posts
Re: The 2002 mandate for internal communication systems at Amazon
#122Earlier quoted context omitted.
A queue if you're lucky! There's also: - Hire an intern / "Customer Service Representative" / "Technical Account Specialist" to manually copy data from one service into another - Dump some file in a directory and hope something is treating that directory like a queue - Read/write from the same database (/ same table) Or the classic Unix trajectory of increasingly bad service communication: - Read/write from the same…
> Dump some file in a directory and hope something is treating that directory like a queue Or it's unencrypted files on an FTP server containing literally the lifeblood of the American economy: https://engineering.gusto.com/how-ach-works-a-developer-pers... -_-
ACH is not the lifeblood of the American economy. If you removed ACH there would be unimaginable distruption but I can't see that economic activity would completely cease. I think the lifeblood of the American economy is our population.
Re: The 2002 mandate for internal communication systems at Amazon
#123Earlier quoted context omitted.
Some methods I've commonly seen in Enterprise Duct Tape: Screen scrape the other service and do data exchange via a Selenium script. Directly interact with the other service's database. CSV files and nightly batch jobs.
I raise you a service which gets it's configuration from a table on confluence page
It's funny to think about but the reality is that it's better than a lot of other options.
- The page has automatic history & merge conflict resolution - There's built-in role-based security to control both visibility and actions (read-only vs. read-write) - You can work on a draft and then "deploy" by publishing your changes - You can respond to hooks/notifications when the page is updated
Considering that the alternative is either editing a text file on disk or teaching business users to use git, a Confluence page is not so bad.
Re: The 2002 mandate for internal communication systems at Amazon
#124Earlier quoted context omitted.
How do services talk to each other without an API? Is it something like "put a non-well-documented object into a queue?"
A queue if you're lucky! There's also: - Hire an intern / "Customer Service Representative" / "Technical Account Specialist" to manually copy data from one service into another - Dump some file in a directory and hope something is treating that directory like a queue - Read/write from the same database (/ same table) Or the classic Unix trajectory of increasingly bad service communication: - Read/write from the same…
Don't forget the most important step.
"Think of the acronym CSV. Don't look up the definition of the format, just meditate on the idea of the format for a bit. Then write your data in the format you have just imagined is CSV, making whatever choices you feel personally best or most elegant regarding character escapes. Pass this file on to your downstream readers, assuring them it is a CSV file, without elaborating on how you have redefined that."
Re: The 2002 mandate for internal communication systems at Amazon
#125Earlier quoted context omitted.
Not sure about execs, but this happens in engineering meetings (regarding new features being implemented or other semi-major changes). Whoever is initiating the meeting writes up a paper describing the terminology, the nature of the change and why it's needed, how it will be implemented etc. The entire dev team (+ maybe other dev teams within the group), management (the initiator's boss + 1 level above, maybe other d…
That sounds like a low-fi, synchronous, in-person version of reviewing a Google Doc (with comments, suggestions, etc).
Sounds better than the alternative, which I'm all too familiar with.
"Did everyone get a chance to read the doc I added to the calendar entry last night? No? Ok, I'll just review the main points. So for starters, let's go talk about why we're here...."
Re: The 2002 mandate for internal communication systems at Amazon
#126At a previous company, a senior manager took Yegge’s blog post and presented it internally as his own original work.
Hilarity ensued.
Re: The 2002 mandate for internal communication systems at Amazon
#127Earlier quoted context omitted.
I have to ask. Isn't this just microservices ? Also isn't this terrible for latency and debugging ?
> 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 potentia…
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.
Re: The 2002 mandate for internal communication systems at Amazon
#128Found the original post from Yegge a really interesting and thought provoking read. Didn’t realise from the context that he originally accidentally posted it as a public rather than private Google+ post!
His follow up post explaining this, and with an interesting anecdote about presenting to Jeff Bezos, is archived here (seeing as G+ has, ironically (or not) given the context, shut down): https://gist.github.com/dexterous/1383377#file-the-post-retr...
Re: The 2002 mandate for internal communication systems at Amazon
#129Yegge's post was very interesting reading, and I took similar learnings away from it. I was at Amazon at the time, however, and there were things that certainly weren't true any more: >3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service inte…
I have to ask. Isn't this just microservices ? Also isn't this terrible for latency and debugging ?
> 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=microser...
Re: The 2002 mandate for internal communication systems at Amazon
#130Leonardo Federico needs to take a penmanship class.