Our whole DevOps stack consists of the following tools:

• @{GitHub}|tool:27| (incl. @{GitHub Pages}|tool:683|/@{Markdown}|tool:1147| for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
• Respectively @{Git}|tool:1046| as revision control system
• @{SourceTree}|tool:1599| as @{Git}|tool:1046| GUI
• @{Visual Studio Code}|tool:4202| as IDE
• @{CircleCI}|tool:190| for continuous integration (automatize development process)
• @{Prettier}|tool:7035| / @{TSLint}|tool:5561| / @{ESLint}|tool:3337| as code linter
• @{SonarQube}|tool:2638| as quality gate
• @{Docker}|tool:586| as container management (incl. @{Docker Compose}|tool:3136| for multi-container application management)
• @{VirtualBox}|tool:774| for operating system simulation tests
• @{Kubernetes}|tool:1885| as cluster management for docker containers
• @{Heroku}|tool:133| for deploying in test environments
• @{nginx}|tool:1052| as web server (preferably used as facade server in production environment)
• @{SSLMate}|tool:2752| (using @{OpenSSL}|tool:3091|) for certificate management
• @{Amazon EC2}|tool:18| (incl. @{Amazon S3}|tool:25|) for deploying in stage (production-like) and production environments
• @{PostgreSQL}|tool:1028| as preferred database system
• @{Redis}|tool:1031| as preferred in-memory database/store (great for caching)

The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

• Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
• Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
• Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
• Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
• Scalability: All-in-one framework for distributed systems.
• Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.

We began our hosting journey, as many do, on Heroku because they make it easy to deploy your application and automate some of the routine tasks associated with deployments, etc. However, as our team grew and our product matured, our needs have outgrown Heroku. I will dive into the history and reasons for this in a future blog post.

We decided to migrate our infrastructure to Kubernetes running on Amazon EKS. Although Google Kubernetes Engine has a slightly more mature Kubernetes offering and is more user-friendly; we decided to go with EKS because we already using other AWS services (including a previous migration from Heroku Postgres to AWS RDS). We are still in the process of moving our main website workloads to EKS, however we have successfully migrate all our staging and testing PR apps to run in a staging cluster. We developed a Slack chatops application (also running in the cluster) which automates all the common tasks of spinning up and managing a production-like cluster for a pull request. This allows our engineering team to iterate quickly and safely test code in a full production environment. Helm plays a central role when deploying our staging apps into the cluster. We use CircleCI to build docker containers for each PR push, which are then published to Amazon EC2 Container Service (ECR). An upgrade-operator process watches the ECR repository for new containers and then uses Helm to rollout updates to the staging environments. All this happens automatically and makes it really easy for developers to get code onto servers quickly. The immutable and isolated nature of our staging environments means that we can do anything we want in that environment and quickly re-create or restore the environment to start over.

The next step in our journey is to migrate our production workloads to an EKS cluster and build out the CD workflows to get our containers promoted to that cluster after our QA testing is complete in our staging environments.

If you want to integrate your cluster and control end to end your pipeline with AWS tools like ECR and Code Pipeline your best option is ECS using a EC2 instance. There are pros and cons but it's easier to integrate using cloud formation templates and visual UI for approvals, etc. ECS is free, you need to pay only for the EC2 instance but unfortunately, it is not standard then you cannot use standard tools to see and manage your Kubernetes.
EKS in the other hand uses standard Kubernates definitions but you need to pay for the service and also for the EC2 instance(s) you have in your cluster.