Ram Iyengar, Cloud Foundry: “laying a good foundational architecture for your web applications is great, but at what cost?”

By presenting intricate hardware and software services in various domains, cloud computing has been proving itself as a revolutionary model of distributed computing.

As a consequence, Cloud Resource Orchestration Frameworks (CROFs) emerged. These are systems designed to manage the life cycle of resources. But even though, there are hundreds of providers that offer a cloud orchestration platform, the products they offer are often proprietary, and not portable for various reasons.

Luckily, not all of them are like that. A great example would be Cloud Foundry – a highly efficient, modern model provider for cloud-native application delivery. Thus, our investigation team reached out to its Chief Evangelist, Ram Iyengar, to enlighten us about the insights of this field.

What has your journey been like since your launch?

Cloud Foundry has always been focused on two fundamental areas – orchestrating cloud resources and providing a fluid experience for application developers. The Cloud Foundry community successfully enabled this for virtual machines and continues to demonstrate success with its core project, while, more recently, expanding this developer experience to Kubernetes and the wider cloud-native ecosystem.

The Cloud Foundry Foundation today owns several well-integrated projects that exist to simplify the developer experience. Whether consumed in parts (for example Paketo Buildpacks, the Open Service Broker API, Stratos) or in whole as Cloud Foundry – it helps adopters realize a convenient and powerful developer platform.

Multi-company open source is not without its quirks and complexities, and our path is no exception. In the past decade, we have been able to pull together and create one of the most advanced, active, and amicable communities in technology.

How did Cloud Foundry come about in 2009?

The PaaS substrate found its origins in the need for an enterprise-grade tool that could convert source code into immutable artifacts that are deployed to remote infrastructure. At the time, there were tools that could do easy deployments (think Heroku, AppEngine, EngineYard) or were enterprise-ready (think Oracle, IBM) – but were not both.

Cloud Foundry emerged as a leader by virtue of its ability to combine both these foundational aspects and build a best-in-class developer experience on top of it. Slowly it evolved into numerous projects that aided the core PaaS to succeed.

Can you tell us a little bit about your development platform? What are its key features?

Cloud Foundry simplifies the deployment experience for application developers. It is a complete platform designed to support the consumption and governance of multi-cloud environments. This includes capabilities to build, deploy, monitor, and maintain applications.

Cloud Foundry works the exact same way for every programming language and framework, and is cloud-agnostic; developers have the same experience whether it is deployed on any major cloud provider, on-premises, or on a hosted service. This homogeneity makes it an ideal platform for software engineering teams that use different stacks, and different clouds, and operate across different teams.

Most recently, the community announced the release of a new, lighter-weight version of the Cloud Foundry platform, Korifi, which brings that best-in-class developer experience to Kubernetes. This is currently in beta and will be an important focus of the community in the coming years.

It is evident that open source is an important part of Cloud Foundry. Would you like to share more about your vision?

Cloud Foundry is entirely open source, licensed under the Apache 2 OSS license in contrast with several proprietary developer platforms that provide a seamless experience for application developers to deploy apps. However, since they either run on the public cloud or cannot be easily extended, enterprise-grade rollouts are not possible.

On the other hand, when you have an open-source tool, the barriers to entry are much lower and community benefits are much higher. Customizing for bespoke needs within enterprises is simpler. There are past examples of successful projects in which the community was able to swap components to create new tools and provide extendable functionality, made possible purely because of the open-source nature of the projects.

Do you think the recent global events influenced your field of work? Were there any new challenges you had to adapt to?

In some ways, the pandemic has been kind to open source projects and contributors. Because of remote work policies, a lot of contributors have had the opportunity to increase the number of hours in the day.

This has resulted in a cognitive surplus for open source projects and therefore we’ve seen an uptick in contributions - both technical and non-technical. Several project enthusiasts have also been posting information on social platforms for many others to take advantage of. This has helped increase the visibility of many open source projects.

What are the most common vulnerabilities nowadays, that if overlooked, can lead to serious problems for a business?

Remote code execution and malicious injection are perhaps the most notorious attacks that are taking place. Two recent CVEs - the Log4JShell and the Spring4Shell vulnerabilities come to mind immediately. Owing to the ubiquity of the underlying technology (Java in this case), a lot of software, devices, wearables, and other electronic equipment were left vulnerable. Being unable to secure these components can quickly avalanche to problems for the business.

Likewise, another trend that is gaining traction quickly is supply chain security, where the components of a larger software system are not verifiable, leading to issues with using them in a risk-free manner.

What would you consider the main challenges developers run into nowadays?

Distractions - “Left shift” and DevOps have both been very positive trends in software development. But having too many moving pieces for a single person to take care of and too many parameters to fine-tune can be overwhelming. The problem stems from DevOps transforming into Dev—Sec-Fin-Biz-Log-Obs—Ops. The Dev++Ops role that a lot of developers are forced to take can be a challenge.

The second kind of distraction is plain old marketing. I see a lot of engineers say — "Uber does microservices, so we're doing it", "Google uses Kubernetes, let us also do it", “Airbnb this, Shopify that”, and so on. This is not a healthy trend. Laying a good foundational architecture for your web applications is great, but at what cost? When this trickles down from an executive through the hierarchy, it can lead to dissonance and burnout for individual developers.

What are some of the best practices organizations should follow when creating cloud-native applications?

Containers, orchestration, services, APIs, security, and DevOps.

Containers, orchestration, services, APIs, security, and DevOps.

• Containerization - All apps need to be containerized to take full advantage of the cloud-native architecture.
• Orchestration - As apps scale, the organic need for orchestration arises. Engineering teams must prepare themselves for this.
• Service-based architecture provides a great platform upon which to provide engineering best practices such as SLOs and formalize SLIs.
• APIs allow applications to be composable and modular, leading to extensible cores and communication between services to be fast, reliable, and uniform (REST-based).
• Security should always be the center of all feature development work. Vulnerabilities that are a result of not focusing on security can result in disastrous consequences.

Finally, adopting these as axiomatic habits will result in the automatic adoption of the DevOps culture – which is important for teams that intend to succeed with cloud-native applications.

Talking about average individuals, what security measures do you think every casual Internet user should have in place?

Basic safety and hygiene. Keep to trusted websites. Don’t leave antivirus software outdated. Be wary of what information you share on the internet.

If you’re visiting a new website, read the information twice. Do not write passwords on Post-it notes!

Share with us, what’s next for Cloud Foundry?

Over time, the core focus of the Cloud Foundry community has shifted from making containerization and scheduling work at scale to interoperability with other cloud-native technologies and increased flexibility.

This haiku by Onsi Fakhouri (ex-Pivotal) - “Here is my source code. Run it on the cloud for me. I do not care how.” captures the Cloud Foundry vision, and this remains the core of Cloud Foundry’s value proposition. Across infrastructure changes, different waves of DevOps tooling, and other ideas that unfold across the technological landscape, Cloud Foundry seeks to provide a simplified, best-in-class developer experience, extrapolating away underlying infrastructure and allowing application developers to focus on shipping code.

The latest effort in this tradition is Korifi, a project that converges the Cloud Foundry experience atop Kubernetes infrastructure. This allows for a uniform developer experience across Kubernetes, VMs, or other cloud-based infrastructure, and aims to make Cloud Foundry fully interoperable with Kubernetes and other cloud-native technologies as they mature.