At the time we made the decision, we had a very small number of Postgres DB's in production and a large number of MySQL DB's in production.
We had built up a LOT of excellent operational tooling and expertise to enable us to operate MySQL to a really high standard and didn't have the same tooling/knowledge in place for Postgres.
Also, the Postgres instances were not chosen for any specific, differentiating Postgres features, more because the original developer preferred Postgres to MySQL.
We had recently encountered a few completely avoidable Postgres outages, mainly arising from the fact that they were not covered by the same level of supporting operational tooling that our MySQL DB's had.
We were faced with 2 choices:
1. spend a bunch of time leveling up our tooling and knowledge around Postgres
2. standardize on MySQL and migrate the small number of Postgres instances to MySQL
We chose option 2. And believe it provided the right level of improved operability at the lowest cost.
The icing on the cake was that soon after, AWS Aurora was launched with MySQL-only support (later they did also launch Postgres support for Aurora) which allowed us to get a 5X throughput improvement at a 30% cost reduction. These numbers were not just AWS marketing numbers, we benchmarked them with our workloads and found them to be true.
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
This blog post is somewhat a written summarization of a 25 -> 30 minute conference tech talk that I gave at SRECON-EU last year. It was a real struggle to figure out what to leave in and what to leave out. I didn’t want to arrive at a blog post that takes 30 mins to read :-) So, I can see how the four armies and battlefield analogy might come across as disjointed or unnecessary. There is definitely some context missing from the blog post that was in the talk.
When I was putting together the original talk, the “four armies and battlefield” framing was something I felt was useful to help illustrate how competitive I feel the modern software business landscape is and thus how important it is that your company has the right engineering strategy to help them “win their own battle” / succeed in your chosen market.
Anyway, thanks again for the feedback, hopefully the above provides a little more insight on why I used the four armies framing.
Thanks for taking the time to read our blog post and for sharing your thoughts!
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.
We've deliberately chosen to accept vendor lock-in with AWS. I probably should have made that explicit in the blog post.
We believe that the value we get from going all-in on AWS is greater that the potential negotiating power you may get by staying higher level and having the illusion of low cost switching to GCP or Azure.
This also accepts the risk that if AWS goes down, we go down.
I think both of those are acceptable risks/tradeoffs at this point.
I'm the blog author, Rich Archbold from Intercom. Just to clarify …
I wrote this blog, with the exaggerated / cliched title, to try to speak to the large cohort of over-confident, under-skilled and often lacking-enough-self-awareness, managers out there. I was (and often still am) a member of this cohort. Being a great manager all the time is really hard and almost impossible IMHO.
The goal was to hopefully try and generate some more self-awareness and introspection and thus make life a little fairer, more pleasant, more growth-oriented and hopefully more successful for all concerned.
I wasn't trying to deny or downplay that people also leave their jobs for all of the other reasons highlighted by folks here.