Added draft blog post for buildpacks rebase #283
Conversation
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
✅ Deploy Preview for tag-env-sustainability ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Just chipping in on @catblade 's comments regarding the measurement. Did you recently migrate in one of your projects from a classic Dockerfile to a buildpack? Since I never worked with buildpacks before this would be also a very interesting project for me to give it a try :) Referencing a post regarding the general approach suggested here: #273 |
There was a problem hiding this comment.
Thank you for submitting the blog. Very interesting! Something we haven't looked into before - great to see this blog.
General thoughts... every project always wants to be as efficient as possible, this is not a new requirement but correlates with energy consumption. Docker has its place, but in a cloud native environment with lots of dependencies and regular rebuilds, buildpacks are probably a better choice. The concept using buildpacks (rebase dependencies etc) is the real performance gain here. I would consider highlighting the concepts that are different and make buildpacks a better tool in a cloud environment.
- I've added a comment in the introduction. I would consider rewriting it a bit.
- For me, a historical perspective would be interesting. Docker is well developed, but the context has changed (-> cloud native), so a different tool, buildpacks, emerged. There is already a paragraph about Docker, I would consider expanding it slightly with technical details (and I suppose most other tools podman, lama, are similar to how, Docker works, right?).
- Maybe add a little more technical detail on how the buildpacks rebase process works.
- For me, the images don't provide much additional information, I would consider updating them.
| author: Joe Kutner | ||
| --- | ||
|
|
||
| Container builds can be very wasteful. Every operating system update, new dependency version, and toolchain upgrade results in copious amounts of energy used to build and rebuild our container images; often unnecessarily. It can be costly at scale, which is why Cloud Native Buildpacks were designed to perform builds as efficiently as possible. |
There was a problem hiding this comment.
Thoughts
- Maybe add one sentence at the start to get the reader into the mindset. (ofc we expect that the reader knows docker etc.)
Container builds can be very wasteful.does not actually say much. The next sentence says more.which is why Cloud Native Buildpacks were designed to perform builds as efficiently as possible.this is quite long and does not really say anything. Every tool wants so be performant. What comes in the next paragraphs rebasing etc. are interesting because these are the concepts that differ..- To me, a history perspective is missing here. Some details into docker are described a bit later, but I sense that there is something missing here. (feel free to disagree, ofc.)
- Perhaps you want to merge both paragraphs. I am not sure why to break at this point.
There was a problem hiding this comment.
How about this?
which is why Cloud Native Buildpacks were designed to perform full builds only when a rebuild is actually required.
Re: history perspective, I worry that might clutter the intro. But maybe it is necessary to set context. Are you thinking I should add some of the history of buildpacks (ex. they pre-date Dockerfile). Also, it may be worth clarifying that the choice is not between Docker and Buildpacks, but rather Dockerfile and Buildpacks (buildpacks image work with docker and otehr container runtimes).
For the intro sentence, I'm not sure what you mean by "get the reader into the mindset". Can you elaborate?
There was a problem hiding this comment.
How about this?
[...]
👍
I worry that might clutter the intro. But maybe it is necessary to set context
Yeah, the history part should come later, but for the flow and to get into the context it would consider adding / teasing it in the intro.
Also, it may be worth clarifying that the choice is not between Docker and Buildpacks, but rather Dockerfile and Buildpack
Yes! I would take this in. You could think about using Containerfile instead of Dockerfile.
For the intro sentence, I'm not sure what you mean by "get the reader into the mindset"
Essentially, my comment is about setting the context. The blogs we have are very different in terms of content. Just to make it easier to change context. Buildpacks is used for XYZ.
Co-authored-by: Marlow Weston <catblade@gmail.com> Signed-off-by: Joe Kutner <jpkutner@gmail.com>
Co-authored-by: Marlow Weston <catblade@gmail.com> Signed-off-by: Joe Kutner <jpkutner@gmail.com>
Co-authored-by: Marlow Weston <catblade@gmail.com> Signed-off-by: Joe Kutner <jpkutner@gmail.com>
Co-authored-by: Marlow Weston <catblade@gmail.com> Signed-off-by: Joe Kutner <jpkutner@gmail.com>
|
@leonardpahlke do you think the images might be more valuable if there was more context provided about what they are illustrating? Or did you understand what they are showing, but don't find the illustration helpful? |
|
|
||
| Today, many applications are coupled to the operating system and its packages because they use a Dockerfile to define their container images. As a result, those images frequently need rebuilds to apply patches to OS-level components, or simply to update tools that aren't even used by the application. Even worse, the layer caching mechanism imposed by Dockerfile forces us to frequently rebuild layers that don't even need to be rebuilt. | ||
|
|
||
| The cloud-native ecosystem has brought great productivity and operational improvements to software development. But we've lost sight of how wasteful some of those technologies can be. |
There was a problem hiding this comment.
But we've lost sight of how wasteful some of those technologies can be.
@jkutner Can you elaborate what do you mean by wasteful here?
There was a problem hiding this comment.
What do you think about something like this?
The cloud-native ecosystem has brought great productivity and operational improvements to software development. But we've lost sight of how wasteful some of those technologies can be. The relative ease and low cost of cloud infrastructure encourages us to solve problems by spinning up new resources instead of optimizing for the efficient use of our resources. We see this with container builds using Dockerfile, but also other parts of CI/CD, where it's sometimes easier to re-run expensive processes.
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
|
@catblade @leonardpahlke @savitharaghunathan thank you for the feedback. Let me know if there's anything else I can do to move this forward. |
If you have a diagram, there should always be a written explanation of the diagram that guides the reader through the diagram. It would be good to add that. My comment also referred to the information content of the diagrams, which in my opinion is on the low end. If there is not much more info to transport, that's ok. |
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
|
@leonardpahlke I've revised the intro paragraphs based on your feedback (and some from @catblade). i also added some more description for the diagrams. Let me know if you think this helps or not. I'm incline to try and keep the images because we've had success in the past communicating the rebase process in this way (in other blogs and KubeCon talks for years, etc). |
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
|
Thank you for this blog post, I always looked at the CICD processes overall and how to achieve more sense in it, but this detail is great. |
|
Thank you all for the feedback! definitely made the post better. It looks like the spell checker needs to be taught the "Buildpacks" word. How can I do that? |
|
Apart from the spell checker warning, the blog seems to be finished & reviewed! We can publish it this week if no one puts in a block request today/tomorrow. We will then send it to the CNCF PR team (fyi, we do this for some blog we seem fit). cc @catblade (⬆️) Apart from this specific blog -- @caradelia @patricia-cahill @savitharaghunathan could we define early next year the role of the wg-comms blog post wrangler, right now it's not defined and a question mark to me & check if our current blog post process works well or should be modified https://github.com/cncf/tag-env-sustainability/blob/main/governance/blogpost-process.md |
@leonardpahlke +1. I have been thinking about utilizing project board to line up blog issues and document any missing steps. I am currently on PTO. Will be working on this early Jan. If anyone has ideas and want to take a stab at it, please feel free to :) |
Draft of #281