> Jib/Ko/etc are proven patterns in this field, and we saw an opportunity to use the existing infrastructure of MSBuild to reduce the amount of concepts our users would need to know in order to be successful in their journey to the cloud.
Hah, I don't know - my experiences with Jib have only ever been negative. Having something like a Dockerfile that lets you customize everything that goes into the container and only having to worry about your app as a .jar file seemed like a better option to me, rather than having some plugin that integrates with your build tooling and feels infinitely more opaque all of the sudden: https://cloud.google.com/java/getting-started/jib
Essentially if you'd need a bunch of custom packages, e.g. some non-open-source fonts so your PDF export in your Java app would work correctly, you'd still probably need a custom base image, thus slightly negating the benefits of this apparent simplification: https://cloud.google.com/java/getting-started/jib#base-image
In addition, the images that were generated (last I tried) didn't have proper timestamps and thus showed up in Docker as created decades ago, which might be good from a reproducible build perspective (same code --> same image), but still felt unintuitive when you actually looked at the images.
But hey, maybe I'm just used to Dockerfiles and not needing a different plugin for each separate technology stack - looking at any application as just a Dockerfile (or a similar equivalent) regardless of whether it runs Java, Ruby, .NET, Python, Node or something else under the hood has always seemed like a good idea.
I'm glad that people who like alternative approaches have those options!
Personally (bit of a tangent here), I also found things like dealing with memory limits in JVM (e.g. the container needs a bit of free memory not to OOM, so JVM needs to leave a bit free, but Xmx is not the actual limit and will still be exceeded, alas there is no actual JVM_MAX_MEMORY_LIMIT_MB parameter so it's a bit of a pain if you want stable containers that don't crash). to be problematic, so it's nice that various different technologies are getting attention, be it Jib, .NET or something else!
.NET just generally seems like a pretty sane and performant option (primarily for web development, but for other use cases as well), especially with how it feels like most of what you need comes out of the box vs the more fragmented nature of other stacks (e.g. Spring and its plugins like Hibernate/myBatis/jOOQ in Java land).
In summary: I still believe that this (much like the other tools in the space) will be good for people who don't want to learn all of the concepts of what Docker/Buildah/... provide you with and will make building containers for your particular stack more easy. Though this will come at the expense of having multiple separate tools for different tech stacks, which may or may not erase some of the benefits, depending on how polyglotic your stack is.
You make great points about the need for customization and the boundaries of solutions that aren't based on Dockerfiles. Our approach to that problem is twofold, though both parts are still only in the planning stage:
* eventually providing an 'eject' mechanism to create the matching Dockerfile for a given project. this serves as a basis for any customization you might need, as well as a base language that many existing tools can understand.
* making it easy to include arbitrary image layers by reference in your container through a syntax like `<ContainerLayer Include="<layer SHA ref>" />`. This makes it easy to grab already-built components and inject them into your build.
I entirely agree with your summary. More choices, but all built on the same standard foundation :)
Hah, I don't know - my experiences with Jib have only ever been negative. Having something like a Dockerfile that lets you customize everything that goes into the container and only having to worry about your app as a .jar file seemed like a better option to me, rather than having some plugin that integrates with your build tooling and feels infinitely more opaque all of the sudden: https://cloud.google.com/java/getting-started/jib
Essentially if you'd need a bunch of custom packages, e.g. some non-open-source fonts so your PDF export in your Java app would work correctly, you'd still probably need a custom base image, thus slightly negating the benefits of this apparent simplification: https://cloud.google.com/java/getting-started/jib#base-image
In addition, the images that were generated (last I tried) didn't have proper timestamps and thus showed up in Docker as created decades ago, which might be good from a reproducible build perspective (same code --> same image), but still felt unintuitive when you actually looked at the images.
But hey, maybe I'm just used to Dockerfiles and not needing a different plugin for each separate technology stack - looking at any application as just a Dockerfile (or a similar equivalent) regardless of whether it runs Java, Ruby, .NET, Python, Node or something else under the hood has always seemed like a good idea.
I'm glad that people who like alternative approaches have those options!
Personally (bit of a tangent here), I also found things like dealing with memory limits in JVM (e.g. the container needs a bit of free memory not to OOM, so JVM needs to leave a bit free, but Xmx is not the actual limit and will still be exceeded, alas there is no actual JVM_MAX_MEMORY_LIMIT_MB parameter so it's a bit of a pain if you want stable containers that don't crash). to be problematic, so it's nice that various different technologies are getting attention, be it Jib, .NET or something else!
.NET just generally seems like a pretty sane and performant option (primarily for web development, but for other use cases as well), especially with how it feels like most of what you need comes out of the box vs the more fragmented nature of other stacks (e.g. Spring and its plugins like Hibernate/myBatis/jOOQ in Java land).
In summary: I still believe that this (much like the other tools in the space) will be good for people who don't want to learn all of the concepts of what Docker/Buildah/... provide you with and will make building containers for your particular stack more easy. Though this will come at the expense of having multiple separate tools for different tech stacks, which may or may not erase some of the benefits, depending on how polyglotic your stack is.