Cloud Foundry and 12-Factor applications are great to create Cloud Native Applications and has become the standard. But you and I don’t just have to worry about our new 12 Factor apps, we also have legacy applications in our family. Our position is that your traditional apps and your new cool 12-Factor apps should be able to experience the benefits of running on Cloud Foundry. So, we have worked to create a world where your legacy apps and new apps can live together.
In the past, Cloud Foundry applications cannot use any filesystem or block storage. That totally makes sense, given that Cloud Foundry apps are executed in elastic containers, which can go away at any time. And if that happens, any data written to the local filesystem of the containers will be wiped.
If we can externalize persistent storage to be a service – and bind and unbind those services to Cloud Foundry applications – a lot more apps can run in Cloud Foundry. For example, heavy data access apps, like databases and video editing software, can now access extremely fast storage AND at the same time experience the scalability and reliability provided by Cloud Foundry.
Allowing Cloud Foundry applications to have direct persistence access opens a lot of doors for developers. Traditional applications that require persistence can migrate to Cloud Foundry a lot easier. Big Data Analytics applications can now use persistence to perform indexing and calculation.
Traditionally, a lot of data services consumed by Cloud Foundry applications, such as MySQL, Cassandra, etc, need to be deployed by Bosh as Virtual Machines. With Persistence, we can start looking bringing these services to run in Cloud Foundry or create the next generation of Cloud Native data services.
What can Developers Expect?
When developers come to the Cloud Foundry marketplace by using cf marketplace, they will see services that can offer their applications persistence:
The details of the service plan can be seen by cf marketplace -s ScaleIO
This is a plan that would offer 2GB of storage for your Cloud Foundry applications. Let’s sign up for it by running cf create-service scaleio small my-scaleio-service1
By creating a service instance, the ScaleIO Service Broker goes into ScaleIO and creates a volume of 2GB. We are now ready to bind this new service to our app. To demonstrate the functionality, we have created a very simple application that will write and read to the filesystem:
After a cf bind-service call, the storage will be mounted as a directory and the path will indicate an environment variable inside the service. For example:
<a href="http://dojoblog.emc.com/wp-content/uploads/2016/05/Screen-Shot-2016-05-20-at-11.35.07-AM.png"><img class="alignnone wp-image-295 size-Standard" src="http://dojoblog.emc.com/wp-content/uploads/2016/05/Screen-Shot-2016-05-20-at-11.35.07-AM-820x422.png" alt="Screen Shot 2016-05-20 at 11.35.07 AM" width="820" height="422" /></a>
Based on the container_path variable, the application can read and write as if it’s a local filesystem.
Tags: 12 factor, cloud foundry, cloudfoundry, dojo, emc, emc dojo, EMCdojo, legacy, lift, monolith, persistence, scaleio, shift, traditional