This is obviously marketing for the author's company. What do the four armies have to do with the point the autor's trying to make? "Hey, you should run as little software as possible. But first let's analyze the professional IT landscape with an analogy that does not make anything clearer but allows us to embed fancy pictures and videos."
This trade-off between (apparent) simplicity and vendor lock-in is a fundamental force in the industry, and is worth talking more plainly about. (Another big area where this affects people is authentication - it's easier (for users) to use Google- and Facebook-backed OAuth, but what are the trade-offs involved? Does this increase my vulnerability in any way?)
I liked the idea behind this article, but it's definitely a missed opportunity. And yeah, as something of a web-minimalist myself the ridiculous page-weight was a rather ironic touch.
I guess that is the peril of content marketing in a narrow field - eventually you run out of fresh takes but still need to attract eyeballs. Hence the Buzzfeed-style headlines.
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.
Yes, I know - wrong medium for presentation over content.
The post gives an example of switching from self-hosted MongoDB onto AWS DynamoDB. But AWS DynamoDB is proprietary technology, not standard. Amazon doesn't even claim that DynamoDB is standard; they argue that DynamoDB is the best in the world, worth the premium in price. It's not at all "undifferentiated heavy lifting."
It sounds like they made the right decision with DynamoDB, but they did it by violating the pillars of their own philosophy, adopting a differentiated proprietary solution for their scalability problems.
By undifferentiated, they mean outsource anything that doesn't differentiate their own product offering. Build things that give you a competitive advantage over other products in your space. Outsource everything else because wasting work on it won't help you get customers. Of course DynamoDB is differentiated for Amazon, but it's undifferentiated for Intercom...it's just a persistence strategy that customers should never know about.
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!
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
Otherwise I really enjoyed the article, it resonated well with my own thoughts and vision.
At least go with a hosted Mongo solution.
Also, you are incorrect about only being able to index two fields in DynamoDB. Though we luckily don’t need anything other than the primary key.
By what metric is it dumb? We've found that our chat widget dramatically increased contacts, conversions, and is often used for support.
Personally I am not a fan of annoying chat widgets, but they do seem to work well.
Then they started to blink the tab title.
It's one thing that you do irritating stuff to get my attention when I'm actively on the website, but when I'm doing other things? This is right up there with popunder ads, blocking right click, and autoplaying sounds.
Outsourcing to SaaS means trusting your (and your customers) data to lots of different companies. And in the case of SaaS those companies could be small software companies or even one-man operations. This is not very compatible with upcoming data privacy regulations like GDPR. And I suspect that more and more companies are going to be looking at a model where they purchase/license/outsource non-core software but host it themselves in their own datacenter or cloud accounts.
The solution I am working towards in my current project is to build the software from day 1 with dual-mode operations in mind. Easy to host as SaaS but with the option of running Standalone on customer premises with the same codebase. Just different configuration/modules.
Oh and before someone says "we outsource fixing our toilets to plumbers" - in this case we are not event talking about replacing a flap, we are talking about being able to use a plunger.
Sure, I can do all that by myself but that takes time, time that is better spent serving my clients instead of setting up yet another replicated db. It takes me a few minutes to setup an Amazon RDS instance with all that enabled out of the box.
a) do not have service that operates 24x7
b) do not have peopleware needed for 24x7 operations
c) service customers that do not have 24x7 operations
A metric boat load of now shuttered "startups" would have been going concerns providing very nice long term living (and retirement) to their owners had they been optimized for "not spending 109% of revenue for Yet Another Thing We Should Use As a Service".
Oh to have those problems
In our (Intercom) case these tasks are not simple.
We are lucky to have had exponential growth in most metrics (including database throughput) for the entire 7 years of our existence. This is a harsh environment for datastores! A 99.9% SLA makes it even harder.
We are also nowhere near finished building out our vision for the product. We prefer to focus on that instead of operating data stores, which we can pay someone else to do.
Then you need search, so you either build the search yourself, or build on solr/elasticsearch or anything else building on lucene. Then you need a cache, and suddenly you need to worry about cluster setups, choose a cache implementation. Then you end up with a use case which would be easily solved with a persistent queue, or neo4j or whatever, but your on-premise solutions block you.
It sounds simple to have n different backend solutions, and to offer a binary choice - everything built-in and everything not-built in. But usually you end up with about n! * #on-premise different setups and they all end up with their own classes of bugs and difficulties to setup.
See more of my thoughts here:
Personally I have found growth and simplification by replacing the complex with the simple, not necessarily less.
But certainly less software that does many things.
For example, I might replace one monolith app with many command line tools that each do a single job well.
Embracing markdown vs myriad of closed note taking tools has been a boon.
For very early stage startups, I think outsourcing software development can sometimes have merit. If the main point of the software is answering the question, "Do we have a real business here?" then if there isn't a technical cofounder I think outsourcing can be worthwhile as long as you assume that all the outsourced code will be thrown away.
But as soon as the founders are sure it's a real business, I think at that point you have to toss out the oursourced stuff and start building the real code base. Then you're reasonably sure that some of the code you're writing is going to be delivering customer value over the long haul, so it's worth investing in sustainability.
There are other software companies out there, smaller and leaner than Intercom that are eating their lunch by offering similar or a better product at a lower cost. Those companies aren't 'outsourcing undifferentiated heavy lifting' but rather have a lean and talented team that's able to do the heavy lifting themselves without sacrificing on product development.
And many companies used to make outsourcing decisions based off of simple head count cost and didn't factor in the extra time/hours/delays due to integration/poor work/other factors.
> Includes chat, email messaging, customer support, and other interaction tools.
The summary page has some privacy details:
> Data Collected:
> Anonymous (Browser Information, Cookie Data , Date/Time, Page Views )
> Pseudonymous (IP Address (EU PII))
I wish he'd talked more about the four armies and how they played into the choices Intercom has made.
It's worth noting that Aurora is compatible with PostgreSQL (as of Oct 2017) .
Dang: please consider removing the code-block functionality from HN.
The DynamoDB move is certainly a tradeoff, but for us it really makes sense. Moving to it will allow us to:
- scale out this storage layer trivially easily
- shed a ton of operational responsibility
- save lots of money
There are certainly downsides to moving to a proprietary database run by a single proivider, but we’re happy to make that tradeoff.
Also, we’re absolutely not recommending that people move from MongoDB to DynamoDB as some general rule. It just made sense for us at this time.
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.
The goal is to have a framework that's so easy to use that even non-programmers can understand it. I'd really love to hear your thoughts, especially anyone that is new to programming. @jaequery
You don't say!!!!
"But as technology advances and provides us with more advanced software components it devalues and commoditizes what we’re working on and at worst makes us redundant."
Will someone please post a summary?
I also find that type of animation really annoying, even if it didn’t cause problems due to its high resource demand.
As a rule of thumb, I’d say animations should only be used for short-term things. Eternal animations will make a substantial fraction of people’s devices heat up, have fans speed up, &c. I think it is probably most.
And in the case of this article, animations don’t even fit with the art direction which is otherwise delightful.
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.
With the HN comments being here: