“Build Foundry” May Ease Service Discovery and Maintenance of Buildpacks
What issues to address?
A proposal called “Build Foundry” was mentioned during the latest Community Advisory Board (CAB) call, in the context of looking beyond the ongoing, core open-source Cloud Foundry development that’s the normal focus of the monthly calls.
Jared Wray
Developed by Jared Wray and mentioned during the call by Cloud Foundry Foundation CEO Sam Ramji, Build Foundry is a proposed registry system that aims to resolve several specific issues. These issues are outlined by Jared as follows in a longer document that can be found online:
- “There are 45+ buildpacks in the community and only the core ones are maintained.
- All current core buildpacks are part of the Cloud Foundry BOSH deployment process. If customers do not upgrade Cloud Foundry, then their applications are running with legacy buildpacks that could have security or performance issues.
- There is currently no rating system for buildpacks that allows users to know the success/failure percentage and usage.
- Customers requiring CA certification of buildpacks are building one-offs, which is causing more separation from the core. By having a system that can handle the CA requirements via deployment, it will fix the issue.
- Services have no centralized registry to register with and be discoverable.
- Services have no rating system to know which ones are used and how often.”
Based on Node.js
Jared says the solution is “to provide an open-source/community-driven registry system that allows for a public repository of services and buildpacks. It should also enable companies, which have the ability to control their own mirror of this with a process, to maintain CA and control over what is used in their environment.”
The proposed platform architecture “is based on Node.js as it is a web service with a web interface. Members are able to authenticate using their GitHub or other authentication methods using the Auth0’s authentication service,” Jared writes. “The service contains a registry, web interface, and CLI for publishing and maintaining these services.”
In our opinion, this initiative is a very positive step for Cloud Foundry.
Better quality and consistency
Our take is that this idea is precisely why communities are the lifeblood of modern software development. Altoros CEO Renat Khasanshyn has said Altoros will fully support the proposal and assist our customers with integration of Build Foundry into the Cloud Foundry deployments. Our engineers are aware of this document, too, and will be providing their evaluations to Renat and the management team.
Renat Khasanshyn
Renat has offered the following additional thoughts about the proposal:
“Interoperability and portability of runtimes and services between Cloud Foundry deployments across private and public clouds have always differentiated the platform against competing proprietary and open-source options.”
—Renat Khasanshyn, Altoros
“So, Jared Wray, Sam Ramji, and the Cloud Foundry Foundation just catapulted Cloud Foundry to the next level. I believe that the Build Foundry registry will greatly impact value proposition of Cloud Foundry, because it adds two mission-critical functions to its ecosystem of already interoperable and portable runtimes and services, namely aggregation and quality assurance.”
Renat also highlighted that by verifying the consistency of runtimes and services, by adding quality checks, and by using reputation as a mechanism to hold authors accountable for quality of runtimes and services, Cloud Foundry is likely to further solidify its competitive advantage, and value proposition as the platform of choice for software application delivery.
Once you’ve read over the complete document, we’d love to get your comments (send me an e-mail). You can of course also contact Sam Ramji and/or Jared Wray with your thoughts.
Related reading
