FAQ

What is Roboconf?

Roboconf is a platform to manage elastic deployments in the cloud.
It manages deployments, probes, automatic reactions and reconfigurations. It can be defined as « Paas framework »: a solution to build Platform as a Service. Most PaaS, such as Cloud Foundry or Openshift, target developers and support application patterns. However, some application require more flexible architectures or design. Roboconf addresses such cases.

With Roboconf, you can create PaaS for any programming language, any kind of application and any operating system. You define what you put in your platform, you specify all the interactions, administration procedures and so on.

How does it work?

Roboconf takes as input the description of a whole application in terms of “components” and “instances”. From this model, it then takes the burden of launching Virtual Machines (VMs), deploying software on them, resolving dependencies between software components, updating their configuration and starting the whole stuff when ready. Roboconf also handles the application life cycle: hot reconfiguration (e.g. for elasticity issues) and consistency (e.g. maintaining a consistent state when a component starts or stops, even accidentally).

Methodology and DevOps

In the past, teams were mainly separated into developers and operators teams.
Now, we talk a lot about DevOps. It does not means the developer and operator roles have disappeared. But they are more and more addressed by the same persons / same team.

The main interest of DevOps approaches is that developers know what operators need (probes, administration procedures, etc). With Roboconf, such elements are parts of the development deliverables (what we call a « Roboconf application »). And this reduce the need of improvisation and long text notice in production environments.

The following schema explains the approach Roboconf promotes.

The application’s development is one project’s part.
It can be hosted in its own source repository and independently of the Roboconf part. The Roboconf deployment is another project, which can be hosted somewhere else. Therefore, Roboconf is not intrusive in the application’s code. It is only about how you will manage your application at runtime.

What are Roboconf’s key points?

Roboconf allows to define a model of the application that one wants to deploy.
It then offers a vision of this model during deployment and at runtime.

The model and the use of Roboconf are designed to be simple.
This project tries to not reinvent the wheel, by using and relying on several well-known technologies (Puppet, AMQP, Bash, REST/JSON web services…).

Roboconf is asynchronous (the application parts can be deployed in any order) and IaaS-agnostic (provides plug-ins for many well-known IaaS, including OpenStack, Amazon WS, Azure, VMWare, as well as an embedded deployment plug-in for on-premise hosts). The asynchronous mechanisms Roboconf supports allow to add and remove dynamically application parts. Other application parts are then updated and/or reconfigured depending on what happened there.

Is Roboconf open source?

Yes, Roboconf is open source.
See the license page for more information.

What are Roboconf pre-requisites?

Roboconf is developed in Java.
You at least need a JDK 1.7 (Oracle JDK or OpenJDK) to run it.

Although the agent is developed in Java, it would be possible to implement your own agent in your own language. This could suit constrained environments (such as connected objects). The only requirement is that this agent can access a messaging server to interact with the Deployment Manager.

The current messaging server we recommend in production is RabbitMQ.
It supports a wide variety of clients, implemented in different languages.

What does Roboconf bring in addition to classics like Bash and SSH?

Roboconf could be replaced by some scripts executed by hand, but the result would be very complicated to maintain.
In fact, Roboconf recipes can use bash scripts. Roboconf only plugs dynamicity behind script invocations.

What is Roboconf’s position with respect to standards?

In terms of concepts, Roboconf is very close from TOSCA.
We should investigate this deeper in the future, since Roboconf may be seen as a deployment orchestrator (but not only).

How about Puppet, Chef or CFEngine?

Puppet, Chef and CFEngine are various deployment solutions. Roboconf does not pretend to be a concurrent, but instead, a complement to these solutions. The real key feature of Roboconf is the asynchronous exchanges to adapt and deploy concurrently Software components. How Roboconf concretely deploys something (once the asynchronous thing worked) is delegated to plug-ins. For the moment, we have a Bash and a Puppet plug-ins. It means Roboconf receipts can be either bash scripts or Puppet modules.

No plug-in has been developed for Chef and CFEngine (yet), but we have this in mind.
This plug-in approach allows to use and mix various solutions in a deployment. It also makes Roboconf an extensible solution that can fit various requirements.

Are there concurrent solutions to Roboconf?

Yes, you can take a look at Cloudify, Right Scale, Scalr and the OW2 project Sirocco.
You may also be interested by JClouds, which is a Java toolkit to manipulate IaaS APIs.