Hacker News Reader

Comment by munns | Hacker News Reader

As the original creator of the presentation referenced by the blog author (later re-delivered by Joel in the linked post) I am super excited to see this still have an impact on people, but I'd say today in 2019 you'd probably do things very differently(as others call out).

Tech has progressed really far and there are tools like Netlify for hosting that would replace 90% of the non-DB parts of this. Cloud providers have also grown drastically and so again a lot of this would/could look a lot lot different.

Fwiw original deck from Spring of 2013, delivered at a VC event and then went on to be the most viewed/shared deck on Slidehare for a bit: https://www.slideshare.net/AmazonWebServices/scaling-on-aws-...

thanks, - munns@AWS

View on HN

Does it look that much different if you exclude solutions that increase vendor lock-in?

On your own metal it looks like it does in this post.

With managed services it looks a world different.

You always pay the vendor. Whether that’s in sweat and tears or in dollars is up to you.

Fwiw, you are almost certainly shooting yourself in the foot by avoiding vendor lockin at stages before 8 revenue figures per year. Your engineering takes longer, is more brittle, and because you’re only using 1 vendor actively, your solution is still vendor locked-in.

Love, ~ Guy who learned his lesson many times

Fwiw: Slack, Lift, AirBnb, Snapchat, Stripe are all 100% public cloud based (in so far as I know). So up through 8+ figures they are still doing it too.

removed Uber as its not 100% cloud (or at least wasn't in the past)

Uber has always been self hosted. Some workloads are on Cloud and migrating more there. I last worked there 2 years ago.

Thank you for clarifying! I know quite a lot has supposedly shifted. Will update my original comment.

I think it depends on the type of vendor lock-in -- sure, the trade off of having a managed Postgres instance is obvious, but it becomes less obvious to me when you're using things like a proprietary queueing or deployment service.

Writing service API integration code instead of code that interfaces directly with the technology that service is doing makes code quite brittle. If/when the vendor deprecates the service, introduces backwards incompatible changes, or abandons development of the product, you're left on the hook to engineer your way out of that problem. Often times that effort is equal to or greater than the effort of an in-house solution in the first place.

I had the same mentality as you until this happened to the SaaS product I work on for a few different services. Now at very least I try to make sure solutions are cloud agnostic.

My use case is that for the past 5 years I’ve built several API integrations in a vendor agnostic way. We never changed vendors.

Actually, we did once and we found that our abstraction was so tightly coupled to the underlying API that we had to remake it anyway. The core concepts between those APIs were just too different.

And I’ve had at least 2 cases where our attempt at being vendor agnostic made the integration completely fail and never work right. To the point the vendor told us “You’re holding it wrong, please stop”

Reply on news.ycombinator.com