Cloud Native tankegangen
Hvad er Cloud Native? Hvorfor er det relevant og hvordan er det anderledes?
Hvad er Cloud Native?
Cloud Native er arkitekturer og designbeslutninger, der er født med cloud-tankegange i baghovedet. I stedet for at tænke i en traditionel on-premises infrastruktur - “vi skal have en server og en firewall”, så handler cloud native om at bruge de moderne muligheder for cloud til at løse den samme problemstilling på en ny, billigere, hurtigere og mere effektiv måde.
Infrastruktur på en ny måde
Der er stadig en server et eller andet sted i stakken. Men det er ret sjældent noget man tænker på i et cloud native setup. I stedet tænker vi på de logiske komponenter, vi skal bruge. Storage, en database og et website. Hvis det er et statisk website, så trækker vi måske på én type komponenter - hvis det er dynamisk bruger vi noget andet.
Vores defition af infrastruktur bliver måske
- et statisk website
- et API, der leverer dynamisk indhold
- en database, der gemmer informationer om brugere og produkter
Hver service kan i et cloud native setup leveres som en Platform-as-a-Service ydelse (PaaS). Typisk til ingen penge - eller i hvert fald næsten ingen penge. Og det hele kan være klar på få minutter, når vi ved, hvad vi vil have.
DevOps gennem Infrastructure as Code, pipelines og automatisering
Når man arbejder med Cloud Native som sin gennemgående filosofi, handler det i høj grad om at definere og automatisere de underliggende tekniske detaljer på en måde, så det er gjort én gang for alle og kræver meget begrænset vedligehold. Udviklere og DevOps engineers med Cloud Native kompetencer har sjældent brug for hjælp udefra for at kunne levere et end-to-end resultat i drift. Et resultat af cloud native er derfor ofte at behovet for infrastruktur-specialister bliver væsentligt reduceret.
En DevOps-specialist kan hjælpe et udviklingsteam med at definere de nødvendige komponenter som Infrastructure as Code (IaC), klargøre CI/CD pipelines og automatisere processerne. Udviklere med DevOps tankegang kan også sagtens udføre mange opgaver uden hjælp, når først de grundlæggende strukturer er sat op. Dermed bliver de enkelte teams i stand til at levere de fleste ændringer uden at koordinere og afvente hjælp udefra.