From the beginning, Cloud Foundry has been about simplifying the development, deployment and operation of cloud applications. In this second post in a series of guest blogs by application developers, we bring the story of OpenCredo and how Cloud Foundry helped to launch three new products for a major insurance company in just seven months instead of what would typically take years.
Guest blog by Russell Miles, CEO of OpenCredo
OpenCredo is a software professional services company that provides technology training and software delivery for clients who are typically facing interesting IT challenges in launching new products and testing new markets. We employ lean and agile methods to focus on building rapid business value. Based in London, OpenCredo’s clients include many blue-chip organizations across Europe and North America.
In July 2011, we came upon the opportunity to build products for one of the largest independent insurance underwriters in London. The company is introducing new insurance products into specific vertical markets, and trying new distribution techniques as older products are increasingly becoming commoditized and commissions eaten up by intermediaries.
We were confident in our capabilities and choices of technology for the project – Scala, Lift and Cloud Foundry. By industry standards, such products typically take up to 2 years to build, but we set out to deliver 2 products with the goal of being in the market in just 2-3 months and a third product to follow soon after that.
Frequent changes from the client were expected (e.g. compliance needs, policy updates etc.) and going at the pace of a weekly release would simply not have worked for the proposed time frame. Also adding to the unknowns was that the product would be marketed and distributed by one of the world’s largest online retailers – this meant it has to quickly scale to handle unpredictable spikes in traffic.
We had 3-6+ people working in parallel on these products. Scala was chosen for its sophisticated type system needed by the complex data model in the quoting engine and for its ability to work well with both SQL and NOSQL databases. Lift provided a good database integration layer. At first Cloud Foundry was not in our design plans, but a few things changed that:
- Lift support was announced
- We were able to code to a cloud deployed on our local machine (Micro Cloud Foundry) and thus reduce surprises when deploying to the staging instance
- There was no need to deal with several differently configured SQL services. We just took the application and ran it on Cloud Foundry and we were done from persistence layer to the web layer
- Cloud Foundry lowered the barrier to polyglot programming. When extending product functionality, we are now experimenting with Node.js and Redis in prototypes. Rather than installing and extending a new environment, Cloud Foundry is practical in that it offers everything in one environment. Cloud Foundry brought together multiple technologies so that the right tool for the job could be chosen.
- Lastly, one of the nicest things about Cloud Foundry was that “it got perfectly out of the way”. Prior to using Cloud Foundry, it had been very difficult getting feedback from the client who is located in a different city. So, OpenCredo had to provision our own server, work with our system administrator to open it to the client, and then regularly deploy the app onto the server. This included provisioning our own databases etc. All of this took up significant cycles of time. By using Cloud Foundry, the effort reduced to zero to get the feedback from the client.
High Level Architecture Diagram
Performance is currently being tested, but the product was architected in anticipation of high volumes of traffic and, while scaling is not automatic, Cloud Foundry can easily be made to scale quickly to offer more instances without any downtime.
Our process was also a key enabler for our rapid development and deployment goals. We have 3 instances of Cloud Foundry running– one for staging where the applications are deployed first, and one production instance for each application. Each instance just differs on scale. Firstly, the product owner provided us with requirements and we implemented and commited the code to Github after testing the code against Micro Cloud Foundry. Jenkins, which is being used for continuous integration, regularly polls for changes in the code. The project is set up to build, and then automatically release from the CI server and then, upon testing success, automatically manage the push to the staging environment. Upon feature validation from the client, a click of a button runs a further script which pushes the binaries to the production environment. This is a streamlined and almost fully automated process in keeping with our company’s lean and agile philosophies of maximizing value and eliminating errors and waste.
High Level Development and Deployment Process
It turned out that with the streamlined and automated deployment process, and because of the way Scala, Lift and Cloud Foundry work together, the client’s product could be updated in a tenth of the time it normally took going from a few hours to a few minutes per iteration. With this winning combination of technology and process, the client was able to get to market much sooner with their products.
The most recent product launched for the insurer was Web Trader which is their third product in seven months using Scala Lift and Cloud Foundry. This is a new insurance product specifically designed for the SME with a heavy web presence, clearly an appropriate use for a technology such as this with a company such as ours.
I would like to say, “Happy ending”, but really what we have is a happy beginning for three new products with more to come.
Signup for Cloud Foundry today, and start building your own cool app!
About the Author
