I use Portainer because it does so good with the UI that we don't have to train our whole team to be Linux bash heros. It provides deep details without leaving details behind you would think could only come from the command line. Portainer is a professional tool that gives us enterprise features we appreciate. ( Will be blogging about this in January. )

I use Portainer because we were all in on Docker Cloud, which gave 2 months notice that they were sunsetting their services. We knew we wanted to migrate to Docker Community Edition, but its lack of UI had us worried until we came across Portainer. Portainer had just release their agent feature, which was a critical feature for us. To date, Portainer has been an outstanding product and we couldn't be happier with it.

I use Portainer as a way to disseminate micro-service architectures in my institute and drive innovation forward. Portainer enables an easy to deploy, easy to build platform which decreases the learning curve for deploying containers and micro-services. I am particular interested in offering Portainer as a product in the Research space (i work in one of the bigguest Australian Universities).

I use Portainer because it's a great tool to avoid CLI in docker environment, all management in only one screen, awesome. So we can use our time in more important stuff like providing more and better services to our teams and endusers. The Builtin LDAP support and the internal teams helps a lot in diving Dev's in the Devops world. Long live to Portainer. (I work as DevOps in a Big Brazilian Public University )

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.

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.