Why does the title of this keep getting flopped around? It's shifted three or four times today. I thought it was supposed to be the title, or the subtitle, and avoid paraphrasing.
The 2002 mandate for internal communication systems at Amazon
151–160 of 187 posts
Re: The 2002 mandate for internal communication systems at Amazon
#152Earlier quoted context omitted.
> 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.
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 slo…
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.
Re: The 2002 mandate for internal communication systems at Amazon
#153We have robotic baristas here in SF, but no one uses them. Why? People want to have their food prepared and served by a real human being, in most cases. The food tastes better when it's served to you by a real person.
Re: The 2002 mandate for internal communication systems at Amazon
#154Earlier quoted context omitted.
This is one of the niches where (S)FTP and batch processing is still alive and kicking.
Yeah, SFTP + CSV file is still the standard for enterprise software. The problem is that these kinds of things have to be built to the lowest common denominator, which is usually the customer anyway. The customer in enterprise software is usually not a tech company they typically have outdated IT policies and less skilled developers than a pure tech company would have. Even if the developers are capable of doing some…
My experience is that usual reason for RPC-over-SFTP is that it is the only thing that corporate IT security does not control and thus cannot make inflexible. Adding another SOAP/JSON/whatever endpoint tends to be multiyear project, while creating new directory on shared SFTP server is a way to implement the functionality in few hours.
Re: The 2002 mandate for internal communication systems at Amazon
#155Earlier quoted context omitted.
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 slo…
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.
I am talking about people working inside Google, not customers, as should be apparent from context.
Re: The 2002 mandate for internal communication systems at Amazon
#156> doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols
So a jdbc interface and published schema would count?
Re: The 2002 mandate for internal communication systems at Amazon
#157Earlier 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?"
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.
Oh damn you just reminded me. They tried to bring in "Robotics" (e.g. Blue Prism) here. For in-house apps.
Apparently it was so hard to deal with the developers that instead of exposing an API they would automate clicking around on Internet Explorer browser windows.
Thankfully I haven't heard much about it lately.
Re: The 2002 mandate for internal communication systems at Amazon
#158I worked at an organization that had a similar declaration. Here's how it played out: 1. Everyone is super excited for other teams to share their data 2. Everyone wants an exception from sharing their own data because it's too hard or too sensitive to share. 3. Eventually everything gets shared, but it takes 3-4 times longer than it really should.
Yup and getting anyone to write coherent documentation for their new interfaces is like pulling teeth.
Yes, but you'll at least have the API definition. And you work at the same company, so you can show up at the desks of the team responsible and demand answers. And if it breaks in production you get to page them and they have to wake up and help you! The threat of pages is a great way to coerce decent documentation. It's an important principle at Amazon that if a production service has a dependency on you, then you are also a production service. Another benefit of breaking things up into SOA is monitoring individual services. If your API is returning 500s then it's your fault and your problem (at least until you can root cause to one of your own dependencies that's returning 500s, then you can pass the buck).
Re: The 2002 mandate for internal communication systems at Amazon
#159At least as of 3 years ago when I left, the software systems that drove the mandate towards SOA were still massive systems that communicated almost purely through a monolithic Oracle database. It was the software system(s) that was responsible for all automation and accounting at fulfillment centers. This is one of those rare times where I actually think a full rewrite from scratch would have been a better idea.
They got there in the end.
https://aws.amazon.com/solutions/case-studies/amazon-fulfill...
Re: The 2002 mandate for internal communication systems at Amazon
#160Earlier quoted context omitted.
If you have smart employees respectful of other's time it shouldn't be a problem. I would tend to agree with Musk on this one. Processes are often put in place to counteract poor hiring. If you need inefficiency raising processes to defend your business from your own employees, maybe you don't have the right employees.
The problem is if 12 teams all are independently interested in talking to a specific person. Even if that could be condensed in a few meetings organizing it should not fall on the unlucky employee of interest. Handling these complexities of scale are exactly what managers are for.
True, but what you're describing is the exception and not the norm. If it is the norm then the issue is that management has failed to hire enough technical documentation writers.