Archive for the ‘Cloud Foundry’ Category

Cloud Foundry on Kubernetes

Amanda Alvarez

Amanda Alvarez

Amanda Alvarez

Latest posts by Amanda Alvarez (see all)

Hello 🙂

The Dojo team is here again. Recently, we worked on a project called Cloud Foundry (CF) on Kubernetes (K8S) and we are thrilled to share with you how we did it.

Table of contents:
1. Why CF on K8S?
2. Architecture
3. Demo Video

1.Why CF on K8S?

Putting CF on K8S is a good idea because of its ease of deployment, resource utilization, and flexibility.

  • The overall deployment of CF on K8S is simpler than other IaaS because creating and destroying containers is quicker than that of VMs. Therefore, we are saving a significant amount of time and resources when we deploy CF components, which involves more than ten VMs. Woah! 😮
  • Having CF on K8S helps utilize resources better. A traditional Diego Cell VM consumes more resources when NATS or Consul VMs are deployed as separate VMs because resources are assigned to each VM. For example, the NATS and Consul VMs each need 2GB of RAM on top of the Diego Cell using 5GB of RAM, but this not an efficient way of using resources as this is not scalable. Instead of deploying two VMs for NATS and Consul, we can deploy these as jobs using two containers sitting inside a node (or VM) that the Diego Cell has access to. Inside these nodes, the containers share the same resources that are allocated for the VMs.
  • We can pretend K8S is acting as an IaaS to put CF on top of. Knowing this, CF can be in any environment K8S is on because K8S can be deployed on top of any IaaS (including bare metal).

2.Architecture

Figure 1: CF on K8S on GCP architecture
There is a Kubernetes cluster of nodes (or VMS) that reside in GCP. Inside of the Kubernetes cluster, there are CF components that are utilizing K8S nodes. The Diego Cells nodes are separate from the main CF components because it is difficult to run containers within a container (as Diego is also a container orchestrator).

3.Demo Video

Special thanks to the kubernetes bosh cpi team from SAP for helping us. Please check out their repo at kubernetes_cpi.

Deploy Kubernetes on vSphere using BOSH – Kubo

Introduction


During CloudFoundry Summit 2017, Kubo was released. The name originated from the combination of Kubernetes and Bosh. Now we can deploy Kubernetes on many different IaaS using Bosh. It’s the first step to integrate Kubernetes into CloudFoundry.

In this post, we are going to deploy a Kubernetes instance on vSphere using Bosh.

Prerequisite


We suppose you already have a Bosh Director running, one public network and one private network ready on vSphere. Your cloud-config would look like this:

cloud-config.yml

All capitalized fields and IP fields should be replaced with correct values based on your vSphere settings.

We use our bosh director as private network gateway by setting up iptables on bosh director following this instruction.

Deploy


We are going to use kubo-release from CloudFoundry Community. More deploy instructions could be found here.

1. Download releases

We need to download three releases: kubo, etcd and docker. Then upload them to bosh director.

2. Generate certificates

Kubernetes requires certificates for the communication between api server and kubelets, and also between clients and api server. The following script will do the job for us. Replace API_PRIVATE_IP and API_PUBLIC_IP with private IP and public IP for Kubernetes api server.

key-generator.sh

3. Fill bosh deployment manifest

Replace the red fields with the correct values. And paste the contents of the certificate files, generated above, into the correspondent fields.

kubernetes.yml

In order to access deployed Kubernetes instance, we need to create a config file:

~/.kube/config

After your bosh deployment is done, you should be able to type kubectl cluster-info and see this:

Test


We can test our Kubernetes by creating a simple Redis deployment using following deployment file:

redis.yml

kubectl create --filename redis.yml will deploy redis. If we type kubectl describe pods redis-master, we should not see any errors.

If you have any questions, leave a comment here or email xuebin.he@emc.com. Thank you!

Running Legacy Apps on CloudFoundry with NFS How to re-platform your apps and connect to existing shared volumes using CloudFoundry Volume Services

How to re-platform your apps and connect to existing shared volumes using CloudFoundry Volume Services

This week the Cloud Foundry Diego Persistence team released the 1.0 version of our nfs-volume-release for existing NFS data volumes.  This Bosh release provides the service broker and volume driver components necessary to quickly connect Cloud Foundry deployed applications to existing NFS file shares.

In this post, we will take a look at the steps required to add the nfs-volume-release to your existing Cloud Foundry deployment, and the steps required after that to get your existing file system based application moved to Cloud Foundry.

Deploying nfs-volume-release to Cloud Foundry

If you are using OSS cloud foundry, you’ll need to deploy the service broker and driver into your cloudfoundry deployment.  To do this, you will need to colocate the nfsv3driver on the Diego cells in your Cloud Foundry deployment, and then run the nfs service broker either as a Cloud Foundry application or a BOSH deployment.

Detailed instructions for deploying the driver are here.

Detailed instructions for deploying the broker are here.

If you are using PCF, nfs-volume-release is built in.  As of PCF 1.10, you can deploy the broker and driver through simple checkbox configuration in the Advanced features tab in Ops Manager.  Details here.

Moving your application into Cloud Foundry

There are a range of issues you might hit when moving a legacy application from a single server context into Cloud Foundry, and most of them are outside the scope of this article.  See the last section of this article for a good reference discussing how to migrate more complex applications.  For the purposes of this article we’ll focus on a relatively simple content application that’s already well suited to run in CF except that it requires a file system.  We’ll use servocoder/RichFileManager as our example application.  It supports a couple different HTTP backends, but we’ll use the PHP backend in this example.

Once you have cloned the RichFileManager repository and followed the set up instructions, you should theoretically be able to run the application in Cloud Foundry’s php buildpack with a simple cf push from the RichFileManager root directory:

But RichFileManager requires the gd package which isn’t included by default in the php buildpack.  If we push the application as-is, file upload operations will fail after RichFileManager dies while trying to create thumbnail images for uploaded files.  To fix this, we need to create a .bp-options directory in the root folder for our application and put a file named options.json in it with the following content:

Re-pushing the application fixes the problem.  Now we are able to upload files and use all the features of RichFileManager:

But we aren’t done yet! By default, the RichFileManager application stores uploaded file content in a subdirectory of the application itself.  As a result, any file data will be treated as ephemeral by cloudfoundry and discarded when the application restarts.  To see why this is a problem, upload some files, and then type:

When you refresh the application in your browser, you’ll see that your uploaded files are gone!  That’s why you need to bind a volume service to your application.

In order to do that, we first need to tweak the application a little to tell it that we want to put files in an external folder.  Inside the application, open connectors/php/config.php in your editor of choice, and change the value for “serverRoot” to false.  Also set the value of “fileRoot” to “/var/vcap/data/content”.  (As of today, cloudfoundry has the limitation that volume services cannot create new root level folders in the container.  Soon that limitation will be lifted, but in the mean time, /var/vcap/data is a safe place to bind our storage directory to.)

Now push the application again:

When you go back to the application, you should see that it is completely broken and hangs waiting to get content.  That’s because we told it to use a directory that doesn’t yet exist.  To fix that, we need to create a volume service, and bind it to our application.  You can follow the instructions on the nfs-volume-release to set up an nfs test server in your environment, or if you already have an NFS server available (for example, Isilon, ECS, Netapp or the like) you can skip the setup steps and go directly to the service broker registration step.  Once you have created a volume service instance, bind that service to your application:

If you are using an existing NFS server, you will likely need to specify different values for uid and gid.  Pick values that correspond to a user with write access to the share you’re using.

Now restage the application:

You should see that the application now works properly again.  Furthermore, you can now “cf restart” your application, and “cf scale” it to run multiple instances, and it will continue to work and to serve up the same files.

Caveats

Volume services enable filesystem based applications to overcome a major barrier to cloud deployment, but they will not enable all applications to run seamlessly in the cloud.  Applications that rely on transactions across http requests, or otherwise store state in memory will still fail to run properly when scaled out to more than one instance in cloud foundry.  CF provides best-effort session stickiness for any application that sets a JSESSIONID cookie, but no guarantees that traffic will not get routed to another instance.

More detail on steps to make complex applications run in the cloud can be found in this article.

Doers for Today, Visionaries for Tomorrow and Change Agents for Always! We Truly Are The Trifecta

We Truly Are The Trifecta

Emily Kaiser

Emily Kaiser

Head of Marketing @DellEMCDojo #CloudFoundry #OpenSource #TheWay #LeanPractices #DevOps #Empathy

The Dell EMC Dojo has a mission that is two-fold; we contribute to open source Cloud Foundry, and we evangelize ‘the way’ (XP, Lean Startup, etc) by engaging with internal Dell EMC teams in a purely DevOps manner. Our mission is direct with a scope that some could argue is boundless. By practicing ‘the way,’ hours, days, and weeks fly by as we push code to production at times every few minutes. Not only is our push to market rapid, so is our overall productivity. Oftentimes teams working with us nearly guffaw when they come to our office in Cambridge, MA and are able to see the ‘wizard(s) behind the curtain.’ We are asked how we keep three to five projects on track while also engaging with internal teams, planning large technical conferences, and working in the realm of R&D in our greater TRIGr team with an east coast contingent of only eight people and a west coast contingent of five. The secret? We LOVE what we do!

 

A team with empathy at its core, there is never a moment when a task seems impossible.

Truly, we could be featured on one of those billboards along the highway stating that there is no ‘I’ in ‘Team.’ Two baseball players carrying an opposing team member across Home because she/he has hurt themselves, a photo of all of the characters from Disney’s “The Incredibles,” The Dell EMC Dojo team… Take your pick… TEAMWORK. Pass It On.

In all seriousness, the pace at the Dojo can be absolutely exhausting, and with such a small team, the absence of one person (which let’s face it, vacation and life needs to happen at points) could in theory be a huge deal. But, because DevOps is what we live and breathe, any member of the team can fill this gap at any point, truly putting to practice the idea that there doesn’t have to be and should never be a single-point-of-failure. Albeit the industry or sector, what more emulates the ‘Go Big, Win Big’ message than this? By continually pushing ourselves to pair and to up-level the knowledge of our entire team, we never wait until tomorrow to take action. There is no need or desire to.

 

Agility is not a term we just talk about, but is simply inherent to everything we do.

With the combination of the rapidly changing market (externally and internally) and the pace in which we work, we at the Dojo have learned that we must stay on our toes. For those reading this that are familiar with sports, one of the first lessons learned in soccer is to never plant your feet. Holding such a stance allows for the opposing team to outpace you when the unexpected happens, which is most of the time. Same goes here. Pivoting is now second nature for us, and it doesn’t come with the scares. Instead, it is actually exciting when we are able to take data and identify ways in which we can better align with efficiency and effectiveness of software and methodology; to truly keep the user omnipresent in everything we do. We are happier. The ‘customer’ is happier. It is a (Go Big) win-win (Big) game. The cool thing too is that the more we practice this, the more we also feel somewhat like we can predict the future, because we begin to see trends before they are even a thing.

 

 

Doers for Today. Visionaries for Tomorrow. Change Agents for Always.

Cloud Foundry Certified Developer Program Your Exclusive Chance to be in the BETA

Your Exclusive Chance to be in the BETA

Emily Kaiser

Emily Kaiser

Head of Marketing @DellEMCDojo #CloudFoundry #OpenSource #TheWay #LeanPractices #DevOps #Empathy

It is with unbridled excitement that we continue to prepare for Cloud Foundry Summit in Santa Clara. Here at the DellEMC Dojo and the larger Technology, Research, Innovation Group of DellEMC, gears are constantly turning and research and development is moving at a pace unprecedented. We are so excited to share some of these findings and demos with all those related to and involved with the Foundation.

While all is under works, we want to ensure that we and all those we care about are taking up every opportunity possible to continue to develop ourselves further as thought provoking leaders in the industry and in the world. Part of this is keeping ourselves relevant in what exists and then further acting as promoters for the solutions we have found work best. Which brings me to the reason for writing this blog post.

If you have not yet heard, The Cloud Foundry Foundation has been working toward the launch of a “Cloud Foundry Certified Developer” program. The date is getting closer and closer to its unveiling, and it is now more pressing to share the intent of the program so that all wanting and willing to get involved take the opportunity to do so.

The intent of the program is to use a performance-based testing methodology to certify that individual developers/engineers have the skills necessary to be productive developing applications on top of the Cloud Foundry platform. This will allow for a better streamlined data-driven approach to the way we contribute to the Open Source community and our more intimate communities as well. To be active leaders in this realm should be something we are striving for daily. To be PRODUCTIVE active leaders who can then go forth and teach with a congruent and strong set of skills is the mark we should be making, reaching and expanding. So here is how:

The Foundation is currently accepting applications from individuals that may want to participate in the BETA or early access program. If you (or anyone in your organization) are interested in being among the first certified developers, please use the Google Form found here to register interest: https://docs.google.com/forms/d/e/1FAIpQLSeXtGUMLyJ3NkJQLnWhXCafh3SgziHr1fsSYM7mXi6JPcLaPw/viewform

A NOTE: All applications for participation should be filed by March 10th.

The space is limited so the BETA program will be short-listed to 30 candidates, and will communicate with everyone completing the form as to their acceptance into the program. Those that are not accepted will be offered an opportunity to enter the early access phase of the rollout. Developers that pass the exam either during the BETA or early access will get a fancy CF Certified Dev sweatshirt, also… so no harm, no foul!

The BETA period will begin on March 20th and close on March 31st. Candidates will be asked to use the system to schedule a four hour exam window during the two weeks of BETA testing.

Passing the exam requires practical hands-on skills in the following: (1) CF Basics, (2) Troubleshooting Applications and CF Configurations, (3) Application Security, (4) Working with Services, (5) Application Management, (6) Cloud Native Architectural Principles, (7) Container Management within CF, (8) Candidates should be comfortable modifying simple Java, Node.js or Ruby Applications.

You think you have what it takes? We think you do too. So apply today!

TCP Routing and SSL: A Walkthrough Using Spring Boot An incredible guest blog by Ben Dalby, Advisory Consultant at DellEMC

An incredible guest blog by Ben Dalby, Advisory Consultant at DellEMC

Emily Kaiser

Emily Kaiser

Head of Marketing @DellEMCDojo #CloudFoundry #OpenSource #TheWay #LeanPractices #DevOps #Empathy

Walkthrough: Cloud Foundry TCP Routing and SSL

Guest Blog by Ben Dalby, Advisory Consultant (Applications and Big Data) at DellEMC

Use Cloud Foundry’s TCP routing feature to terminate SSL directly in your application

Introduction

A common security requirement for customers in regulated industries such as banking and healthcare is that all traffic should be secured end-to-end with SSL.

Prior to Pivotal Cloud Foundry 1.8, inbound SSL connections would always terminate on the Gorouter, and further encryption could only be achieved between the Gorouter and running applications by installing Pivotal’s IPsec Add-on

With the introduction in version 1.8 of TCP routing, it is now possible to terminate SSL right at your application – and this article will walk you through a working example of a Spring Boot application that is secured with SSL in this way.

Prerequisites

PCF Dev version 0.23.0 or later
JDK 1.8 or later
Gradle 2.3+ or Maven 3.0+
git (tested on 2.10.1)
A Linux-like environment (you will need to change the file paths for the directory commands to work on Windows)

How to do it

Step 1 – Create a Spring Boot application

We’re going to be lazy here, and simply make a couple of small modifications to the Spring Boot Getting Started application:

Step 2 – Create an SSL certificate

Step 3 – Configure Spring Boot to use SSL and the new certificate

(You can also retrieve the application.properties shown below from here)

Step 4 – Package the application

Step 5 – Push the application to PCF Dev (use default org and space)

Step 6 – Create a TCP route and map it to your application

Step 7 – Verify you can now connect directly to your application over SSL

Browse to https://tcp.local.pcfdev.io:61015/ (substitute your own port after the colon):

View details of the certificate to verify it is the one you just generated (note the procedure has just changed if you are using Chrome):

Further Reading

Enabling TCP Routing
http://docs.pivotal.io/pivotalcf/1-9/adminguide/enabling-tcp-routing.html

How to tell application containers (running Java apps) to trust self-signed certs or a private/internal CA https://discuss.pivotal.io/hc/en-us/articles/223454928-How-to-tell-application-containers-running-Java-apps-to-trust-self-signed-certs-or-a-private-internal-CA

Enable HTTPS in Spring Boot
https://drissamri.be/blog/java/enable-https-in-spring-boot/

Do You Hear That? It’s the sound of Keyboards! Call for Papers | Cloud Foundry Summit Silicon Valley 2017 is quickly approaching!

Call for Papers | Cloud Foundry Summit Silicon Valley 2017 is quickly approaching!

Emily Kaiser

Emily Kaiser

Head of Marketing @DellEMCDojo #CloudFoundry #OpenSource #TheWay #LeanPractices #DevOps #Empathy

Our brains are on fire, our keyboards are hot, and the joke in the office the past few days has been over our extreme excitement for the eventual need to buy sunscreen since our Boston winter leaves us Vitamin D deprived. Why is this the case, you may or may not be asking? Well, I plan on telling you anyway because it is just too exciting not to share!

Our team is preparing for CLOUD FOUNDRY SUMMIT SILICON VALLEY! We felt a social duty to let all of those we care about and want to be there with us for what’s sure to be the summit of the summer (how can it not be when it is being held in June in Santa Clara?!), that the last call for papers is quickly approaching (no seriously, it’s this Friday, February 17th).

Just as a refresher for those on the fence, Cloud Foundry Summit is the premier event for enterprise app developers. This year the Foundation, through market research and feedback, found that interest and industry need is engrained in the focus on innovation and the streamlining of development pipelines. For this reason, Summit 2017 is majorly honing in on microservices and continuous delivery in developers’ language and framework of choice. That is why the session tracks available will be Use Cases, Core Project Updates, Experiments, Extension Projects, and Cloud Native Java. Each session that is chosen for the conference is enabled (1) primary speaker and (1) co-speaker. The primary speaker receives a complimentary conference pass while the co-speaker receives a discounted conference pass. So what’s stopping us from getting involved? Absolutely NOTHING!

As a sneak peak to a few of the topics our team have submitted for approval, see below:

  • Adopting DevOps and Building a Cloud Foundry Dojo (Lessons Learned)
  • Lift & Shift Your Legacy Apps to Cloud Foundry
  • How to Develop Scalable Cloud Native Application with Cloud Foundry
  • Enabling GPU-as-a-Service in Cloud Foundry
  • Blockchain as a Service
  • Avoiding pitfalls while migrating BOSH deployments
  • Spring Content: Cloud-Native Content Services for Spring

 

So, now what’s stopping YOU from getting involved? Submit papers here: https://www.cloudfoundry.org/cfp-2017/ and/or register here: https://www.regonline.com/registration/Checkin.aspx?EventID=1908081&utm_source=flash&utm_campaign=summit_2017_sv&utm_medium=landing&utm_term=cloud%20foundry%20summit&_ga=1.199163247.1732851993.1460056335

Last but definitely not least, let us know if you plan on coming—we are more than happy to share sunscreen 🙂 We cannot wait to see you there!

Getting Started with Cloud Foundry Volume Services Trying out Persistent File Systems in Your Cloud Foundry Applications with PCFDev

Trying out Persistent File Systems in Your Cloud Foundry Applications with PCFDev

This week, the PCFDev team released a new version of PCFDev that includes local-volume services out of the box.  This new release of PCFDev gives us an option to get up and running with volume services that is an order of magnitude easier than any of the options we had before. We thought it would be a good time to write a post detailing the steps to try out volume services with your Cloud Foundry applications, now that the post doesn’t need to be quite so long.

1. Install PCFDev

(Time: 30-90 minutes, depending on your internet connection speed, and what you already have installed.)

Instructions for PCFDev installation can be found here.  Installation requires VirtualBox and the Cloud Foundry CLI, and you will need to have (or create) an account on Pivotal Network.  Don’t be deterred.  It’s free and easy.  If you already have PCFDev, make sure that you have version 0.22.0 or later.

Once you have installed PCFDev and successfully started it up, you should see something like this:

screen-shot-2016-11-16-at-4-39-13-pm

Now log in and select the pcfdev-org space:

2. Create a New Volume

(Time: 1 minute)

If you have the right version of PCFDev, then the local-volume service broker should already be installed.  You can tell this by typing

You should see local-volume in the list of available services:

screen-shot-2016-11-16-at-4-43-59-pm

Use cf create-service to create a new file volume that you can bind to your application:

3. Push an Application

(Time: 5 minutes)

For the purposes of this blog post, we’ll use the “pora” test application that we use in our persi CI pipeline. “Pora” is the persistent version of the Cloud Foundry acceptance test “Dora” application.  It is a simple ‘hello world” app that writes a message into a file, and then reads it back out again.

To get the Pora app, first clone the persi-acceptance-tests github repo:

Now change to the pora folder, and push the app to cf with the “no-start” option:

4. Bind the Service to the Application and Start the App

(Time: 5 minutes)

The cf “bind-service” command makes our new volume available to the Pora application.

Now start the pora application:

Once the app is started, you can use curl with the reported url to make sure it is reachable.  The default endpoint for the application will just report back the instance index for the application:

To test the persistence feature, add “/write” to the end of the url.  This will cause the pora app to pull the location of the shared volume from the VCAP_SERVICES environment variable, create a file, write a message into it, and then read the message back out:

5. Use Persistent Volumes with Your Own Application

By default, the volume service broker will generate a container mount path for your mounted volume, and it will pass that path into your application via the VCAP_SERVICES environment variable. You can see this when you type “cf env pora” which produces output like this:

In your application, you can parse the VCAP_SERVICES environment variable as json and determine the value of “container_path” to find the location of your shared volume in the container, or simply parse out the path with a regular expression.  You can see an example of this code flow in the Pora application here.

If it isn’t practical to connect to an arbitrary location in your application for some reason, (e.g. the directory is hard coded everywhere, or your code is precompiled, or you are reluctant to change it) then you can also tell the broker to put the volume in a specific location when you bind the application to the service.  To do that, unbind the service, and then rebind it using the -c option.  This will create any necessary directories on the container, and put the volume mount in the specific path you need:

Type “cf restage pora” to restart the application in this new configuration, and you should observe that the application operates as before, except that it now accesses the shared volume from “/my/specific/path”.  You can also see the new path transmitted to the application by typing “cf env pora”.

6. If You Need to Copy Data

If you need to copy existing data into your new volume in order for your application to use it, you will need to get the data onto the PCFDev host, and then copy it into the source directory that the local-volume service uses to mimic a shared volume.  In a real-world scenario, these steps wouldn’t be necessary because the volume would come from a real shared filesystem that you could mount and copy content to, but the local-volume service is a test service that mimics shared volumes for simple cloudfoundry deployments.

The key that PCFDev uses for scp/ssh is located in ~/.pcfdev/vms/key.pem.  This file must be tweaked to reduce its permissions before it can be used by scp:

Now invoke scp to copy your content across to the PCFDev VM.  The example below copies a file named “assets.tar” to the var/vcap/data directory on the VM:

Now, use “cf dev ssh” to open a ssh session into the vm, and cd to /var/vcap/data.  You should find your file there:

“ls volumes/local/_volumes” gives us a listing of the volumes that have been created.  If you are following this tutorial, there should be only one directory in there, with a long ugly name.  Move the file into that directory, and then exit the ssh session

Finally, invoke “cf ssh pora” to open a ssh session into the cloudfoundry app.  This will allow you to verify that the data is available to your application.  If you used the -c option to specify a mount path, you should find your content there.  If not, you will find it under “/var/vcap/data/{some-guid}”:

7. Where to Find More Information

The best place to reach the CF Diego Persistence team is on our Slack channel here: https://cloudfoundry.slack.com/messages/persi/. We’re happy to hear from you with any questions you have, and to help steer you in the right direction.

If you don’t already have an account on CF slack, you can create an account here: https://cloudfoundry.slack.com/signup

For an introduction to Volume Services in Cloud Foundry, refer to this document: http://bit.ly/2gHPVJM

Or watch our various presentations this year:

CF Summit Frankfurt 2016: https://www.youtube.com/watch?v=zrQPns47xho

Spring One Platform 2016: https://www.youtube.com/watch?v=VisP5ebZoWw

CF Summit Santa Clara 2016: https://www.youtube.com/watch?v=ajNoPi1uMjQ

Bringing Cloud Foundry to You… Exciting Upcoming Events that the Cool Kids are Attending

Exciting Upcoming Events that the Cool Kids are Attending

Emily Kaiser

Emily Kaiser

Head of Marketing @DellEMCDojo #CloudFoundry #OpenSource #TheWay #LeanPractices #DevOps #Empathy

For those of you who follow us on Twitter (@DellEMCDojo for those that don’t) or via this blog, I would guess it is pretty evident that we just love Cloud Foundry. We take pride in being a member of the foundation mostly because it is with this platform that we feel we are delivering and practicing what we preach; living out a true DevOps culture most conducive to productivity and quality product and delivery.

We are lucky enough to just be returning from Cloud Foundry Summit where upwards of 800 developers and other market adopters joined in Frankfurt, Germany to learn from other community members and to be a part of the PaaS’s business direction. With the Native Hybrid Cloud team, we at the Dojo spent our days representing DellEMC through presentations and booth shifts. We left feeling even more confident in our daily choice to use Cloud Foundry and to further evangelize the PaaS for the betterment of the larger technical OS community.

It is because of this that we are excited to announce that we will be hosting and supporting three Cloud Foundry Days here in the near future. Cloud Foundry Days are new, one-day educational events aimed at developers and operators who want to connect with businesses, learn about the platform, and share knowledge. The first that we will be hosting with the support of TIBCO, Pivotal, Telstra, Stark & Wayne, among others, is going to be taking place on October 18th in Sydney, Australia. If you have any interest in attending or know of others who may be, please find the registration link here: https://www.eventbrite.com.au/e/cloud-foundry-day-sydney-australia-tickets-27935602138. The second of these events will be taking place on October 20th in Melbourne, Australia and will also be supported by TIBCO, Pivotal, Telstra, Stark & Wayne, among others. The registration link for this event can be found here: https://www.eventbrite.com.au/e/cloud-foundry-day-melbourne-australia-tickets-27985249635. Last, but definitely not least, is the CF Day in Shanghai, China on October 25th where we will be supporting GE (Registration information to be available within the next day or two. Please contact us via twitter if you are interested).

We truly hope that these events will be fruitful in their reach and effectiveness, and help our technical community discern the best option for themselves and the businesses they affect. Teamwork makes the dream work!

NFS app support in under 5 minutes with CloudFoundry, Wahooo!

Peter Blum

Developers want quick and easy access to storage! They don’t care how they get it, they just want it now. Let me show you how a developer can go from 0 to 100 with persistence in CloudFoundry, starting with Dell EMC Isilon.

Cloud Foundry. Open Source. The Way. Dell EMC [⛩] Dojo.

Follow Us on Twitter

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.