codefinger

This has been a long time coming. The 12-factors have guided us well, but the ecosystem has changed.

The point we're at now reminds me a lot of Java in 2010. Everything was complex--too complex--and the "best practices" led to operational toil. The 12-factor manifesto ushered in a period of simplification that brought us out of big enterprise web servers, and into containers with executable jar files.

Similarly, the cloud-native ecosystem is brimming with complexity. It's time to establish patterns that result in more scalable, portable, and maintainable apps. Updating the 12-factor is how we'll do it.

where?

Give this a watch, and I think it may change your mind on some these points: https://www.youtube.com/watch?v=ofH9_sE2qy0

I think this is exactly why people should use Buildpacks over Dockerfiles. I've seen so many Dockerfiles that are wrong, or even introduce security problems.

Yes. The output of buildpacks is an OCI image (Docker image) that works with the container runtime(s) in Kubernetes

To you first point, there's probably no example of a Buildpack because (unlike Dockerfile) most Buildpack users don't write their own. They are reuseable. I'm not sure why the author didn't include an example of running a buildpack against an app though.

To your second point, Buildpacks are written in code too. But unlike Dockerfile, they use real programming languages that you can write tests for.

For example: https://github.com/paketo-buildpacks

The Ruby buildpack shown in the example installs Node.js for you. A developer doesn’t even need to be aware that it’s required to precompile assets.

There's some more detail here: https://buildpacks.io/docs/

I'm the Java Languages Owner at Heroku. While I can't reveal in full detail why we do (or do not) officially support a particular language, I can say that it has nothing to do with how resource-hungry the runtime is :)

Our determination to officially support a language is based on numerous factors including community demand, relationship with other technologies, suitability to the platform (C++ is really popular but not for web apps), and more. In any case, I wouldn't read too much into our support--it's not a determination on the language itself.

Fun fact: Clojure was the first JVM language supported on Heroku back in 2011 (even before Java itself)! https://blog.heroku.com/clojure_on_heroku

Today, Heroku support Java (with Maven or Gradle), Scala, and Clojure buildpacks. JRuby is supported via the Ruby buildpack. Buildpacks are the mechanism that prepares each app for production, so in some ways our support is more tightly coupled to the build tools than the language. That's why we don't have a Kotlin buildpack (it can use the Maven or Gradle buildpack accordingly). In fact, there's nothing specially you need to do to run a Kotlin app on Heroku, so we have some docs and there isn't much more to say about it. We've also worked closely with the Kotlin folks to make sure the ecosystem plays well with Heroku.

Let us know if you have any trouble with Clojure on Heroku. Stackoverflow.com is a great place to start (and I personal try to watch for questions tagged with "Heroku" and "Clojure").

LinuxKit (as I understand it) is for building the OS itself. Buildpacks are a higher level abstract for building a complete application image (with the emphasis on application). They take app source code as input, and output a docker image that's ready for prod.

This article covers the basics: https://devcenter.heroku.com/articles/java-memory-issues