The speed of innovation these days is often influenced by the speed of adoption of new and exciting tools, and specifically open source tools. Open source projects have been growing at an exponential speed over the course of the past few years; however the process for exploring, testing, configuring, and ultimately integrating these in production often times is still quite complex and time consuming. In many cases, this process is still done manually. Like with all DevOps processes by automating this, we are then able to adopt new tooling much more quickly, and with less human error in the process.
The Open Source Revolution
The friction in this process is due, in large part, to the fact that each of these stages from exploration through POC and testing, integration and then management, many times requires the use of very different tools for each stage, on top of a completely different setup and environment. This means that every time you want to move from exploration to testing, for example, you have to basically rebuild the entire system. This can become quite frustrating and, as mentioned above, time consuming.
What if we could streamline this process and explore tens and even hundreds of projects quickly, thereby enabling us to seamlessly increase our innovation?
How this could work – the flow:
Exploration: Explore the product without having to install any software at all. This could be through a click of a button on Github, and seeing the product in action. This would enable you to play with it without having to download, configure, or set up any machines.
Testing: When we move to trying it out, we want to use the same model as in the exploration phase. We’d like to try it out also on a SaaS basis, but this time with more control. By this I mean testing with real clusters & machines, in a more high performance, and production-like environment.
Development: At this stage, we want to be able to test it with our actual stack, and plug it into our project quickly. Then, eventually at a later stage download it and run it in our own environment.
What’s Needed
With a unified tool for all of these stages, the majority of the friction in the process can be diminished. One way to achieve this is by running the project as a service or in our environment, with an orchestration engine that can basically be used to take us through all these stages.
By wrapping the entire project into an uber-launcher [which with Cloudify we call it “the widget”] that any open source project can plug into – like an app store or repository, and any user can start using immediately without necessarily having to know how exactly it runs or works.
The nice thing is that we can eventually take the software from that app catalog or store, since it’s not packaged as a black box but rather as a blueprint or script. We can then fork it and customize it to our needs. Because of this, we can actually use the same tools through the entire cycle and break the friction completely.
So what it all boils down to, is the basic principle of combining the power of SaaS and cloud orchestration to avoid complexity of installation, use a script-based model to make the packaging of software generic – but still customizable, and use a cloud abstraction to move environments without having to change recipe. This is what we call the automation continuum, and we’ve been using to demonstrate how to take the power of any open source project to any cloud.