In a presentation (I think it was from Rundeck) I heard the phrase “service is software running”. It makes a lot of sense. Software is useful when it is deployed and functional. Deploying software — getting the code running, solving real problems for their users (even if it is just one!) is a software developer’s pride and goal.
Yet, we many times leave the deployment process for later. Tomorrow. Next week. When the code is ready. Or we shy away, and let others take care of it. Too frequently, deployment happens because marketing mandates… Deployment is linked to “stability”, and change is seeing as a bad thing. We are kept at bay, since development equals change. Many times we developers just don’t want to take the responsibility…
It is refreshing to see that we are reacting! Just see the Agile, Lean, Craftsmanship, DevOps and other similar movements. Developers are assuming their responsibility and are increasing their participation in the deployment process. Under the banner of “Continuous Deployment”, we are learning tools and techniques to embrace change instead of preventing it. When change is a main part of the process, we can create stability without stagnation.
At JavaOne next week me and Edson Yanaga will discuss this. We’ll present the talk “The Deploy Factory: Open Source Tools for Java Deployment“. We’ll travel from roadblocks preventing us from embracing change, to actions we can do to solve some of those issues. Our focus is a lot on creating the infrastructure where deployment happens. Tools like Ansible, Puppet and Chef can script and automate our deployments. They show we can have a deeper influence in the end-to-end deploy process.
But something was missing… More and more we are entering the discussions around containers. Docker is grabbing all the attention. Containers offer new ways of creating managed environments, that are easy to use. PaaS and IaaS providers are consolidating their platforms, offering a powerful environment for developers. Although we do touch on some of those things in the talk, we think there are more things we can explore…
There is a vendor that we know well on the Java space that uses containers to provide a PaaS platform for developers. Jelastic. I was always intrigued on how Jelastic offers standards-based solutions in datacenters around the world. This does bring freedom and choice for developers. But both me and Edson have always focused on the “automate your own infrastructure” aspect, not on PaaS. As our talk at JavaOne suggests, we are pretty skeptical that a PaaS solution can provide the flexibility needed by developers.
Lets combine it all!
What brings us to this post… A few weeks ago, we met with Jelastic founder and CTO Ruslan Synytsky in his first trip to Brazil. Ruslan insisted on how the usage of containers can indeed create a flexible alternative in a PaaS solution. So, we decided to take it for a spin! Helped by Locaweb, a Brazilian cloud provider, we set up our own “personal cloud”. We are using Jelastic Private Cloud product, to test how far a solution based on containers can take us.
This was all the time we had before JavaOne, but the plan is to try it out in the next few weeks, and stress test it. Not for performance (after all, our private cloud is pretty limited), but for developer focus. Can a container-based solution provide developers with what they need? Can it be flexible, easy to use, provide control? Can it help out with deployment without limiting options? Does it support any architecture we are using in our projects? Will it lock me in to a specific vendor?
Those are valid questions that we would like to discuss. Jelastic and Locaweb are helping out, providing the necessary technical support. But the possibilities that containers bring to our projects go way beyond a single vendor. It impacts how we develop software!
So… what would you like us to probe? What fears do you have today when adopting solutions like PaaS, private clouds, containers, that we could test out? Do you have an application that you want to run in this environment? Get in contact (or tweet to @AskDevOps or #AskDevOps) and lets see what we can explore together! If you’re at JavaOne, come to our talk, lets experiment were this is all going!