Hacker News new | ask | show | jobs
by johnonolan 2961 days ago
I do! It's nuanced, and every language decision has benefits and drawbacks. Making a bet on JavaScript/Node.js 5+ years ago was a big risk - a lot of people laughed at us or chastised the decision. A lot of those people are now also rewriting their apps in JavaScript.

When it came to selecting Node, the biggest benefit was that it was notable. If we had said "HEY we're making another blogging platform in, wait for it, PHP!" -- it would likely have been significantly more difficult that the project would've been seen as noteworthy / attracted any users.

Conversely, Node is not without its drawbacks. The ecosystem is young today. It was positively infantile when we started. I don't even think there was a fully formed RSS library. In fact, from a technical point of view, most of what we've built would have been easier to achieve with other tools and frameworks.

Nowadays when we select technology, we tend to go for the oldest most reliable stuff we can find. The sort of stuff that when you have a problem and you google it, there are 5,000 people who have done it before. Because there are only SO many innovation battles you can fight simultaneously.

At one point we tried to rewrite our infrastructure using Docker/Swarm - it was a 9 month project which ultimately got completely cancelled at the last minute. Why? Turns out Docker Swarm doesn't scale above 500 instances and we needed to run about 10,000 for Ghost(Pro). We asked Docker Inc and their response was pretty much "idk lol". So now, especially with our infrastructure, we almost always select the most tried and tested technology. Boring stuff. Stuff that is very, very well understood.

The problem is, it's not cool to talk about how our infrastructure is built on very straightforward LXC containers, managed by HAProxy, connected to a cluster of MySQL servers. The tech isn't bleeding edge enough to hear about on HN, so you end up not hearing about it. But most of our best tech decisions end up being when we choose older technology.

Sorry, this got really long. Did Node.js influence our success? Yes! It made Ghost more popular and also more difficult to build. Would I change it? Definitely not.

3 comments

> The problem is, it's not cool to talk about how our infrastructure is built on very straightforward LXC containers, managed by HAProxy, connected to a cluster of MySQL servers. The tech isn't bleeding edge enough to hear about on HN, so you end up not hearing about it.

And those are exactly the ones I want to hear about.

Like you I find the old, established tech choices to be good. New tech is fun to play with, but when I need to get work done and keep it running (for years) I take old every time.

Please write more on this!

Also, I like the interplay between new/risky tech in one area of your story and established in others. Pushing a manageable number of boundaries.

Woah! That information about Docker is bananas. I've worked on projects with more than 200 VMs. Talk about things that don't show up on HN: scaling issues with popular technology where you never find a solution.
Until fairly recently with docker enterprise, from what I've been able to gather Docker's official stance on Enterpriseā„¢-use has been "don't use docker, use runc, and build / orchestrate / etc it with kubernetes or something" which basically means "rewrite whatever you intend to use". (afaik this all changed with https://blog.docker.com/2018/04/announcing-docker-enterprise... )

Which is fine. "can execute binaries in isolation" and "can schedule rollouts and efficient disk/networking structures across many thousands of instances" are vastly different problems. Even "can deploy to 100s" and "can deploy to 1000s" are quite different, without something targeting 1k+ I wouldn't expect it to handle beyond a couple hundred without compounding issues.

Awesome! I love the combination of HAProxy and LXC containers. It's so great. And even better using Ubuntu's LXD(/LXC), with DNS service/auto discovery built-in. Eg, just reference myghost1.lxd in the haproxy backend config for the LXC target host.