Thank you for joining me in this course on building images. As we've seen, containerization is changing the landscape of how we package applications. The end result is applications that can be deployed and run across computers in a more consistent and predictable way, but this means that the burden of providing and packaging dependencies is shifting left into the build cycle. There are a number of tools that can help us do this successfully and in this course, we looked at three different approaches, Dockerfile, Jib, and Cloud Native Buildpacks using Paketo.

With Dockerfile, you write your own script to assemble an image, using a fixed set of valid Dockerfile instructions. Overall, you can see that working with Dockerfile is a double-edged sword. On one hand, you have full control over your application's behavior and environment, but on the other Dockerfile authors must become knowledgeable about many low-level details, and there's plenty of room for error.

Higher level tools aimed to abstract away some of these challenges. One example for Java applications in particular is Jib, a plugin that integrates seamlessly with a Mave integratal workflow. Jib has garnered wide adoption since its introduction in 2018, since it alleviates Java developers from having to deal with Docker CLI, Docker Demon and Dockerfiles, and it incorporates some optimizations for Java, but its model is relatively simple and it doesn't address use cases related to re-usability, modularity, governance and integration with agents or other commodity products.

The Cloud Native Buildpacks Project provides a leap forward with a well-designed API based approach that fosters an ecosystem of platforms and Buildpacks. It leverages the latest capabilities of modern container standards to offer substantial optimizations and advanced features such as OS rebasing. It provides a foundation for governance, consistency, observability and ensuring and enforcing security measures.

In addition, the variety of existing platforms makes Cloud Native Buildpacks easy to use and enables us to address very different use cases while still guaranteeing the same image will be built from the same source. Finally, we saw that Paketo Buildpacks enables us to leverage the maturity of the previous generation of Cloud Foundry Buildpacks and improves upon it with modularized Buildpacks that can be configured in a standard way.

I hope you enjoyed this course and that you learned valuable information that you can put to use right away supporting and improving existing images or creating new ones and if you explore more containerization tools in the ecosystem, I hope your understanding of Dockerfile, Jib, the Cloud Native Buildpacks Project, and Paketo Buildpacks can help you better assess other options that you encounter. Happy building.