(no title)
rich_archbold | 8 years ago
For us, the concept of “standard” technology is not about whether it’s proprietary or open source, more that we have a “standard way of doing things. So in this case it was moving toward saying, “hey, if you’re an engineer at Intercom, and need a scalable key-value store for the thing that you’re building, we think you should lean toward using DynamoDB, rather than any of the other technology options, because that’s the one that we’re committed to making a first developer experience for internally for the long term”.
The reason for having AWS alone as a Tier 1 option is similar. We’re already very heavily invested in making developing on top of AWS a great developer experience at Intercom, and we’re committed to doing so for the long term. Therefore we think that it makes sense for us to advocate for always exploring relevant offerings that put out.
I recognize that I could have elaborated on the philosophy a lot more, there’s always a tension between writing too much and too little. And the philosophy is just that, not dogma and not right or wrong, just trying to give insight into how we think.
Thanks again for the feedback! Rich.
dajonker|8 years ago
rich_archbold|8 years ago
Your feedback is super fair. That is how it comes across in the blog.
In the talk that came before the blog post, I go into a lot more detail here. I have some slides where I explain that these are "our" standard technologies, and are not intended to be "the" standard technologies that everyone should use.
I gave some other examples of perfectly good sets of "standard" technologies which other companies could choose for lots of good reasons.
The main point that I/we were advocating for was that, in our opinion (just an opinion, not dogma, not definitely right or wrong), there are some strong benefits to making deliberate decisions about what technologies you consider standard, safe, easy and fast to use, versus those that are not.
Some of those benefits we see include: 1. speed of technical decision making 2. incentivizing engineers to develop deep technical expertise in specific technologies 3. incentivizing managers to fund training in specific technologies 4. creating fungibility within your engineering team to make it easier for engineers to transfer between teams and come up to speed quickly 5. minimizing ongoing operational overhead as there's fewer technologies that need to be battle-hardened with operational tooling