It gives context for the article and immediately creates the possibility of converting people off nothing but the article, right off the gate. Blows my mind that it's one of the first times I see this done.
https://news.ycombinator.com/item?id=22616857
We wrote this piece (well, "they" did; I hadn't joined up with Fly yet --- this piece is part of why I did) but Dan edited it. I got to read the back-and-forth and revisions when I got here and it was bananas how much effort he put in. In blog posts, I just keep doing what he suggested in that Launch piece. Seems to be working?
Go look at all the "Launch HN" pieces. I think a lot of them are comparably informed by Dan.
I'm commenting about this because I think it's super interesting that one of YC's secret weapons is the moderator for HN, who informally moonlights as the editor for YC launch posts, and is spooky good at it.
>>> Moving server apps close to users is a simple way to decrease latency, sometimes by 80% or more.
I am willing to believe, but ... what about all the time I spend cacheing, optimising my SQL indexes, buying new RAM.
Does sending a packet a few thousand extra miles.... oh never mind I think I am answering my own question.
It would be interesting however to have a service that does latency testing for different sites from different locations. Now maybe I could use fly for that?
It's different if you're applying to a university, or you're right out of college, I guess.
(This info gets added automatically to any article I send to my Kindle for later reading.)
And do away with the stupid and annoying teaser pictures that force me to scroll down on a 27" monitor to even see some text.
I think they're called hero images[1]. I think it's okay to have them, but scaling them up with monitor size is a web-design pattern that needs to die IMHO.
It also signals to me it is not battle tested and results in lost sales.
I'll find someone else.
It all seems very well engineered. I worry more about them getting acquired quickly (which is deserved for them but not so much for their customers)
Is it "I invest in people with sound business ideas", or "I invest in people whose approach has historically shown their company will do well", or is it something else?
There are certain people whose skills and judgement I respect, that I feel I know well enough about how they reason about things (as well as you can know following them on the internet), that if they're saying this thing is good, I trust that.
One example is Yehuda Katz, who was a ruby on rails and jQuery core dev team member, now spends most of his time on Ember.js. I may not always agree with him (although it's rare) but I have found that his approach to engineering is just really well-rounded and well-reasoned. So you can totally see how he arrived at his conclusions. Like why to even put time into working on something like Ember.js, rather than joining yet another core team.
Another set of folks are the Hashicorp founders – over the years their approach to the industry and how they build out their solutions has really resonated with me. So I tend to trust just about anything they build.
Similarly, I feel someone like tptacek isn't just a security nerd but is able to articulate where the importance of security fits in with an org, with users, with businesses, with tradeoffs, etc etc etc, and seems to have a clarity in communication that I admire. Similarly, the fact that they are able to so confidently explain every aspect of their stack shows that not only are they proud of what they've accomplished, that they don't feel this is going to hurt them competitively. And the more I read about the stack, the more I keep nodding my head and just smiling at the sheer elegance in how they built it out. And I am actually someone who never really got on the Heroku bandwagon. It just never felt right.
So I'm looking forward to really trying it out.
I completely agree about Hashicorp btw. They are for me one perfect embodiment of the philosophy you outlined: they challenge the current preconceived notions and are severely pushing back against too much complexity.
Same for clarity in communication. Thinking about it, in my 19.5 years of career, I spent the last 3-4 much more in improving my articulation than improving my programming. The latter kind of started happening automatically due to the former. Felt quite pleasantly surprised by that.
So, thank you for existing, really. The world needs more people like you.
Some of our clients have policy that states they won't let themselves be used as a reference site under any circumstances. That includes us mentioning them in promotional literature, except if they specifically agree to (or suggest) some sort of cross-promotion opportunity.
In my experience almost all references to big corporations are being done according to the "ask for forgiveness not permission" principle. So in GP's comment these companies you could also argue are flying closer to the sun according to law.
Edit: from their website "Deploy App Servers Close to Your Users Run your full stack apps (and databases!) all over the world. No ops required."
So: what we're describing isn't some breakthrough in hosting technology --- we're literally shoplifting the engine Amazon wrote to do the same thing --- but rather just explaining how we put these pieces together for our own product.
If I wanted to talk about things that were unique to Fly, I'd talk about our Anycast CDN and the way it automatically plugs into Fly apps, so that they are, out of the box, globally connected. Or about how we manage certificates, which we (I had nothing to do with it) apparently nailed the UX for so well that people use us just for that.
But that wasn't the point of this post; it really was just an effort to talk through some of the technical decisions we made.
It's OK to have a little more background before the start of the article. It's a technical audience, they'll not just take it but as you can see, some will actively ask for it.
I will say that most of our technical choices are informed, and even forced, by customer workloads. Almost everything we've built is the result of "battle".
Even this post – the change to containerd + devicemapper was the result of running a tremendous number of apps AND customers with 8GB+ images who wanted fast deploys.
For some people, the technical detail gives them enough confidence to try it out. And we're totally ok just attracting those people as customers right now.