Live data from Hacker News

Buildpacks: Heroku for Everything

blog.heroku.com

21–30 of 41 posts

Re: Buildpacks: Heroku for Everything

#21
post #13

I'm a bit surprised there isn't a buildpack for PHP. It seems like there would be a demand, since PHP it so popular (I know I would definitely use it). I wonder if it's because modern PHP apps (such as Symfony) have some external dependencies (such as on the APC cache).

Yes, you have to love the myopia and revisionist definition of the statement "Run and scale any type of app. Run any web or background process with any web framework or worker type. " Really Heroku? Any web framework? I guess PHP and ASP.NET aren't web frameworks any longer.

Not to be a jerk, but you've been able to run PHP on Heroku for quite a while now, even without buildpacks. Create a facebook app and set language to PHP and you're good to go. Also, if you look at the heroku facebook php template app, there is minimal config needed to run php on heroku.

Also, PHP is not a web framework, it's a language.

Re: Buildpacks: Heroku for Everything

#22
post #19

Does anyone have any insight into why Google App Engine has not taken this route? Are there technical limitations within Google's infrastructure that would limit it?

I am not sure what you mean by "this route". App Engine supplies multiple runtimes (Java, Python, Go). Heroku somewhat analogously supplies buildpacks for using different languages, but also allows custom buildpacks.

Understand that Heroku and App Engine are fundamentally different kinds of things.

The commonality is that they are both selling some kind of service to run code on, and they are both (in different ways) trying to make it easier than just administering everything at the low level of a VPS or dedicated server, while also giving you similar levels of isolation and capacity as you get outside the shared hosting world.

But other than that, they are aimed at quite different goals and the architectures (necessarily) vary accordingly.

App Engine imposes heavy constraints on your app architecture with a primary goal of making scaling easier from the outset. You are very much doing everything inside a framework provided by Google. They are trying to make sure your handlers do not run too long or do certain classes of insecure things. And the infrastructure of production is very much opaque to you. You can't just run any old combination of services, they provide you a set of very good and very transparent but proprietary APIs for things like memcache and datastore. You just use them and get billed by usage. While they offer multiple runtimes and some multi-runtime tricks are possible, they really aren't trying to cover the 'polyglot' use case or support every language under the sun. It has good technical merits but your app is almost completely married to Google. Running a low-traffic app is free but scaling can be a little costly compared to approaches where you are doing more yourself.

Heroku is not a platform in the same sense as App Engine. That could be good or bad depending on what you need. It provides high-level interfaces to reduce most users' deploy and management overhead. But like a VPS, it isn't trying to limit your flexibility or determine your architecture. It explicitly gives you control over your mix of services and your own languages and use different things together. However, in the course of simplifying it also does constrain and hide details. It just isn't a fundamentally different environment from normal Linux VPS, as App Engine is - it's only one which you manage at a higher level using Heroku's tools. You are left with less lockin than App Engine, but you are still dependent on Heroku insofar as it is supplying all your deploy/management scripting and stuff like that.

App Engine says something like "do it our way with our tools and you will be able to scale easily on high grade infrastructure" and Heroku says something more like "do what you could do on a VPS in a slightly different way, with slightly less choice of tools, and we can make it much easier. We can help you cross the scaling bridge later." So they are designed to meet different kinds of needs and have attracted somewhat different kinds of audiences.

Re: Buildpacks: Heroku for Everything

#24
post #13

Earlier quoted context omitted.

Yes, you have to love the myopia and revisionist definition of the statement "Run and scale any type of app. Run any web or background process with any web framework or worker type. " Really Heroku? Any web framework? I guess PHP and ASP.NET aren't web frameworks any longer.

Not to be a jerk, but you've been able to run PHP on Heroku for quite a while now, even without buildpacks. Create a facebook app and set language to PHP and you're good to go. Also, if you look at the heroku facebook php template app, there is minimal config needed to run php on heroku. Also, PHP is not a web framework, it's a language.

If you compare it to things called web frameworks in other languages, PHP is a language and a web framework (or, if you like, which provides a highly integrated default framework).

Re: Buildpacks: Heroku for Everything

#25
post #13

Earlier quoted context omitted.

Yes, you have to love the myopia and revisionist definition of the statement "Run and scale any type of app. Run any web or background process with any web framework or worker type. " Really Heroku? Any web framework? I guess PHP and ASP.NET aren't web frameworks any longer.

Not to be a jerk, but you've been able to run PHP on Heroku for quite a while now, even without buildpacks. Create a facebook app and set language to PHP and you're good to go. Also, if you look at the heroku facebook php template app, there is minimal config needed to run php on heroku. Also, PHP is not a web framework, it's a language.

Using PHP on Heroku has never been straightforward. They don't even mention PHP in this post, and the instructions you've given are fairly undiscoverable. Ignorance of the possibility of running PHP on Heroku is more than excusable.

Re: Buildpacks: Heroku for Everything

#26
post #19

Does anyone have any insight into why Google App Engine has not taken this route? Are there technical limitations within Google's infrastructure that would limit it?

I am not sure what you mean by "this route". App Engine supplies multiple runtimes (Java, Python, Go). Heroku somewhat analogously supplies buildpacks for using different languages, but also allows custom buildpacks. Understand that Heroku and App Engine are fundamentally different kinds of things. The commonality is that they are both selling some kind of service to run code on, and they are both (in different ways)…

slugfest, thank you for the detailed response. By "this route" I just ment creating independent isolated environments for the various runtime to operate within. Based on comments made on the GAE mailing list, I suspect they have moved in this direction. After reading your post I now understand that the issue is not allowing indiscriminate code to work in isolation, but to allow that code to interact with external services E.g. make http requests. Maybe in the future GAE will provide a generic API for interacting with the various service, but I don't know what that would look like.

Re: Buildpacks: Heroku for Everything

#27
post #26

Earlier quoted context omitted.

I am not sure what you mean by "this route". App Engine supplies multiple runtimes (Java, Python, Go). Heroku somewhat analogously supplies buildpacks for using different languages, but also allows custom buildpacks. Understand that Heroku and App Engine are fundamentally different kinds of things. The commonality is that they are both selling some kind of service to run code on, and they are both (in different ways)…

slugfest, thank you for the detailed response. By "this route" I just ment creating independent isolated environments for the various runtime to operate within. Based on comments made on the GAE mailing list, I suspect they have moved in this direction. After reading your post I now understand that the issue is not allowing indiscriminate code to work in isolation, but to allow that code to interact with external ser…

App Engine just isn't intended or designed for that kind of interaction with services. Take memcache as an example.

On a VPS, you install an OS package and manage memcached as any daemon. You are editing the configs and compiling your own binaries if you want. Set it up on a separate box if you want. Set up a bunch of memcached boxes if you want. Do the wiring how you want. It's up to you and you handle all the details and you are billed by time. Handle it correctly and it's crazy fast.

On Heroku, there is a layer of abstraction which makes this more like 'give me 3 instances of memcached'. You are billed by the service-instance, essentially. You get help making things work well out of the box. But at a lower level it isn't too different from running deploy scripts to set up EC2 boxes. They just provide the scripts and sell you the resources and support at the same time.

On App Engine, Google runs a clustered memcache service for you. It is always running and there is no service setup. It is already on a scalable distributed configuration, not necessarily the fastest or cheapest but good; micro-optimizing memcache servers is not even intended as a supported use case. There is a ton of Google secret sauce involved, behind the scenes you are connecting to some cluster with RPC, all you know is the simple API interface they give you. You are billed based on how much you use it.

I think I can predict confidently that GAE is never going to expose an interface where you allocate individual memcached instances. That kind of interaction with services just isn't the App Engine way. Google has Compute Engine for the cases where you want EC2 style control of what is going on at the per-service level.

If you want to run your own App Engine platform you can try AppScale. (I never met anyone who does.) It is a whole prescribed architecture and it is not likely to be changed to become more like Heroku.

Re: Buildpacks: Heroku for Everything

#29
post #11

ActiveState's Stackato private PaaS platform ( http://www.activestate.com/stackato ) has support for Heroku buildpacks to deploy ( http://docs.stackato.com/deploy/buildpack.html ), as well as the usual options for polyglot app deployments (it also has a 100% compatible Cloud Foundry API). This is useful when you want portability (deploy on a PaaS that you have full control over).

Stackato rocks!
Post reply on HN