Your application is likely built from multiple components. It’s not unusual for Docker-based application deployments to have double-digit numbers of containers. Operators of such apps typically use orchestrators to manage the application lifecycle. At a minimum, an orderly way to start and stop the requisite containers is a necessity.
Beyond that, an orchestrator can likely help with more advanced topics like restart of failed containers, rolling upgrades, etc.
There are several interesting orchestrators available, including:
- Docker (both docker-compose and docker swarm)
- Mesosphere Marathon
- Amazon EC2 Container Service (ECS)
- Azure Container Service (ACS)
- Google Container Engine (GCE – built on kubernetes)
Is One Orchestrator Enough?
Not necessarily. If your organization believes in DevOps practices, you won’t want to wait until deployment time to introduce the concepts of orchestration. The deployed application should look, as much as possible, like the one a developer is working with on her desktop. But the characteristics of the desktop are fundamentally different from those of the deployment environment. For rapid development, you can’t have multi-node test environments for each contributor. Something lighter-weight is definitely needed. This could easily mean that your application might be deployed on a desktop using docker-compose and deployed in production using kubernetes.
It’s also possible that you need to move your application from one orchestrator to another. Maybe you have a corporate edict that all applications will now be deployed using Mesos/Marathon. Or maybe you’d just like to “kick the tires” on an orchestrator using your own app instead of some contrived “hello world”.
That all sounds good, but creating and maintaining the configuration directives for an orchestrator is not trivial.
Orchestrator configuration for your application can easily take hundreds of lines of text in a prescribed format (e.g., YAML with orchestrator specific keywords). Creating and maintaining a single orchestrator configuration file can be error-prone:
- text file modification is always prone to typos
- file formats can be tricky and error messages are not always helpful
- it can be difficult to test changes (even for syntax validity)
If you want a configuration for more than one orchestrator, the issues mentioned above are compounded by the need to maintain and update multiple orchestrator configuration files. Of course the files will have completely different syntax and rules. So, to make an app change, you need expertise in all the orchestrators. That’s asking quite a lot. Or changes must be made by multiple individuals. That, of course, introduces significant potential for inconsistencies.
What To Do?
Glad you asked!
Your app needs orchestration and you would likely benefit from using more than one orchestrator. But the complexity, and associated cost, of creating multiple orchestration configurations seems daunting. Maintenance of the multiple configurations seems even worse.
Yipee.io is built to address exactly these sorts of issues. You can model your application graphically and not concern yourself with text file syntax. Your application model can be exported directly into orchestrator format for Docker (both Compose and Swarm), Kubernetes, and OpenShift. Future versions of Yipee.io will support additional orchestrator formats based on demand.
Interested in learning more about Yipee.io? Sign up for free to see how Yipee.io can help your team streamline their development process.