Kubernetes is geen wondermiddel

Bij ZEN Software zien we Docker als een innovatie in configuratiebeheer. Docker lost een aantal frustrerende problemen voor developers op. Docker maakt een softwaresysteem zowel productiever als betrouwbaarder.

Docker doet dat door:

1. Alle dependency-nachtmerries weg te nemen waardoor productieomgevingen afwijken van ontwikkelomgevingen.
2. Verpakken en uitrollen efficiënter te maken, zowel qua omvang als qua tijd.
3. Developers productiever te maken — vooral in de binnenste lus van Edit -> Build -> Debug.

Allemaal uitstekende doelen, en grotendeels ook gehaald.

Maar Docker is in de kern een oplossing voor één machine, gericht op het draaien van één proces en op het voorkomen van alle configuratienachtmerries die daarbij komen kijken.

De 'lol' begint zodra je veel containers moet herstarten of draaien om een hoge belasting aan te kunnen.

Daar komt… Kubernetes, hét wondermiddel voor Docker. Toch? 😉

Kubernetes is de terechte winnaar van de container-orkestratiestrijd (Diego cluster, Docker Swarm). Vandaag is het de industriestandaard voor het orkestreren van Docker-containers, en je kunt het bij alle hyperscale clouds als managed service afnemen.

Moet je daarom standaardiseren op Kubernetes zodra je een container draait? We willen je vragen dat beleid te heroverwegen: Kubernetes heeft veel functies die een hoop flexibiliteit geven, maar die bij kleinere workloads weinig opleveren. Denk aan mesh-netwerken, clusterfailover en ingress-controllers.

• AWS Proton
• AWS App Runner

• Cloud Run
• App Engine

Alle bovenstaande diensten laten DevOps-teams zich richten op het opleveren van software en nemen een hoop loodgieterswerk rond het draaien van containers uit handen. Deze Platform as a Service-diensten (PaaS) kunnen containers aan het publieke internet aanbieden, compleet met een Web Application Firewall (WAF) en automatische certificaten voor HTTPS.