asenchi

Same, I think this document is fundamental to our industry and understanding complex systems. We have it as a quarterly reminder to review in our Slack. I give it to everyone that makes it past the first couple of interviews when applying and tout its usefulness for thinking through systems design all the time. RIP Dr. Cook.

Never. It never makes sense to me, why would I want to carry around another computer to read? Why can’t I unplug and enjoy my book? I tried it, it sucked and management was even worse.

DragonFlyBSD would be really interesting here as well since its kernel has Light Weight Kernel Threads that use message passing. Similar in shape to Erlang/BEAM. Though I guess you've built the kernel in Erlang... so wrong abstraction.

So we burn the planet up to deploy individually craft UIs on demand? I mean, I've read your comment three times, and I just don't see it. If we end up in that future, we're doomed.

Well many of them you may know in that they made their way into so many systems (though arguably without the refined UX of Heroku) but the two that come up the most and I am teaching others:

* The simpler the interface for the user, the more decisions you can make behind the scenes. A good example here is "git push heroku". Not only is that something every user (bot or human) can run, it is also easy to script, protect, and scale. It keeps the surface area small and the abstraction makes the most sense. The code that was behind that push lasted for quite some time, and it was effectively 1-2 Python classes as a service. But once we got the code into our systems, we could do anything with it... and we did. One of the things that blows my mind is that our "slug" (this is what we called the tarballs of code that we put on the runtimes) maker was itself a heroku app. It lived along side everyone else. We were able to reduce our platform down to a few simple pieces (what we called the kernel) and everything else was deployed on top. We benefited from the very things our customers were using.

* NOTE: This one is going to be hard to explain because it is so simple, but when you start thinking about system design in this way the possibilities start to open up right in front of you. The idea is that everything we do is effectively explained as "input -> filter -> output". Even down to the CPU. But especially when it comes to a platform. With this design mentality we had a logging pipeline that I am still jealous of. We had metrics flowing into dashboards that were everywhere and informed us of our work. We had things like "integration testing" that ran continuously against the platform, all from the users perspective, that allowed us to test features long before they reached the public. All of these things were "input" that we "filtered" in some way to produce "output". When you start using that "output" as "input" and chaining these things together you get to a place where you can design a "kernel" (effectively an API service and a runtime) and start interacting with it to produce a platform.

I remember when we were pairing down services to get to our "kernel" one of the Operations engineers developed our Chef so that an internal engineer needed maybe 5-7 lines of Ruby to deploy their app and get everything they needed. Simple input, that produced a reliable application setup, that could now get us into production faster.

Anyways, those are just a couple.

I agree with everything you said, and can only thank the founders for their tremendous insight and willingness to push the limits. The shear number of engineering practices we take for granted today because of something like Heroku boggles my mind.

I am forever grateful for the opportunity to work there and make it an effort to pass on what I learned to others.

Yeah I think there is a lot of truth here. You can't solve all the problems and in Heroku's case we focused on user experience (internally and externally). Great ideas like "git push heroku main" are game changers, but what happens once that git server is receiving 1000 pushes a minute? Totally different thought process.

Perhaps the thing I would add is that even with the tech debt and scaling problems we still had over a million applications deployed ready for that request to hit them.

It is hard to explain the impact of such massive growth over a 2-3 period. New features were coming online while old ones were being abused by overuse. For instance, we launched PostgreSQL in the cloud, something we take for granted today. Not only that, but we offered an insane feature set around "follow" and "forking" that made working with databases seem futuristic.

I remember when we launched that product we went to that year's PGCon and there were people in the crowd angry and dismissive that we would treat data that way. It was actually pretty confrontational. Products like that were being produced while we were also working on migrating away from the initial implementation of the "free tier" (internally called Shen). It took me and a few others months to replace it and ensure we didn't lose data while also making it maintainable. The resulting tool lovingly named "yobuko" ended up remaining for years after that (largely due to the stagnation and turn over).

Anyways, that was just a slice of it. Decisions made today are not always the decisions you wanted to be made tomorrow. Day0 is great, day100 comes with more knowledge and regret. :D

Haha, funny you should mention that as I was just telling a coworker that story as we worked on a new dashboard for our infrastructure. :D

I remember Solomon's demoing at All Hands... it was such a crazy time for tech and innovation.

It remains the greatest engineering team I've ever seen or had the pleasure to be a part of. I was only there from early 2011 to mid 2012 but what I took with me changed me as an engineer. The shear brilliance of the ideas and approaches...I was blessed to witness it. I don't think I can overstate it, though many will think this is all hyperbole. I didn't always agree with the decisions made and I was definitely there when the product stagnation started, but we worked hard to reduce tech debt, build better infrastructure, and improve... but man, the battles we fought. Many fond memories, including the single greatest engineering mistake I've ever seen made, one that I still think about until this day (but will never post in a public forum :)).

It was a pleasure working with you bgentry!

You are still selecting one verse to interpret an entire culture. Misleading at best. And saying this is "white washing history" is silly. Continue reading the Bible and you'll see that it is the Christian Worldview that eventually ended slavery.

Cherry picking the bible isn't going to get you any closer to understanding. There are a lot of reasons God ordained society in a certain way. Keep reading and you'll discover that is a much more complex situation than you let on. Also don't let your modern ideals get in the way of understanding an ancient culture and a loving God.

Yeah I'd like to continue playing the game. Perhaps 10 verses before the limit kicks in to save on resources?