Unlike most Platform as a Service offerings today, the open and extensible nature of Cloud Foundry means developers will not be locked into a single cloud or remain beholden to the feature set delivered based on a vendor’s timeline. This month, in our series of guest blogs by application developers, we are featuring the story of Cloudfuji, a modern business application store that uses Cloud Foundry to keep itself nimble and focused on getting to market quickly.
Guest blog by Sean Grove, co-founder of Cloudfuji:
We built Cloudfuji, our modern business application store, on the principle that amazing apps should be 1) easy to make, 2) easy to find, and 3) seamlessly work together. We all have had the experience of data getting stuck in the silos of our individual departmental support systems. Lacking integration, we have been forced to manually copy and paste data from one app to another or using one-off API integrations between the apps. In that scenario, the process of simply finding, trying, provisioning and maintaining the best application can be a nightmare.
With Cloudfuji’s application store, end users can find and instantly launch high-quality open source business applications for bug tracking, agile projects, or CRM, to name a few, that are loosely coupled in a publish-subscribe model with a standardized event schema. This allows them to work not only with each other, but also with the outside world and proprietary legacy applications. This also brings enterprise-wide visibility into events such as real-time notifications on product, sales and marketing activities, regardless of which specific apps are being used. The app development pattern becomes one of small, focused tools that excel at their specific function, and allow other apps to handle anything else. This is the future of the application ecosystem.
The future has demanding technical requirements
We use the Rails framework for our front end, which allows us to model our problem domain and iterate extremely quickly. Ruby is mainly used as a light layer for accessing more powerful services underneath such as Mailgun, Redis, RabbitMQ, and AWS S3. Once a user launches an app, we deploy it to the Binary Execution Environment (BEE).
Initially, we had built out our own LXC-based infrastructure, which was a Sisyphean and wasted effort in hindsight. We were continually reinvening a wheel called PaaS that was readily available in amazing forms right off the shelf. We tried a popular Ruby PaaS provider but faced challenges working with their closed platform as we had no influence over their release schedule.
When the open source Cloud Foundry project became available, we quickly got it running within two days without needing any support and had a provisioning system written for it within the week! Since then, we have scaled out our Cloud Foundry instance, built custom end-points to handle any deeper integration or visibility we need into the system and added CloudFoundry.com. The BEE is designed to be completely stateless and the data is decoupled from it. Because the BEE is not associated with data that an app relies on, we can replace it with a new one if the need arises, such as an outage in underlying infrastructure, and temporarily migrate the apps.
Why Cloud Foundry works for us
- Time-to-market: Although our experience with other PaaS layers led us on a convoluted path, we were able to immediately piggyback on the great work already done on Cloud Foundry. This meant we could stop focusing effort into the lower layers of PaaS–custom kernels, LXC-based para-virtualization, resource management, node health, routing systems, system-level library compatibility and consistency. Time is the biggest killer for startups, and we could easily have stalled in the quagmire of rolling out our own systems. We consider it a bullet dodged.
- Momentum: Having an open platform where the community can chip in means continuous improvement of the platform in faster cycles. When an open source project has the momentum of a whole community behind it, other projects simply cannot keep up. We’ve already benefited tremendously from work that wasn’t done by us, but by other extremely capable individuals. And in turn, when Cloudfuji needs a new feature, we have the choice of putting it out to the mailing list/community or rolling up our sleeves and writing it ourselves. And for all our respect for other platforms out there, none of them offer anything like this.
- Target API-identical clouds with a single config setting: Getting a Cloud Foundry system for development in the cloud is a very simple exercise. Although we’re currently also running our own instance of Cloud Foundry, ultimately we expect to be able to offload more to the CloudFoundry.com service when it comes out of beta and can match our demanding needs. We expect that transition to happen almost seamlessly because of the design of both our system and of the Cloud Foundry project.
- Flexibility to address changes to our business model: Finally, the ability to seamlessly run applications on multiple Cloud Foundry clouds, i.e., move from a public cloud to a private cloud, or vice versa, enables us to plan for a future offering where we can run a Cloudfuji appliance behind the firewall for parties that can’t use public clouds (for example, to meet local compliance needs or because of geographical location).
Taking the next steps
Applications should be easy to create and use. IT services should focus on their strengths and get end users the resources they need, when they need them. We live in a world where we get to take PaaS for granted and leverage great technology that is readily available. We all stand on the shoulders of giants, and we build more amazing products faster than ever before because of it. It’s a cycle we all need to embrace and increasingly reap the benefits from. Choose the open platforms that have strong leadership and excellent communities, and get behind them. It is amazing that we at Cloudfuji are building something of such scale and internal complexity, while staying lean and moving fast with the help of various communities. We couldn’t do all of that without Cloud Foundry.
Don’t have a Cloud Foundry account yet? Sign up for free today
About the AuthorMore Content by Cloud Foundry