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.

When adding a new feature to Checkly rearchitecting some older piece, I tend to pick Heroku for rolling it out. But not always, because sometimes I pick AWS Lambda . The short story:

• Developer Experience trumps everything.
• AWS Lambda is cheap. Up to a limit though. This impact not only your wallet.
• If you need geographic spread, AWS is lonely at the top.

The setup

Recently, I was doing a brainstorm at a startup here in Berlin on the future of their infrastructure. They were ready to move on from their initial, almost 100% Ec2 + Chef based setup. Everything was on the table. But we crossed out a lot quite quickly:

• Pure, uncut, self hosted Kubernetes — way too much complexity
• Managed Kubernetes in various flavors — still too much complexity
• Zeit — Maybe, but no Docker support
• Elastic Beanstalk — Maybe, bit old but does the job
• Heroku
• Lambda

It became clear a mix of PaaS and FaaS was the way to go. What a surprise! That is exactly what I use for Checkly! But when do you pick which model?

I chopped that question up into the following categories:

• Developer Experience / DX 🤓
• Ops Experience / OX 🐂 (?)
• Cost 💵
• Lock in 🔐

Read the full post linked below for all details