Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Update on Heroku

heroku.com

Post reply on HN
Print view View original

331–340 of 366 posts

Re: An Update on Heroku

#331

Post by asenchi »

brabel wrote: post #278
asenchi wrote: post #220

Earlier quoted context omitted.

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 ther…

> by 2012 we were drowning in tech debt and scaling challenges. > the greatest engineering team I've ever seen How do these two things reconcile in your opinion? In my view , doing something quickly is the easy part , good engineering is only needed exactly when you want things to be maintainable and scalable, so the assertions above don’t really make much sense to me.

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

Re: An Update on Heroku

#333

Post by asenchi »

macintux wrote: post #303
brabel wrote: post #278

Earlier quoted context omitted.

> by 2012 we were drowning in tech debt and scaling challenges. > the greatest engineering team I've ever seen How do these two things reconcile in your opinion? In my view , doing something quickly is the easy part , good engineering is only needed exactly when you want things to be maintainable and scalable, so the assertions above don’t really make much sense to me.

In general, my impression has been that you don't want to architect your solution at first for massive scaling, because: * You probably aren't going to need it, so putting the effort into scaling means slowing down your delivery of the very features that would make customers want your solution. * It typically slows down performance of individual features. * It definitely significant increases the complexity of your s…

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.

Re: An Update on Heroku

#334

Post by catlifeonmars »

ptdorf wrote: post #219
Aurornis wrote: post #194

Earlier quoted context omitted.

Thanks for sharing your story. Those early days of using Heroku were really enjoyable for me. It felt so promising and simple. I remember explaining the concept to a lot of different people who didn't believe that the deployment model could be that simple and accessible until I showed them. Then life went on, I bounced around in my career, and forgot about Heroku. Years later I actually suggested it for someone to us…

The cancer of corporations: bureaucracy.

Bureaucracy is a natural consequence of workforce growth. Respectfully, I think you are blaming the symptoms here, not the root cause.

Re: An Update on Heroku

#335

Post by asenchi »

Folcon wrote: post #241
asenchi wrote: post #220

Earlier quoted context omitted.

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 ther…

I'm just going to chime in here and say thank you, there still really isn't in my mind a comparable offering to heroku's git push and go straight to a reasonable production I honestly find it a bit nuts, there's offerings that come close, but using them I still get the impression that they've just not put in the time really refining that user interface, so I just wanted to say thank you for the work you and the GP di…

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.

Re: An Update on Heroku

#336

Post by asenchi »

whitepoplar wrote: post #306
asenchi wrote: post #220

Earlier quoted context omitted.

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 ther…

Tell us more about some of these ideas and approaches that changed you as an engineer! We'd love to hear!

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.

Re: An Update on Heroku

#337

Post by asenchi »

asenchi wrote: post #336
whitepoplar wrote: post #306

Earlier quoted context omitted.

Tell us more about some of these ideas and approaches that changed you as an engineer! We'd love to hear!

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, prote…

Here[0] is a talk that shows off some of these tools. Mark led the way on many of these ideas internally.

[0]: https://www.youtube.com/watch?v=yGcaofDq8SM

Re: An Update on Heroku

#339

Post by bigfatkitten »

hosh wrote: post #311
bigfatkitten wrote: post #222

Earlier quoted context omitted.

Auth0 still has a ton of people working on it at Okta. If they’re facing execution problems, it’s not due to a lack of resources.

Auth0 and Okta serves two different market segments. You’d use Autho0 for your customers and Okta for your employees.

That’s why they bought Auth0 in the first place. They didn’t have a real offering for customer identity.
Post reply on HN