I den förra delen av denna spännande följetång om en tekniskstack framtagen för att kunna utvecklas utan molnplattformar eller andra molntjänster tittade vi på utvecklingsmiljö och CICD-verktyg. I denna andra och mellersta del ska vi gå vidare till miljön där vår produkt ska driftsättas och köras.
Driftmiljö
Driftsmiljön för vår hypotetiska teknikstack skiljer sig på de flesta områdena inte särskilt mycket från den sortens stack utvecklare är vana vid att jobba med i techjättarnas molntjänster. I ett par fall har jag dock valt att ersätta tjänster som tidigare varit helt öppna men sedermera bytt till mer restriktiva licenser. I andra fall har jag valt projekt som är kompatibla med proprietära produkters APIer.
Meddelandeköer
Först ut i listan är meddelandeköer. Här finns det en uppsjö av olika projekt att välja mellan och alla de som jag valt ut här är möjliga att självhosta, så det är snarare upp till dig som utformar din stack att välja meddelandekö utifrån din domäns specifika behov. Mitt defaultval här brukar vara Kafka, men även RabbitMQ, ActiveMQ och ZeroMQ är bra val.
Databaser
Nästa i listan är databaser. Här har jag valt att bara ta med ett val i form av Postgresql. Anledningen till det är att Postgresql med tiden kommit att sticka ut bland relationsdatabaser som en riktig schweiziskt armekniv som kan hantera alla möjliga uppgifter väl och dessutom är byggd helt i öppen källkod. Den enda tydliga nackdelen hos Postgresql är att den inte är byggd för horisontell skalning och replikering, men där finns det å andra sidan andra bra öppna alternativ.
NoSQL-databaser
Om du har behov av en kolumn-orienterad databas som är byggd för replikering och horisontell skalning så är både Cassandra och ScyllaDB bra val. Cassandra har länge varit populär för sin förmåga att hantera stora datamängder och trafikvolymer, och har blivit så pass trendsättande att ScyllaDB valde att bygga in stöd för samma frågespråk (CQL) och filformat (SSTable).
Block-storage
Nästa listpunkt är object storage, ett koncept som populariserades av Amazons S3 tjänst. Object storage innebär i korthet lagring av versionerade filer indexerade med unika nycklar och organiserade i mapp-struktursliknande buckets. Här är mitt förstahandsval Minio, ett projekt som kombinerar ett S3-kompatibelt API med en egenutvecklad lagringsarkitektur. Detta gör det lätt att återanvända existerande klienter och bibliotek som utvecklats för S3 med Minio.
Document-storage
Om ditt projekt behöver lagra JSON-data på ett sökbart sätt och med möjlighet till självhostning så är min rekommendation att använda CouchDB. Denna dokumentdatabas från Apache erbjuder ACID på dokumentnivå, inkrementell MapReduce, inkrementell replikering, eventual consistency och multi-master replikering. Att den dessutom är licensierad under Apache License 2.0 gör den till ett betydligt pålitligare alternativ än MongoDB, som diskvalifierats från denna lista på grund av sin licens.
Secrets management
För att hantera hemlig konfiguration som lösenord, nycklar och certifikat är min rekommendation OpenBao. Detta projekt blev till som en fork av det betydligt mer kända Vault när det bytte till en restriktiv licens och har sedan dess utvecklats i sin egen riktning samtidigt som man bibehållt kompatibilitet med Vaults API vid forkpunkten. Projektet drivs av Linux Foundation och är utformat för både självhostning och molntjänster.
Infrastructure as Code (IaC)
När det kommer till IaC eller Infrastructure as Code är min rekommendation OpenTofu, vilket (likt OpenBao) är en fork av Terraform som blev till då den senare bytte till en restriktiv licens. OpenTofu används för att programmatiskt definiera hur mjukvaruinfrastruktur ska byggas, konfigureras och kopplas ihop och används ofta tillsammans med Kubernetes eller olika molntjänster genom plugins. Projektet drivs även det av Linux Foundation.
Nätverk
För programmatisk hantering av säkra nätverk rekommenderar jag Istio, ett verktyg för att skapa service meshes byggt ovanpå Envoy-proxyn.
Monitorering
När det kommer till monitorering finns det redan idag många bra alternativ med möjlighet till självhostning: Grafana för visualisering och larm, Loki för logghantering, Prometheus för metrikinsamling och Open Telemetry (OTEL)för telemetri och tracing. Alla dessa produkter har många pluginer och integrationspunkter som gör att de kan passas in i många olika miljöer.
Analytics
För beteende- och trafikanalys av webbapplikationer är mitt förstahandsval Fathom, ett lättviktigt alternativ till Google Analytics som fokuserar enbart på analys av hur användare interagerar med din webbapplikation och inte på att spåra och kategorisera användarnas levnadsvanor och bakgrunder. Detta verktyg går, till skillnad från GA, att helt och hållet självhosta och du har själv kontroll över var och hur det insamlade datat lagras.
PaaS
Sist men inte minst i listan kommer valet av PAAS eller platform-as-a-service. För en stack som både ska gå att självhosta eller driftsätta i en molntjänst så begränsas alternativen kraftigt och därför finns här bara två kandidater: Kubernetes eller OpenShift. Av dessa två är Kubernetes det mer öppna alternativet, och ger mer frihet och konfigurationsmöjligheter samtidigt som det kräver mer jobb att sätta upp första gången. OpenShift från Red Hat bygger delvis på Kubernetes men är mer åsiktsfullt och har vissa beroenden på produkter från just Red Hat, men kan fortfarande självhostas. Här krävs en noggrann analys av fördelar och nackdelar mellan de två alternativen för att göra ett bra val.
I nästa del av denna vintersaga i tre delar kommer vi att titta på verktyg för produktivitet och kommunikation.
