OK, ik geef het toe: een serverless pipeline, dat is buzzword-bingo. Eigenlijk wilde ik het over Serverless Jenkins hebben, of Jenkins-X. En daarmee meteen over vernieuwing en verandering rondom pipelines. Want Jenkins bestaat al een tijdje (sinds 2011).
Maar toen kwam de mededeling van Gitlab serverless https://about.gitlab.com/2018/12/11/introducing-gitlab-serverless/. Misschien zit er toch iets in die hele serverless hype! Op de Cloud Native landscape is serverless immers ook al gepromoveerd van plekje op de landscape naar een eigen plaat (https://github.com/cncf/landscape#serverless).
En er is meer, zoals Dispatch van VMWare (https://github.com/vmware/dispatch) en Gestalt van Galactic Fog (http://www.galacticfog.com/product/). En ook Pivotal kwam een paar dagen geleden met de aankondiging van de Pivotal Function Service. (https://pivotal.io/platform/pivotal-function-service).
Deze push naar serverless is vast te relateren aan Knative (https://cloud.google.com/knative/), een serverless framework voor Kubernetes dat door Google deze zomer werd aangekondigd.
Kortom: serverless Jenkins moet maar even wachten: de serverless pipeline is veel interessanter.
Wat is dat precies, serverless?
In een eerder artikel heb ik al iets uiteengezet over serverless (https://www.linkedin.com/pulse/serverless-functions-cloud-niels-goossens/), maar dat is alweer anderhalf jaar geleden, voordat er een Kubernetes-framework was. Amazon liep met haar Lambda service toen behoorlijk voor, maar gaat inmiddels weer een andere kant op: met de (niet echt opgemerkte) introductie van Fargate (https://aws.amazon.com/fargate/) op re:Invent in 2017 lijkt het bedrijf zich meer te richten op containers-as-a-service – en daarmee is het misschien eerder een concurrent voor Kubernetes.
De term serverless is eigenlijk ongelukkig gekozen. Het is namelijk niet zo dat de onderliggende infrastructuur verdwijnt, maar dat de afhankelijkheid ervan minder wordt of verdwijnt. Welke van de twee het is, hangt samen met je perspectief.
Perspectief
Dat perspectief, dat is wel een dingetje. Serverless geeft meer controle aan ontwikkelaars over de infrastructuur waarop de code wordt gedeployed. Nu is dat op zich ook weer niets nieuws: die afhankelijkheid van infrastructuur is ontwikkelaars wel vaker een doorn in het oog, al dan niet terecht.
In een artikel over FarGate (https://medium.freecodecamp.org/amazon-fargate-goodbye-infrastructure-3b66c7e3e413) wordt gesproken over een aantal revoluties, waaronder containerized infrastructure. Vervolgens staat er: “Each and every one of these revolutions has one common trait: they all give more control to software engineers. They do this by encouraging good practices and code sharing with a collaborative workflow, and they lower the need for expensive dedicated servers, System administrators, DevOps, IT support, and so on.”
Of dat echt helemaal zo is, waag ik te betwijfelen. Die “expensive servers” en system administrators zijn er nog wel, maar minder zichtbaar voor de ontwikkelaar. En hoewel foutherstel steeds vaker automatisch kan en gaat, is er altijd achter de schermen nog wel ergens iemand die een schijf moet verwisselen of een jobje moet herstarten. Echt waar, ontwikkelaars.
Je dwaalt af. Wat is dat, serverless?
In de traditionele betekenis van anderhalf jaar geleden waren serverless en een andere, minder gebruikte afkorting synoniem: FaaS, oftewel Function-as-a-Service. Tegenwoordig is er van alles serverless mogelijk, met name rondom data: databases bijvoorbeeld (Amazon Aurora of FaunaDB). Martin Fowler noemt deze nieuwe verschijningsvorm (Mobile) Backend-as-a-Service (https://martinfowler.com/articles/serverless.html). De overeenkomst tussen de twee is het gebrek aan zichtbare infrastructuur.
In de context van dit artikel (en uitgaande van pipelines dus) is FaaS een betere insteek. Amazon geeft een goede omschrijving van het begrip bij de productdetails van Lambda (https://aws.amazon.com/lambda/features/): “Lambda runs your code on high-availability compute infrastructure and performs all the administration of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, code and security patch deployment, and code monitoring and logging. All you need to do is supply the code.” De code wordt getriggerd door events, kan razendsnel op- en afschalen en wordt betaald op basis van daadwerkelijk gebruik.
Kelsey Hightower van Google gaf op KubeCon 2018 een geweldige keynote (https://www.youtube.com/watch?v=oNa3xK2GFKY) waarin hij zijn visie op serverless geeft, aan de hand van een Fortran applicatie!
Hoe werkt een serverless pipeline dan?
In een serverless pipeline zijn build, test en deploy ondergebracht bij de serverless provider. De term cloud-native pipeline komt ook wel voorbij. Een git push is genoeg om code naar een volgende omgeving te brengen. Dat gaat natuurlijk niet helemaal vanzelf: voor Amazon Lambda is bijvoorbeeld LambCI (https://medium.com/@hichaelmart/lambci-4c3e29d6599b) beschikbaar, dat de stappen tussen git push en deploy op Lambda op zich neemt. Voor Jenkins is een plugin beschikbaar waarmee koppeling met Lambda mogelijk is.
Prow en knative
The plot thickens! Ontevredenheid (zoals over security issues, de complexe pluginstructuur en het feit dat Jenkins stateful is) van verschillende Kubernetes-ontwikkelaars leidde in 2016 tot de bouw van Prow (https://github.com/kubernetes/test-infra/tree/master/prow). Hiermee werd het mogelijk om Kubernetes te testen op Kubernetes zelf. Begin 2018 is het Kubernetes team volledig op Prow overgestapt. Ook binnen Red Hat en bij de ontwikkeling van Istio wordt er nu gebruik van gemaakt.
In relatie tot Kubernetes behelst de serverless pipeline het verschuiven van de pipeline naar de binnenkant van het containercluster. En dan komen we toch weer bij Jenkins terecht, maar dit keer de nieuwe versie (Jenkins-X of Serverless Jenkins). Een goede uitleg van hoe de nieuwste versie van de software werkt wordt gegeven door James Rawlings (https://medium.com/@jdrawlings/serverless-jenkins-with-jenkins-x-9134cbfe6870).
De koppeling tussen Jenkins en Kubernetes verloopt via het serverless framework voor Kubernetes (Knative – https://cloud.google.com/knative/) en Prow (the irony!). Met Knative is het mogelijk om bouwblokken van code (getriggerd door events, met ondersteuning van pub/sub) op een Kubernetes platform te draaien, waarbij Istio zorgt voor routing en ingress. In welke cloud dit bouwblok vervolgens draait, is niet meer relevant.
Knative integreert met bestaande pipelines, zoals het al eerdergenoemde Jenkins – maar ook met Concourse van Pivotal (zie bijvoorbeeld https://schd.ws/hosted_files/cfdayna18/9e/CF%20Day%202018%20-%20Using%20Concourse%20with%20Knative.pdf).
Nieuwe tools
En hoe kan het ook anders, er ontstaat weer een nieuwe ecosfeer van tools rondom de serverless (pipeline). Zomaar een paar interessante voorbeelden:
- Kaniko van Google, om Docker images vanuit een container in een cluster te builden (https://github.com/GoogleContainerTools/kaniko)
- Knctl, een commandline tool voor Knative (https://github.com/cppforlife/knctl)
- Firecracker van Amazon, een alternatief voor QEMU (https://firecracker-microvm.github.io/)
- Cilium, API-Aware networking en security voor Kubernets (https://cilium.io)