Altoros, a Cloud Foundry Foundation members, has announced general availability of the first-ever self-service Cloud Foundry training platform. In a user-owned cloud environment, engineers can learn and play with open-source Cloud Foundry first-hand.
Combining online tutorials with real infrastructure experience, the course is offered in basic, intermediate, and advanced versions.
Who may be interested?
The training platform is delivered to cloud-native engineers working with Cloud Foundry as end-users. The three main courses include:
Open-source Cloud Foundry for Operators
Open-source Cloud Foundry for Developers
Open-source Cloud Foundry for DevOps
Members of the Cloud Foundry ecosystem that help enterprises to innovate faster may also find this learning environment useful.
Since becoming the Executive Director for Cloud Foundry, I have been eagerly awaiting today’s launch of the Open Service Broker API project. This collaborative project with Fujitsu, Google, IBM, Pivotal, Red Hat and SAP enables developers, ISVs and SaaS vendors to deliver services to applications running within cloud-native offerings — including Cloud Foundry, OpenShift and Kubernetes — in the most straightforward, effective way possible.
Part of what I love so fiercely about the open source world is the ability to shed ego, come together to collaborate and to envision a radically open future.
Today, Cloud Foundry Foundation excitedly announced the launch of the Open Service Broker API project, in partnership with individuals representing Fujitsu, Google, IBM, Pivotal and Red Hat. The Open Service Broker API project provides developers, ISVs and SaaS vendors a single, simple and elegant way to deliver services to applications running within cloud native offerings, including Cloud Foundry and Kubernetes.
Many large companies are already in the process of implementing service brokers, including Google, Red Hat and Microsoft. Cloud Native Computing Foundation’s Kubernetes service catalog special interest group (SIG) is incubating integration of the Open Service Broker API.
The Cloud Foundry Routing subsystem handles and forwards all incoming requests to platform system components and applications. As such, the latency and throughput of the routing components has significant impact on the performance of your applications. Seemingly harmless code changes to these components could lead to unexpected performance regressions. A recent performance degradation in the GoRouter prompted the Routing team to investigate approaches to detect regressions as they are introduced.
While the main goal is to find and fix regressions, performance testing also enables the team to establish a baseline benchmark for the routing tier, and better educate Cloud Foundry operators on how to scale their deployment.
(This post assumes you’ve read the introductory blog post.)
While Cloud Foundry is the world’s premier developer platform, we have heard from customers how we can give them even better control and security, and help them integrate Cloud Foundry into their current and new environments. In this post, we’ll talk about some common pain points and how Cloud Foundry is evolving to give organizations better control and smoother adoption on their own terms. To summarize: the network is becoming application-aware and we’re embracing software-defined networking to help developers, DBAs, and security engineers manage and secure their CF networks in new, flexible ways.
Your DBA Feels Exposed (“I want to apply least-privilege access to my database.
A few months ago, we shared a vision for container networking for Cloud Foundry. Today, we are excited to introduce you to netman-release – the new, pluggable container networking stack for Cloud Foundry.
As stated in the vision, the main problems that the container networking effort aims to solve are:
Security policies within Cloud Foundry are provided through Application Security Groups (ASGs) which require an application restart to apply policy. Simple, CIDR-based rules are too broad to indicate application intent.
All communication between containers must go through the Gorouter. This exposes internal applications by requiring them to have a public route or configuring ASGs to allow all internal communication.
Over the past few years, I’ve been lucky to witness the evolution of Cloud Foundry. From a commercial product owned by VMware and Pivotal to its rebirth as an open source foundation, Cloud Foundry is a great example of the evolution of the technology industry as a whole. Beginning in January of 2015, the Cloud Foundry Foundation began to establish business and technology governance, building a strategy that has since rooted Cloud Foundry as the leading cloud application platform. Earlier this year, I joined the Foundation as its first Fellow before transitioning to a full-time position as the Vice President of Strategy. There is no place else I’d rather be.
This is why I’m thrilled to announce I am taking over Cloud Foundry Foundation as the Executive Director.
In our earlier blog posts, we have described how to build and deploy Concourse, BOSH and cf-release on OpenPOWER systems, an alternative processor architecture based on IBM POWER systems. In separate performance experiments, we have run up to 10,000 containers in a single IBM POWER system and run workloads such as IBM WebSphere Liberty in Docker containers with better price performance on IBM POWER systems.
In this post, we are describing how to build and deploy Cloud Foundry with Diego, for running Docker containers, as a BOSH release on OpenStack on OpenPOWER systems. Diego release installation steps with BOSH documented here require OpenPOWER specific binaries to deploy on OpenPOWER. We are providing a base Diego release which contains three OpenPOWER binaries: golang 1.7.
Today, we published a report titled “Identifying The Developer Gap,” which divulges a looming shortage of developers with cloud skills. This “Developer Gap” presages difficulties not only for IT but for businesses in general — particularly as software continues to “eat the world.”
Although we are still in the early stages of this “developer gap,” the findings indicate companies who are late to the game will struggle to find the highly-skilled developers required to keep up with an industry becoming more fragmented and complex, and as the pace of change continues to accelerate. You can read the full report here.
So you’ve built a cloud native app, taking advantage of all the 12-factors, or at least most of them. Is there a cloud application platform that you could run it to test it out? Yes, there is: Cloud Foundry.
Here are some of our certified providers that can help you get up and running on Cloud Foundry immediately:
AppFog from CenturyLink. Take advantage of a free trial on AppFog, CenturyLink’s platform based on Cloud Foundry. You also gain access to the broad array of services and resources for those developers that are new to cloud-native.
Atos Cloud Foundry.