The Blog

 

Cloud Foundry Summit Europe 2018 was again held in the international city of Basel, Switzerland. Situated at the border of three countries (Germany, France, and Switzerland), Basel is an easily accesible city with a great transportation system and superb conference venues. Its only problem? Hotel and food costs tend to be quite pricey. But we won’t dwell on this, because the Cloud Foundry Summit organizers provided various opportunities for attendees to have coffee, lunch, and snacks. After all, the most exiting place to be was the Cloud Foundry Summit!

This post recaps the wide variety of IBM’s contributions to Cloud Foundry Summit Europe 2018 as well as various sessions we found interesting. From co-leading three tracks, to delivering keynotes, and presenting more than 10 talks, IBMers were there in force to help drive the overarching message that Cloud Foundry is central to the IBM Cloud and that we are key participants and contributors to the platform today and in the future. Let’s dive into the areas that stood out and areas where IBM had the largest contributions.

Pre-conference activities

Hackathon photo

The day before the conference usually includes a variety of sessions that Cloud Foundry Summit calls Day 0 activities. This year, IBM sponsored the hackathon event. We also co-hosted the event and provided one of the judges. Early in the morning, Nimesh Bathia helped set the stage for the various hackers participating with a overview of what it takes to win hackathons and what to expect in the next 24 hours of hacking, including tips on how to strategize and budget time.

Unconference photo

In addition to a series of training tracks and the on-site certification examination that were going in paralel, Day 0 of Cloud Foundry Summit Basel 2018 included the Unconference. Organized by EngineerBetter, this event started in the evening when many conference attendees had made their journey to Basel and joined the activities. It was packed with Cloud Foundry users, sponsors, and developers, all wanting to hear the many lightning talks. Based on my recollection, we saw an increase in participants in both the Unconference and the hackathon, compared to previous years.

IBM presence

As we noted in a previous post, IBM’s presence at this Cloud Foundry Summit in Europe has only strengthened. Not only did IBM sponsor and help run the hackathon, but had the opportunity to showcase the IBM team that was the overall winner of last year’s competion. During the conference keynotes, the team of IBMers shared where that winning project is headed. Additionally, this post hightlights some of the 10 talks that IBMers presented at this conference.

IBM booth photo

Of course we had our booth, also packed with activitites. For example, the Cloud Coin app allowed all visitors to participate in a giveaway that encouraged them to walk around and be healthy. By adding the Cloud Coin application to their mobile phone, participants are able to see a summary of their healthy behavior during the conference. One visitor won a grand prize, presented on the last day.

Cloud Coin photo

Experiments and Extensions track

Experiments and Extensions track photo

One of the three tracks co-led by IBMers was the Experiments and Extensions track, with co-lead, Dr. Nic of Stark & Wayne. This track was the place for new experimental projects and extensions to the Cloud Foundry platform. IBM not only co-lead this track at the summit but also is the Project Management Committee (PMC) leader for these types of projects in Cloud Foundry. The Extensions PMC produces monthtly summary notes that you can peruse to see the progression of this group of projects in CloudFoundry. Various companies (large and small) got to present their experiments – and in some cases their updates – to their extensions projects. Examples include Stratos UI and App AutoScaler.

We want to highlight the following three talks in this track:

App AutoScaler by Ying Liu of IBM and Rohit Sharma of SAP

One of the promises of platform as a service (PaaS) is to alleviate the cloud application management burden for both developers and operators. A PaaS should not only help manage the deployment of applications, and their update cycles, but also non-functional properties such as scaling and dealing with variable loads.

Ying Liu of IBM and Rohit Sharma of SAP photo

The App AutoScaler CF-Extensions project allows applications to register their scaling needs as declarative policies, and then the platform does the job of scaling the applications when the policy event triggers. Examples of possible policies are to scale based on metrics such as number of requests or simply at specific time intervals (such as when anticipating sharp increase in traffic).

You add support for application auto-scaling to your own Cloud Foundry application like you would add any service to your application. The App AutoScaler service needs to be available and enabled in the Cloud Foundry environment. For example, the public IBM Cloud and the newly released IBM Cloud Foundry Enterprise Edition both include the application auto-scaling service. We encourage you to view the presentation’s video, to get additional information on the Github project page, and to engage with the team and participate in this project.

“Performance of a VM vs Containerized Cloud Foundry” by Jeff Hobbs and Vlad Iovanov of SUSE

As Cloud Foundry and Kubernetes grew closer in the past year, different efforts to integrate them developed. One of the oldest and most mature efforts in this area is SUSE’s Cloud Foundry containerization project, which came from their Fissile project. In a nutschell it allows CF BOSH releases to be packaged in a way that allows them to easily get deployed onto Kubernetes.

In this talk, Jeff and Vlad, originators of the project, discuss a recent experiment they ran to help answer the questions around the issue of performance. Especially comparing the performance of running Cloud Foundry in containerized environment vs the classic VM-based deployment mode. While they offered no clear cut “winner”, I took away three key messages from their talks. First is that deploying Cloud Foundry on VMs and containers with limited resources leads to eventually lots of push and application errors.

Jeff Hobbs and Vlad Iovanov of SUSE photo

Second, when Cloud Foundry is deployed in an environment where the resources are not so contrained, the overall health of the environment increases. And in this case, VM-based Cloud Foundry deployments seems to perform better. Third, the containerized Cloud Foundry results show that running containers on top of containers (such as classic Diego-managed Garden containers on top of Kubernetes) has basicially no impact on the applications that are running.

The importance of this talk is twofold. First, it sets an experiment that others can try themselves. Since the authors took time to try to make both environments the same (price-wise and resource-wise) we hope that this is an experiment that others could try on other cloud environments. Further, it helps to dispell any myths and misconceptions about running Cloud Foundry on VMs or adding additional containerization layers on the Cloud Foundry stack.

“Cloud Foundry + CNI” by Angela Chin of Pivotal

CNI or Container Networking Interface is a de facto industry standard interface for adding networking functionality to containers and containerized applications. Since its introduction, multiple implementations and plug-ins are available for different cloud platforms. The variety is needed because many network interfaces can be exposed to containers in a cloud, and the container engines and orchestrators have different needs.

Cloud Foundry decided to include CNI support with its container networking initiative that started more than a year ago. Now in its mature second release, Cloud Foundry and CNI are tightly integrated, and multiple plug-ins are ready to use for most Cloud Foundry environments. In this talk, Pivotal Engineer Angela Chin gave an overview of the Cloud Foundry support for CNI, summarized the features, and discussed how you can swap in other networking plug-ins or even get started creating your own plug-in, if you have special needs that require such an effort.

Angela Chin of Pivotal photo

The ability to create your own CNI plug-in, rather than just using the existing ones (for example, calico), is a testament to the maturity of the Cloud Foundry networking stack, which allows extensions and flexibility. Of course, not all Cloud Foundry providers need to create their own CNI plug-in. However, the flexibility is important to allow not only experimentation but also the safe knowledge that if the need arises, Cloud Foundry providers can swap the CNI plug-ins in their environments to better deal with their specific network configurations and their scaling and network issues.

These networking scaling issues are real, from our own experience running Cloud Foundry at scale on the IBM Cloud. And many providers do have to create their own plug-ins, as you can find in other communities such as Kubernetes.

Other worthy extensions

Many other projects, experiments, and updates were presented during the summit. We cannot highlight all of them here. However, we should mention the Stratos UI update from SUSE. Stratos is a complete (multi-Cloud Foundry) user interface that we have integrated into the IBM Cloud Foundry Enterrpise Environment. Finally, the BOSH links visualization project from Pivotal and the OSB Local projects from eVoila are also worth mentioning. We encourage you to click on the video links to watch these presentations if you were not able to see them in person. You can see all the videos on the Cloud Foundry Summit Europe 2018 playlist on YouTube

Containers and Serverless track

At this summit, an entire track was dedicated to Container and Serverless, given the increasing adoption of containers and momentum it has. The track was co-led by Dr. Julz of IBM and Sanjay Patil of SAP. Sanjay kicked off the track with Haiku, comparing simplicity of Cloud Foundry and empowerment provided by Kubernetes. Sanjay shared three workstreams under Cloud Foundry Foundation to bring these two stacks together: 1.) Cloud Foundry and Kubernetes integration scenarios, 2.) a Cloud Foundry pluggable scheduler, and 3.) containerized Cloud Foundry control plane.

Photo of Sunjay Patil explaining Cloud Foundry efforts to integrate Container and Serverless

A big question in Cloud Foundry developers’ minds is how their experience would change when using Kubernetes. Developers who have completed the app development, first want to deploy it, and then plan for scaling or auto-scaling, recovery from failures, logging to debug the failures, service bindings, and managing the life-cycle of an app with zero downtime. In the case of Cloud Foundry, an app developer needs to know cf push and cf bind-service to bring the application up and running. An app developer does not have too many knobs, but it is a fairly straight-forward process. For Kubernetes, app developers first need to package the application in a container such as Docker, then push the container image to the container registry. Then Kubernetes can pull the image to deploy and scale the application. There are many configuration possibilities, but skills beyond app development are needed. This was the gist of the talk by Matthias Haeussler of NovaTech, who went over a thorough comparison of the user experience during his talk.

Photo of Matthias Haeussler showing the side-by-side experience of developer and deployer between Cloud Foundry and Kubernetes

A container session of particular note is “Kube Your Enthusiasm – Bringing the CF Push Experience to Kubernetes Operators (Project Eirini) by IBMers Julz Friedman and Julian Skupnjak. The Eirini project (now an official incubator project in the Runtime PMC) brings pluggable container scheduling to the Cloud Foundry application runtime. In other words, you get the cf push developer experience we all love, with your choice of container orchestrator – including Kubernetes – under the covers. This session introduced the Eirini project, walked through the reasons behind it, and explained what it means for developers and your operators.

Photo of Julz Friedman explaining Project Eirini

Keynotes and sessions

The session and keynote engagement from IBM was really exciting at this Cloud Foundry Summit, with some key highlights. The first one is the keynote “IBM Cloud Foundry Enterprise Environment” by Tammy Van Hove, Distinguished Engineer and Director, Cloud Foundry, IBM Cloud. Tammy showcased the GA release of the IBM Cloud Foundry Enterprise Environment solution, an offering that allows users to create and manage isolated Cloud Foundry environments for hosting cloud-native applications exclusively for their organizations.

photo of Tammy Van Hove, Distinguished Engineer and Director, Cloud Foundry, IBM Cloud

It provides on-demand self-service provisioning, elastic consumption, and complete access to administrative capabilities. It can make seamless use of the vast catalog of IBM Cloud services, enabling customers to build complex applications with a wide range of services, including Watson AI. You can see the keynote’s video and more information about Cloud Foundry Enterprise Environment.

A second session that was very cool was the next step, continuing on that topic, and going into more detail. You can watch the video of “Lightning Talk: IBM Cloud Foundry Enterprise Environment – Integrating Cloud Foundry and Kubernetes” by Lucinio Santos of IBM.

One last session of note was “Where Does Cloud Foundry Stand in the Containers’ Ecosystem?” by Surya Duggirala of IBM. You can watch the video to learn more. As container technology is becoming the de facto choice for cloud platforms, it is essential to compare various container ecosystems. As the industry is embracing microservices and service mesh technologies like Istio, there is a common question around how Cloud Foundry fits in this space.

This session compared Cloud Foundry’s garden containers with other container technologies like Docker and Kubernetes and highlighted the strengths and weaknesses of each of these container technologies. Surya also looked into the latest advances in Cloud Foundry Platform and how it is strengthening the cloud native deployments.

Conclusion

One of the key observations at this summit is the realization that the platform is maturing. In the past three previous summits, many hallway discussions and sessions revolved around how Cloud Foundry was affected by Kubernetes, or about how Cloud Foundry should be integrated with Kubernetes and other leading OSS projects like Istio. At this summit, the discussions were centered more around what value Cloud Foundry can keep bringing to customers.

Photo of Nima Kaviani and Morgan Bauer of IBM and Blockhead

It’s a given now that Cloud Foundry and Kubernetes and Istio will share components. The Open Service Broker API, which officially went live late last year is a great example of that cross-community sharing today. And more is happening, even as you read this. In addition to the integration of Istio into the Cloud Foundry networking layers, project Eirini promises to allow those who want to use their Kubernetes clusters to run Cloud Foundry applications, to do so seamessly. And like the Cloud Foundry Enterprise Environment offering from IBM, others like SUSE have already delievered Cloud Foundry on Kubernetes by running the Diego scheduler on top of Kubernetes directly.

Photo of Nima Kaviani and Swetha Repakula of IBM and Blockhead

As we mentioned, IBM’s presence is not only in leading the charge for these integrations but also in extending the platform by allowing it to be more open to enable experimentations in completely new avenues. Project Blockhead is a great example. The Blockhead leaders from IBM had an opportunity to present at the keynote stage. They showed how an Ethereum blockchain contract could be created, delivered, and ran on a Cloud Foundry Enterprise Environment in less than five minutes. To learn more, you can watch the video of the keynote.

In addition, the Blockhead team was interviewed by Ian Murphy of Enterprise Times for his his podcast. The team explained the goals and visions of Project Blockhead in making it easier for developers to write applications against public (such as Ethereum) or permissioned (like Hyperledger) blockchain networks. Here is a quick list of the highlights in the podcast, but we highly encourage you to listen to the podcast for the details:

  • The Blockhead broker combines the paradigms of 12 factor web applications with the offerings of a service broker, making blockchain available as a backing data store to decentralized web applications (dApps).
  • The Blockhead broker gives developers a choice as to what blockchain network to use.
  • Blockchain has given birth to a new group of application developers, programming languages, and job descriptions to bring this class of decentralized applications into the global market.

Overall, we left this summit feeling proud of the IBM team and knowing that the platform is evolving in a direction of inclusion and integration. Until the next summit in Philadephia, we encourage you to peruse the various videos from this past summit, try on Cloud Foundry from our various offerings (public, private, and Cloud Foundry Enterprise Environment) or the ones from the other sponsors, and plan your time to come to Cloud Foundry Day in Seattle in early December during KubeCon + CloudNativeCon North America 2018.

We look forward to seeing you at the Cloud Foundry Summit North America 2019 in Philadelphia in April!