Pivotal Cloud Foundry gives you an awesome way to run cloud-native apps. To be cloud-native, apps must obey certain rules such as being “stateless”. This means that state is stored in backing services like databases, data caches, or object storage, and not carried across transactions in application memory or local files. But what about applications that have a strong dependency on an accessible file system? Those applications make up a major part of business today, and in the past you would need to run those apps outside of PCF.
No longer. DellEMC, with extensive knowledge of Enterprise legacy apps, has implemented a solution for all PCF customers. In PCF 1.10, we announce Volume Services with out-of-the-box NFSv3 support. We have extended the definition of cloud-native to now include persisting state to files.
Let’s see how this came together. Meet Sarah—a composite of the customers we worked with to generate the right solution.
Sarah met the DellEMC Cloud Platform Team on Slack after a Cloud Foundry Summit. She explained a common problem encountered during the cloud-native transformation. When a new change is ready for release, it meanders through five different teams before finally reaching the customer. The elapsed time can take upwards of 7-10 days and sometimes multiple weeks.
She and her team quickly converted 10 apps to a cloud-native model, and deployed them on Cloud Foundry after seeing all the benefits. It completely changed things for them. Software changes could now be released directly and automatically to customers in a matter of seconds. All while getting built-in app resilience, centralized logging, high profile metrics, and more. They couldn’t convert apps fast enough.
Then it hit her...they had gone above and beyond and converted 10 apps in 2 years to cloud-native. Ten out of the thousands of apps they had running in their data center. As exquisite as new release process was, the pace to convert them wasn’t fast enough. So she began to look for new ways, maybe a different platform or a new advancement to allow persistent file storage in Cloud Foundry. Yet no plugin for her systems existed. She had all of the standard OAM&P concerns (Operations, Administration, Maintenance, and Provisioning). And she needed more than just an NFS mount command.
That’s when Sarah contacted us. Working with her and others like her, we ran through our product synthesis process. Additionally, we helped Sarah directly build the needed customizations. We discovered through this process that many customers are in the exact same boat.
Most customers have legacy apps talking to legacy systems it can take a long time to convert to a cloud-native model. We first started with building an NFSv4 plugin supporting Kerberos and LDAP. Unexpectedly, none of Sarah’s currently deployed legacy apps actually talked to an NFSv4 server. They all used NFSv3 with IP based security and required mounting as specific service user. In addition, while Sarah’s OAM&P process followed some patterns, ultimately she needed some customizations.
Armed with this information, we repeated the process with other “Sarahs” and found that in general, customers had NFSv3 deployments with existing data on them. We built our base offering for this specific case. By default, it utilizes a mount routine that bind mounts into Diego containers. You can send any of the standard NFSv3 mount options through parameters during the bind process. Additionally, the stock NFSv3 broker can be altered to support any of the OAM&P operations you need or it can be used as is to connect to a wide variety of Enterprise NFS systems (Isilon, ECS, NetApp, to name a few that were tested).
We brought all of this to you in the PCF 1.10 release. We redefined cloud-native storage and simplified the on-ramp to using it with both new and existing apps.
Now you have a roadmap to the future.
About the Author
Follow on Twitter
