— Mākonis un DevOps
Daudzmākoņu, konteineri, piegāde
Mākonis ir nomaināms preces slānis, ko es saliku — nevis piegādātājs, pie kura esmu piesiets.
Es izvietoju pār GCP, Azure un AWS, ar malas izpildvidēm un pārvaldītām aizmugursistēmām, izvēloties spēcīgāko pakalpojumu katrai lomai un orķestrējot starp piegādātājiem. Konteineri, CI/CD un infrastruktūra kā kods atrodas centrā; Linux darbojas zemāk administratora līmenī.
Es neizvēlos mākoni un nelieču katru problēmu uz to. Es izvēlos spēcīgāko pakalpojumu katrai lomai un orķestrēju starp piegādātājiem.
Daudzmākoņu man nav modes vārds — tā ir apzināta atteikšanās ļaut vienam piegādātājam piederēt arhitektūrai. GCP, Azure un AWS katrs dara dažas lietas labāk nekā pārējie, un malas izpildvides un pārvaldītas aizmugursistēmas aizpilda lomas, ko neviens no trim lielajiem tīri nesedz. Uzdevums ir labi izvēlēties pēc lomas un saglabāt visu pārnesamu.
Tas, kas to padara iespējamu, ir slānis zemāk: konteineri un infrastruktūra kā kods centrā, lai vienreiz definēta slodze varētu mērķēt uz jebkuru piegādātāju, kurā projekts jau dzīvo. Mākonis kļūst par preci, ko varu nomainīt, nevis par atkarību, ap kuru man jāplāno.
Un zem orķestrētāja joprojām ir resursdators. Es darbinu Linux administratora līmenī — kodola pielāgošana, sysctl nostiprināšana, systemd, konteineru izpildvides un tīkls zem pakalpojumiem — jo daļas, ko vairums manto kā noklusējumus, ir daļas, ko es labāk darbinātu apzināti.
galvenie mākoņi, kuros izvietoju — GCP, Azure un AWS — izvēlēti pēc lomas, nevis pēc ieraduma
piegādātāji, no kuriem es ļauju arhitektūrai būt atkarīgai; mākonis ir nomaināms preces slānis
malas izpildvides, ko darbinu tīkla robežā — Cloudflare Workers un Vercel Edge
pārvaldīti datubāzu aizmugursistēmu risinājumi, ko turu gatavus — Supabase, Firebase, PlanetScale, Neon
Viena lietojumprogramma, trīs mākoņi, bez piesaistes.
Slodze, ko turu pārnesamu: konteineri un infrastruktūra kā kods centrā, izvietojami uz piegādātāju, kurā projekts jau darbojas. Katrs piegādātājs ir pievienots lomai, ko tas dara vislabāk, un mala atrodas priekšā tiem visiem.
Pakalpojumu izvēle — spēcīgākais rīks pēc lomas
- Modeļu apmācība un apkalpošana
- Vertex AI (GCP)
- Analītiskie vaicājumi mērogā
- BigQuery (GCP)
- Notikumu kopne / izplatīšana
- Pub/Sub (GCP) · SQS/SNS (AWS)
- Konteineri, kas mērogojas līdz nullei
- Cloud Run (GCP) · Container Apps (Azure)
- Pilns Kubernetes
- GKE · AKS · EKS
- Notikumu vadītas funkcijas
- Cloud Functions · Azure Functions · Lambda
- Objektu glabāšana
- Cloud Storage (GCP) · S3 (AWS)
- Relāciju datubāze
- RDS (AWS) · Neon · PlanetScale
- Malas skaitļošana
- Cloudflare Workers · Vercel Edge
- CDN
- CloudFront (AWS)
Katrai lomai izvēlos piegādātāju, kas to dara vislabāk, un tad orķestrēju starp tiem — mākonim vajadzētu būt precei, ko varu nomainīt, nekad atkarībai, kas pieder produktam.
Kam katrs mākonis patiešām ir paredzēts.
Četras cilnes zemāk nav reitings. Katra ir lomu kopums, ko konkrēts piegādātājs dara labi, un disciplīna ir slodzi saskaņot ar to, kas der, nevis spiest visu uz vienu kontu. GCP datiem un modeļiem, Azure Microsoft ekosistēmā, AWS kā plašais noklusējums un mala un pārvaldītas aizmugursistēmas ātrajam ceļam.
Google Cloud — kur parasti dzīvo darbs ar datiem un modeļiem
GCP ir vieta, kur novietoju slodzes, kas skar datus un modeļus. Vertex AI apmācībai un apkalpošanai, BigQuery analītiskiem vaicājumiem pār lielām tabulām un Pub/Sub kā ziņojumu kopni, kad pakalpojumiem jāizplata notikumi, savstarpēji nezinot viens par otru.
Skaitļošanai izmantoju Cloud Run, kad konteineram jāmērogojas līdz nullei starp pieprasījumiem, Cloud Functions maziem notikumu vadītiem apstrādātājiem un GKE, kad slodzei vajadzīga pilnā Kubernetes virsma. Firestore un Cloud Storage sedz dokumentu stāvokli un objektus.
- Vertex AI modeļu apmācībai un apkalpošanai
- Cloud Run · Cloud Functions · GKE skaitļošanai visā mērogošanas spektrā
- Pub/Sub · BigQuery · Firestore · Cloud Storage ziņojumapmaiņai, analītikai, stāvoklim un objektiem
Azure — kad projekts jau dzīvo Microsoft ekosistēmā
Kad klients jau darbojas ar Microsoft identitāti un rīkiem, cīnīties pret to ir izniekots darbs. Azure Kubernetes Service piedāvā to pašu Kubernetes līgumu, ko izmantoju citur, tāpēc slodze, kas definēta kā konteineri un manifesti, pārvietojas turp ar nelielām izmaiņām.
Azure Functions sedz notikumu vadītu skaitļošanu, Container Apps apstrādā gadījumu ar konteineru, kas mērogojas līdz nullei, un Cognitive Services ir pragmatisks ceļš uz redzi, runu un valodu, kad modeļa būvēšana uz vietas nav projekta jēga.
- AKS pārvaldītam Kubernetes Microsoft ekosistēmā
- Functions un Container Apps notikumu vadītai skaitļošanai un mērogošanai līdz nullei
- Cognitive Services redzei, runai un valodai kā pārvaldītai spējai
AWS — plašais noklusējums ar dziļāko pakalpojumu katalogu
AWS ir plašais noklusējums: kad komanda jau ir tur vai kad konkrēts pārvaldīts pakalpojums ir tīrākā atbilde, es izvietoju tieši tajā. Lambda notikumu vadītām funkcijām, ECS vai EKS konteineriem atkarībā no tā, cik daudz Kubernetes komanda vēlas pārvaldīt.
S3 noturīgai objektu glabāšanai, RDS pārvaldītām relāciju datubāzēm un SQS un SNS rindām un pub/sub. CloudFront atrodas priekšā kā CDN. Tie paši konteineri un infrastruktūra kā kods, kas mērķē uz GCP, mērķē arī uz šo.
- Lambda funkcijām · ECS / EKS konteineriem
- S3 · RDS objektu un relāciju glabāšanai
- SQS · SNS rindām un pub/sub · CloudFront malā
Malas izpildvides un pārvaldītas aizmugursistēmas — ātrais ceļš
Tīkla robežā darbinu Cloudflare Workers un Vercel Edge: kodu, kas izpildās tuvu lietotājam, ar aukstajiem startiem, mērītiem milisekundēs, maršrutēšanai, autentifikācijas pārbaudēm un vieglām transformācijām, pirms pieprasījums vispār sasniedz reģionu.
Produktiem, kam jāvirzās ātri, pārvaldīta aizmugursistēma nopelna savu vietu. Supabase un Firebase nodrošina autentifikāciju, glabāšanu un datubāzi, neuzstādot serverus; PlanetScale un Neon nodrošina pārvaldītu, atzarojamu SQL. Izvēlos tos, kad ātrums līdz strādājošam produktam ir svarīgāks par infrastruktūras īpašumā turēšanu.
- Cloudflare Workers un Vercel Edge robežā
- Supabase un Firebase kā pilnas pārvaldītas aizmugursistēmas
- PlanetScale un Neon pārvaldītam, atzarojamam SQL
Izvietošanas vienība ir tā pati, lai kur tā nolaistos.
Docker · Kubernetes · konteineru drošība
Nemaināms attēls, ko plāno Kubernetes, identisks visiem piegādātājiem.
Viss tiek piegādāts kā konteiners. Slodze tiek iepakota kā nemaināms Docker attēls, uzbūvēts vienu reizi, un tieši šis attēls ir tas, kas darbojas katrā vidē — nav pārbūvējuma, kas varētu klusi atšķirties starp staging un ražošanu.
Kubernetes to plāno tādā pašā veidā neatkarīgi no tā, vai klasteris ir GKE, AKS vai EKS, tāpēc slodze ir pārnesama jau pēc konstrukcijas. Drošība ir iebūvēta attēlā, nevis pievienota vēlāk: minimāli bāzes attēli, lietotāji bez root, tikai lasāmas failu sistēmas, atmestas Linux spējas un skenēšana, pirms kaut kas tiek nosūtīts.
- Viens nemaināms attēls, uzbūvēts vienu reizi, darbināts visur
- Identiski plānots uz GKE, AKS vai EKS
- Minimāli bāzes attēli, bez root, tikai lasāms, atmestas spējas
- Skenēts, pirms tas sasniedz reģistru
Kubernetes slodze — darbības forma
- Orķestrētājs
- Kubernetes — GKE, AKS vai EKS
- Izvietošanas vienība
- Nemaināms konteinera attēls, viens būvējums
- Mērogošana
- Horizontāla podu automātiskā mērogošana pēc metrikām
- Konfigurācija un noslēpumi
- ConfigMaps un Secrets, piesaistīti izpildlaikā
- Ingress
- Pārvaldīts slodzes balansētājs · CDN priekšā
- Izvietošana
- Rolling, canary vai blue-green
- Attēla avots
- Reģistrs ar nemaināmām, parakstītām birkām
Attēls tiek uzbūvēts vienu reizi un veicināts nemainīts.
Konveijers, ko uzskatu par neapspriežamu infrastruktūru. No commit attēls tiek uzbūvēts un testēts vienu reizi, skenēts, nosūtīts ar nemaināmu birku un veicināts cauri katriem vārtiem — lai tas, kas darbojas ražošanā, būtu baits pa baitam tas, kas izgāja testus.
No commit līdz ražošanai — GitHub Actions / GitLab CI
- 01 Commit Push uz repozitoriju ir vienīgais izraisītājs; nekas netiek būvēts ar roku.
- 02 Build + tests GitHub Actions vai GitLab CI uzbūvē konteinera attēlu vienu reizi un palaiž testu komplektu pret to.
- 03 Skenēšana Attēls tiek skenēts uz zināmām ievainojamībām un atkarību koks tiek pārbaudīts, pirms tas drīkst turpināties.
- 04 Push Parakstītais attēls tiek nosūtīts reģistrā ar nemaināmu birku — nekad nepārrakstīts.
- 05 Pielietot IaC Infrastruktūra kā kods plāno izmaiņu, parāda diff un tad to pielieto, lai vide atbilstu repozitorijam.
- 06 Veicināšana Tas pats attēls tiek izvietots aiz canary vai blue-green slēdža, ar iepriekšējo versiju vienas komandas attālumā.
Konveijers, kā fails.
Saīsināta GitHub Actions darbplūsma — uzbūvēt attēlu vienu reizi, to testēt, skenēt, tad nosūtīt ar nemaināmu birku. Tas pats attēls vēlāk tiek veicināts uz katru vidi; nekas netiek pārbūvēts pa straumi lejup.
name: build-and-deploy
on:
push:
branches: [ main ]
jobs:
ship:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
env:
IMAGE: ghcr.io/${{ github.repository }}:${{ github.sha }}
steps:
- uses: actions/checkout@v4
- name: Build image (once)
run: docker build -t "$IMAGE" .
- name: Test
run: docker run --rm "$IMAGE" go test ./...
- name: Scan for vulnerabilities
run: trivy image --exit-code 1 --severity HIGH,CRITICAL "$IMAGE"
- name: Push immutable tag
run: |
echo "${{ secrets.REGISTRY_TOKEN }}" | docker login ghcr.io -u "${{ github.actor }}" --password-stdin
docker push "$IMAGE"Attēls, definēts tā, kā tas tiek piegādāts.
Daudzpakāpju Dockerfile — kompilēt pilnā būvēšanas attēlā, tad kopēt tikai bināro failu minimālā izpildvidē, kas darbojas kā lietotājs bez root. Maza virsma, nekā attēlā, kas programmai nav vajadzīgs.
# --- build stage: full toolchain, thrown away after compile ---
FROM golang:1.22 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -trimpath -ldflags='-s -w' -o /out/app ./cmd/app
# --- runtime stage: minimal, non-root, only the binary ---
FROM gcr.io/distroless/static:nonroot
COPY --from=build /out/app /app
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/app"]Deklarēta, plānota, pārskatīta, pielietota.
Vide dzīvo repozitorijā
Neviens neklikšķina ražošanu esamībā.
Katrs infrastruktūras gabals — tīkli, klasteri, rindas, datubāzes — tiek deklarēts kā kods un dzīvo versiju kontrolē līdzās lietojumprogrammai. Izmaiņa tiek piedāvāta kā diff, plānota kā tukšgaita, pārskatīta kā jebkurš cits kods, tad pielietota.
Jēga ir tajā, ka repozitorijs ir vienīgais patiesības avots. Periodiska atkārtota plānošana noķer jebkuru manuālu novirzi, tāpēc dzīvā vide vienmēr tiek saskaņota atpakaļ ar to, ko kods saka, ka tai vajadzētu būt. Vide kļūst atveidojama, nevis atmiņā saglabātu konsoles klikšķu produkts.
- Tīkli, klasteri, rindas un datubāzes kā kods
- Plāns parāda diff, pirms kaut kas mainās
- Pārskatīts kā kods, nevis noklikšķināts konsolē
- Novirzes pārbaudes patur repozitoriju kā autoritāti
Infrastruktūra kā kods — no deklarēšanas līdz saskaņošanai
- 01 Rakstīt Infrastruktūra tiek deklarēta kā kods — tīkli, klasteri, rindas, datubāzes — versiju kontrolē līdzās lietojumprogrammai.
- 02 Plānot Tukšgaita aprēķina diff starp deklarēto stāvokli un dzīvo stāvokli, tāpēc katra izmaiņa ir redzama, pirms tā notiek.
- 03 Pārskatīt Plāns tiek pārskatīts kā jebkura cita koda izmaiņa; neviens neklikšķina konsolē, lai mutētu ražošanu.
- 04 Pielietot Plāns tiek pielietots; dzīvā vide tagad precīzi atbilst repozitorijam.
- 05 Pārbaudīt novirzi Periodiska atkārtota plānošana noķer manuālas izmaiņas, tāpēc deklarētais stāvoklis paliek vienīgais patiesības avots.
Linux administratora līmenī.
Virs orķestrētāja ir Kubernetes; zem tā joprojām ir Linux resursdators, un tas ir slānis, ko darbinu apzināti, nevis mantoju.
Konteineri nenoņem operētājsistēmu — tie atrodas uz tās. Es darbinu Linux administratora līmenī: kodola pielāgošana slodzei, sysctl nostiprināšana, lai savilktu izpildlaika kodola virsmu, systemd, lai definētu pakalpojumus ar restartēšanas politikām un resursu ierobežojumiem, pašas konteineru izpildvides un tīkls, kas nes katru paketi no malas līdz podam.
Tas ir tas pats instinkts, kas caurvij pārējo manu darbu. Daļas, ko vairums pieņem kā noklusējumus — kodola parametri, ugunsmūra noteikumi, bāzes attēls, no kura konteiners ir uzbūvēts — ir daļas, ko es labāk saprastu un iestatītu apzināti, jo tieši no turienes klusi nāk uzticamība un drošība.
Kodola pielāgošana
Kodola parametru pielāgošana slodzei — failu deskriptoru ierobežojumi, tīkla buferi, plānotāja uzvedība — nevis pieņemot distribūcijas noklusējumus.
sysctl nostiprināšana
Izpildlaika kodola virsmas savilkšana caur sysctl: tīkla steka iestatījumi, adrešu telpas aizsardzība un atspējošana tā, ko serverim nav iemesla atklāt.
systemd
Pakalpojumi, definēti kā systemd vienības ar restartēšanas politikām, resursu ierobežojumiem un atkarību secību, lai resursdators uzvestos paredzami starp pārstartēšanām.
Konteineru izpildvides
Darbs izpildvides līmenī — Docker un OCI slānis zem tā — ieskaitot namespaces, cgroups un attēla iekšieni, ne tikai augsta līmeņa komandas.
Tīklošana
Tīkls zem pakalpojumiem: maršrutēšana, ugunsmūra noteikumi, DNS, TLS terminācija un ceļš, ko pakete iet no malas līdz podam.
Konteineru drošība
Minimāli bāzes attēli, lietotāji bez root, tikai lasāmas failu sistēmas, atmestas spējas un attēlu skenēšana — samazinot to, ko kompromitēts konteiners var sasniegt.
Sistēma, kurā nevar ieskatīties, ir tāda, kuru nevar darbināt.
Tiklīdz slodze ir izkliedēta starp funkcijām, konteineriem un rindām vairāk nekā vienā piegādātājā, to nevar darbināt pēc intuīcijas. Novērojamība ir daļa, kas izkliedētu sistēmu pārvērš atpakaļ par kaut ko, par ko var spriest — metrikas tendencēm, žurnāli detaļām, pēdas ceļam, ko pieprasījums nogāja, un brīdinājumi, kas paziņo par simptomiem, ko lietotājs patiešām sajustu.
Es uzskatu novērojamības steku par būvējuma daļu, nevis par kaut ko, kas pieskrūvēts pēc pirmā incidenta. Četras cilnes zemāk ir slāņi, ko instrumentēju, un secība ir svarīga: metrika norāda uz problēmu, pēda to sašaurina līdz lēcienam, un žurnāli izskaidro, kas notika tieši šajā pieprasījumā.
Skaitļi laikā, lai tendences būtu redzamas, pirms tās kļūst par incidentiem
Metrikas ir lētais, vienmēr ieslēgtais signāls: pieprasījumu ātrumi, kļūdu ātrumi, latentuma procentiles, resursu piesātinājums. Tās ir tas, ko nolasa automātiskais mērogotājs un kas iedarbina brīdinājumu, jo tās ir skaitliskas un nepārtrauktas.
Es instrumentēju lietas, kas atbilst lietotāja pieredzei — latentumu, ko pieprasījums patiešām piedzīvo, kļūdu ātrumu, ko klients patiešām sastop — nevis tikai resursdatora līmeņa skaitītājus, kas izskatās veseli, kamēr produkts cieš neveiksmi.
- Pieprasījumu ātrums, kļūdu ātrums, latentuma procentiles
- Resursu piesātinājums, kas virza automātisko mērogošanu
- Signāli, kas saistīti ar lietotāja pieredzi, nevis tikai resursdatora skaitītāji
Detaļa, pēc kuras meklē, tiklīdz metrika ir parādījusi, kur skatīties
Žurnāli ir strukturēti un centralizēti, lai vienu pieprasījumu varētu izsekot cauri pakalpojumiem, kurus tas skāra. Metrika man saka, ka kaut kas nav kārtībā; žurnāli man saka — kas, kurā pieprasījumā, ar kādu ievadi.
Strukturēti lauki nozīmē vairāk nekā brīvais teksts — žurnāls, ko var vaicāt un agregēt, ir daudz vērtīgāks nekā tāds, ko incidenta laikā var lasīt tikai rindiņu pa rindiņai.
- Strukturēti, vaicājami, centralizēti
- Viens pieprasījums izsekojams cauri pakalpojumiem
- Vaicājami lauki, nevis brīvā teksta rindas
Pieprasījuma forma, kad tas šķērso pakalpojumu robežas
Izkliedētā izsekošana seko vienam pieprasījumam cauri katram lēcienam — vārtejai, pakalpojumam, datubāzei, rindai — un parāda, kur laiks patiešām aizgāja. Sistēmā, kas izkliedēta starp funkcijām, konteineriem un rindām, šī ir vienīgā godīgā atbilde uz kur ir lēni.
Pēda pārvērš neskaidru šķiet lēni konkrētā spanā, kas pieder lielākajai daļai latentuma, kas ir atšķirība starp minēšanu un labošanu.
- Viens pieprasījums izsekots cauri katram lēcienam
- Latentums attiecināts uz spanu, kas to pieder
- Godīgā atbilde, kur laiks aizgāja
Paziņojumi, kas saistīti ar simptomiem, ko lietotājs sajustu, nevis ar troksni
Brīdinājumi iedarbojas uz simptomiem — paaugstinātu kļūdu ātrumu, latentumu pāri slieksnim, piesātinošu resursu — nevis uz katru pārejošu mirkļošanu. Brīdinājumam, kas kādu modina pulksten 3 naktī, jāatbilst kaut kam, ko lietotājs patiešām pamanītu.
Mērķis ir neliels skaits augsta signāla brīdinājumu. Pārāk daudz zema signāla paziņojumu apmāca cilvēkus tos ignorēt, kas ir sliktāk nekā nebūt nevienam.
- Balstīti uz simptomiem, saistīti ar lietotājam redzamu ietekmi
- Augsts signāls, nevis liels apjoms
- Sliekšņi izvēlēti tā, lai paziņojums kaut ko nozīmētu
No kodola līdz mākonim, viens steks.
Resursdators, konteiners, konveijers, mākonis — lasīts no apakšas uz augšu, darbs ir viens nepārtraukts steks, nevis četras atsevišķas rūpes.
Katrs slānis balstās uz to, kas zem tā. Nostiprināts Linux resursdators nes konteineru izpildvidi; nemaināms attēls darbojas uz Kubernetes; CI/CD konveijers un infrastruktūra kā kods padara visu atveidojamu; un daudzmākoņu izvietošana to izplata, nepiesaistoties nevienam vienam piegādātājam.
Atdalītas, tās izskatās kā atsevišķas specialitātes. Darbinātas kopā, tās ir viena disciplīna: apzināta katrā slānī, pārnesama starp piegādātājiem un atveidojama no repozitorija, nevis no atmiņas.
- Resursdators Linux administratora līmenī Kodola pielāgošana, sysctl nostiprināšana, systemd vienības, konteineru izpildvides un tīkls zemāk — slānis, ko vairums manto, darbināts apzināti.
- Konteiners Docker un Kubernetes Slodzes iepakotas kā nemaināmi konteineru attēli un darbinātas uz Kubernetes — GKE, AKS vai EKS — lai izvietošanas vienība būtu tā pati, lai kur tā nolaistos.
- Konveijers CI/CD un infrastruktūra kā kods GitHub Actions un GitLab CI būvē un veicina attēlu; infrastruktūra, deklarēta kā kods, padara visu vidi atveidojamu, nevis būvētu ar roku.
- Mākonis Daudzmākoņu, pēc lomas GCP, Azure un AWS — plus malas izpildvides un pārvaldītas aizmugursistēmas — izvēlēti pēc lomas un orķestrēti kopā, bez tā, ka kāds viens piegādātājs pieder arhitektūrai.
Principi zem platformas.
Piegādātāji un rīki mainās līdz ar projektu; principi ne. Šie ir noteikumi, ko piemēroju neatkarīgi no tā, vai mērķis ir GCP, Azure, AWS, mala vai pārvaldīta aizmugursistēma — daļa, kas padara platformu atveidojamu, nevis nejaušu.
Izvēlēties spēcīgāko pakalpojumu pēc lomas
Katrai lomai — modeļu apkalpošanai, notikumu kopnei, datubāzei, malai — izvēlos piegādātāju, kas to dara vislabāk, un tad orķestrēju starp tiem. Rezultāts ir sistēma, salikta no pareizajām daļām, nevis ērtajām.
Nekad neatkarīgi no viena mākoņa
Konteineri un infrastruktūra kā kods atrodas centrā, lai tā pati slodze varētu mērķēt uz GCP, Azure vai AWS. Mākonis ir prece, ko varu nomainīt, nevis atkarība, kas pieder produktam.
Uzbūvēt attēlu vienu reizi, veicināt to nemainītu
Attēls tiek uzbūvēts vienu reizi un pārvietots cauri katriem vārtiem līdz ražošanai baits pa baitam. Tas, kas darbojas ražošanā, ir tieši tas, kas izgāja testus, nevis pārbūvējums, kas varētu atšķirties.
Deklarēt infrastruktūru, nekad neklikšķināt to
Tīkli, klasteri, rindas un datubāzes tiek deklarēti kā kods, plānoti, pārskatīti un pielietoti. Neviens nemutē ražošanu konsolē, tāpēc repozitorijs paliek vienīgais patiesības avots.
Nostiprināt resursdatoru zemāk
Darbināt Linux administratora līmenī — kodola pielāgošana, sysctl nostiprināšana, systemd, konteineru izpildvides, tīklošana — nozīmē, ka slānis zem orķestrētāja ir apzināts, nevis atstāts noklusējumos.
Padarīt sistēmu novērojamu
Metrikas, žurnāli un pēdas ir daļa no būvējuma, nevis pieskrūvētas pēc incidenta. Sistēma, kurā nevar ieskatīties, ir sistēma, kuru nevar darbināt.
Izvēlēties spēcīgāko pakalpojumu pēc lomas, turēt slodzi pārnesamu ar konteineriem un kodu, uzbūvēt attēlu vienu reizi un nostiprināt resursdatoru zemāk — viss pārējais ir detaļa.
Open to the right work
Ja jums vajadzīga platforma, kas darbojas pār mākoņiem, nepiederot nevienam no tiem, tas ir darbs, ko es daru.
If you are holding a problem that doesn't fit inside one field, that is the conversation I want.