- Software Development
- How Cloud Foundry Supports Other Communities – InApps Technology 2022
How Cloud Foundry Supports Other Communities – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn How Cloud Foundry Supports Other Communities – InApps Technology in today’s post !
Read more about How Cloud Foundry Supports Other Communities – InApps Technology at Wikipedia
You can find content about How Cloud Foundry Supports Other Communities – InApps Technology from the Wikipedia website
A solitary tree is not a forest. Without other trees in a networked ecosystem, a tree has a more difficult life — it lacks the shelter of other trees, and it’s tougher to withstand storms and droughts. Trees fortify each other through a network of interconnected roots.
Trees banding together in a forest have another advantage: through their roots, trees assist and support each other via a network dubbed the “wood wide web,” communicating about threats and even passing nutrients to each other. There’s also a deeper, wider connection between trees and other plants in a forest — a network of mycorrhizal fungi via branching filaments called hyphae that enrich the soil and enable a reciprocal relationship that sustains forest ecosystem.
A Solitary Tree vs. a Forest
The open source Cloud Foundry application development platform was publicly announced over six years ago, and along the way, we have connected with other projects, adopting technologies from other open source communities as they matured. For example, before Docker was a company or even a project, the Cloud Foundry platform was using Linux containers to isolate deployed applications from one another. Our container implementation wasn’t built in a general purpose way like Docker’s; it wasn’t designed to solve all of the potential use cases for a container runtime. It was designed specifically to support the stateless web applications that Cloud Foundry was initially intended to support, and to do that in a secure, multitenant fashion.
Chip has spent more than 18 years in large-scale computing and open source software. In 2015, he became the co-founder of the Cloud Foundry Foundation as Technology Chief of Staff. He was the first VP of Apache CloudStack, a platform he helped drive while leading Enterprise Cloud Services at SunGard and then as VP Product Strategy at Cumulogic. Prior to SunGard, he led the rebuild of mission-critical applications for organizations including IRS.gov, USMint.gov, Merrill Lynch and SEI Investments. Chip is an experienced speaker at events like OSCON, LinuxCon North America, LC Japan, LC EU, ApacheCon, O’Reilly Software Architecture Conference, and many more. In his free time, Chip loves trail hiking with his black lab, sailing catamarans and sunfish, and trying to keep up with his young daughter.
As Docker matured, it separated its lower level container runtime library, runC, and eventually donated it to the Open Container Initiative. This was a signal to the the Cloud Foundry technical community to review its architecture, and Cloud Foundry became a very early adopter of runC. After a period of parallel support, the team eventually announced that runC support was complete and that we would be deprecating the previous container backend.
If you work in the technology industry, especially if you are paying attention to all of the exciting open source projects that come and go, it can be very easy to get distracted by the next exciting thing. The reality is that it rarely pays off to embrace something just because it’s new, and in fact this is a major risk for a project like Cloud Foundry. Our community is focused on end user productivity, above all else. This means that we work with other open source communities by first watching, then evaluating and finally participate where we believe it will benefit both groups. When the time is right in the evolution of a project — when technology is mature enough and proven in production — we then consider if and how we can adopt something into the Cloud Foundry platform.
The Cloud Foundry community’s approach to its Linux container runtime is a perfect example of our approach. So is the container networking interface. We were looking to change the way container networking worked in Cloud Foundry. The spec was good, and we were able to both take advantage of the efforts of another community and find ways to support their efforts.
As with any open source technical community, there are many voices and opinions. What happens in healthy communities is the emergence of a group philosophy around the technical evolution of the project. The Cloud Foundry community, in particular, understands the seriousness of the responsibility to deliver a solid, opinionated platform to its entire ecosystem. We look for the appropriate time to adopt technologies that have been incubated and developed both within the Cloud Foundry community and by other communities. When we need a new component, we first look to adopt. If nothing stable, scalable, secure and appropriately functional exists, we build “just enough” to solve our use case.
But technology doesn’t stand still. Over time, other projects will appear or evolve in ways that begin to fit our needs. When that happens, we lean in and push them over the line that lets us adopt them.
The relationship between different open source projects is a two-way street. We’ve helped those communities that we have embraced through upstream contribution. Even the language and framework communities that Cloud Foundry supports (through our buildpacks) get the advantage of the Cloud Foundry platform providing outstanding developer experiences — not only great, but up to date and secure, because we track the upstream language and framework releases closely. We keep developers working on modern versions of everything. This gives developers a better experience, helps reinforce the value of that language or framework, and even introduces different programming language to users that otherwise may have never tried them.
Our Open Service Broker API initiative is another example of the bi-directional (in this case, multi-directional) support that open source ecosystems can give each other. An API that started as only for the Cloud Foundry platform has been elevated to a multi-ecosystem status, giving end users of multiple platform technologies a unified way to expose and consume backing services for applications.
We take a mature, thoughtful approach to collaboration, incorporating technology into the Cloud Foundry platform when it makes sense, rather than pulling in anything and everything before it’s mature. If there’s an opportunity to replace a core component when maturity is achieved, we will. This collaborative philosophy enables the open source community as a whole to spread the cost of individual components’ development even further.
Not every technology gets drawn into the platform, but we have a lot of extensions points for the system. There’s a ton of bidirectional opportunity for open source communities, or even a single vendor open source project, to be well integrated into the Cloud Foundry platform. Doing so gives you access to a massive community of application developers who can use your technology, join your community, and improve your standing in the world.
A tree standing alone isn’t as strong as a group of trees joining forces to create a sustainable ecosystem. Just like trees in a forest, open source projects can nurture and sustain each other.
The Cloud Foundry Foundation is a sponsor of InApps Technology.
Feature image via Pixabay.
InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.