Docker Compose vs Apache Maven: What are the differences?
Docker Compose: Define and run multi-container applications with Docker. With Compose, you define a multi-container application in a single file, then spin your application up in a single command which does everything that needs to be done to get it running; Apache Maven: Apache build manager for Java projects. Maven allows a project to build using its project object model (POM) and a set of plugins that are shared by all projects using Maven, providing a uniform build system. Once you familiarize yourself with how one Maven project builds you automatically know how all Maven projects build saving you immense amounts of time when trying to navigate many projects.
Docker Compose belongs to "Container Tools" category of the tech stack, while Apache Maven can be primarily classified under "Java Build Tools".
"Multi-container descriptor", "Fast development environment setup" and "Easy linking of containers" are the key factors why developers consider Docker Compose; whereas "Dependency management", "Necessary evil" and "I’d rather code my app, not my build" are the primary reasons why Apache Maven is favored.
Docker Compose and Apache Maven are both open source tools. Docker Compose with 16.4K GitHub stars and 2.52K forks on GitHub appears to be more popular than Apache Maven with 1.71K GitHub stars and 1.26K GitHub forks.
CircleCI, Docker, and Airbrake are some of the popular companies that use Docker Compose, whereas Apache Maven is used by Intuit, Yammer, and Zillow. Docker Compose has a broader approval, being mentioned in 787 company stacks & 608 developers stacks; compared to Apache Maven, which is listed in 301 company stacks and 138 developer stacks.
What is Docker Compose?
What is Apache Maven?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Heroku was a decent choice to start a business, but at some point our platform was too big, too complex & too heterogenic, so Heroku started to be a constraint, not a benefit. First, we've started containerizing our apps with Docker to eliminate "works in my machine" syndrome & uniformize the environment setup. The first orchestration was composed with Docker Compose , but at some point it made sense to move it to Kubernetes. Fortunately, we've made a very good technical decision when starting our work with containers - all the container configuration & provisions HAD (since the beginning) to be done in code (Infrastructure as Code) - we've used Terraform & Ansible for that (correspondingly). This general trend of containerisation was accompanied by another, parallel & equally big project: migrating environments from Heroku to AWS: using Amazon EC2 , Amazon EKS, Amazon S3 & Amazon RDS.
We use Apache Maven because it is a standard. Gradle is very good alternative, but Gradle doesn't provide any advantage for our project. Gradle is slower (without running daemon), need more resources and a learning curve is quite big. Our project can not use a great flexibility of Gradle. On the other hand, Maven is well-know tool integrated in many IDEs, Dockers and so on.
Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.
We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.
Java build tool for internal processes: Jezebel daemon (in-mem classifiers/recommendations/feature analysis), Connemara (batch resume stream processor) and opes (opening elasticsearch plugin, simple process that listens for new incoming resumes and triggers analysis by Jezebel via a tcp json command).
Since our production deployment makes use of the Convox platform, we use this to describe the containers to be deployed via Convox to AWS ECS.
We also use this for our local dev environment (previously used vagrant with chef).
All Java-Projects are compiled using Maven. We prefer it over Ant and Gradle as it combines lightweightness with feature-richness and offers basically all we can imagine from a software project-management tool and more.
Aside from our Minecraft-infrastructure, we compose it with ... Docker Compose! (kinda obious, eh .. ?) This includes for example the web-services, aswell as the monitoring and mail-infrastructure.
Docker Compose is just another part of my "infrastructure as code" initiative and allows me to build isolated pieces of systems with their own volumes and networks.
Our application will consist of several containers each communicating with each other. Using docker-compose, we can orchestrate several containers at once.
The core tech in ACS (Azure Container Services) we spin up a Kubernetes cluster and deploy our app into staging and production environments here.
Package management and build automation for the back-end, plus integration of front-end build automation using Gulp/Bower/NPM.
Necessary for Google j2objc