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.

Hi! I’m Rich, the blog post author.

Thanks for the candid feedback :-)

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.

Rich.

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.

Thanks again for the feedback! Rich.

Somehow the recommendations feel like you are making them to the reader, and in that regards it doesn't feel right to just recommend AWS. Other public clouds provide equivalent or sometimes even better services.

Hi, Rich, blog author here again.

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

Hi Rich, thanks for the response. I guess I just found it a bit hard to see the lines between "here's a good strategy" and "here's our strategy". Where you are writing "we have a tiered set of recommendations for who to outsource to", you could add something like "for our developers, ..." or "at Intercom, ..." and it would be much better placed into context.

Otherwise I really enjoyed the article, it resonated well with my own thoughts and vision.

thanks again dajonker, that's more good feedback.

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.

Hey all,

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.

Thanks, Rich.

My take based on my experience is,

#1. People get hired for what they are good, their skills and then get promoted (to management) for same technical/IC skills not for the MGMT skills. No MGMT ramp-up. No MGMT tools. No MGMT framework. You are now tasked to lead a team. it's surely will fail.

#2. Next the mindset. Typical mindset when you move from technical (or any IC) role to MGMT and the higher you go in MGMT should completely change.... unfortunately its not so easy to give up the control. MGMT is about making others successful... giving up your control to others is very frightening and often causes identity issues... moving from do it all (as an IC) to ask_and_inspire is not easy...

#3. Assuming you overcome these two... typical problem of MGMT/leadership is they try to find, "What's the matter?" where as the focus should always be on "What matters to you (an individual/ICs in team)"

Hey Rich,

I enjoyed the article and IMHO it did well in encouraging self-awareness and introspection. I hope it goes far.

I liked the "tracking the dust in your phone" part. Hehe