Successfully reported this slideshow.
Your SlideShare is downloading. ×

Let The Computer Do It

Ad

Let The Computer Do It
Usage Of Declarative APIs
Frank Müller

Ad

•Oldenburg, Germany


•Born 1965


•Working at Kubermatic


•Team Lead Development


•@themue
Introduction Frank Müller

Ad

The World Of APIs Today

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Upcoming SlideShare
Concurrency with Go
Concurrency with Go
Loading in …3
×

Check these out next

1 of 31 Ad
1 of 31 Ad

More Related Content

Let The Computer Do It

  1. 1. Let The Computer Do It Usage Of Declarative APIs Frank Müller
  2. 2. •Oldenburg, Germany •Born 1965 •Working at Kubermatic •Team Lead Development •@themue Introduction Frank Müller
  3. 3. The World Of APIs Today
  4. 4. • Since many years using imperative APIs is normal • Examples are XML-RPC, RESTful APIs, and gRPC • Have proven themselves in simple client/server scenarios • The load of multiple related calls lies with the client • This increases in increasingly distributed and integrative fields of application Most APIs Work Imperative Frank Müller
  5. 5. Imperative Environments Frank Müller Service A Service B Service C Service D Client
  6. 6. • Heat 300 ml of milk to lukewarm ✔ • Dissolve a tablespoon of margarine in it ✔ • Crumble a block of yeast into a tall glass and pour a little warm milk and sugar over it; stir the yeast and let everything warm ✔ • Put 500 gr of flour with the rest of the milk and one egg in a mixing bowl and mix 👀 • Ouch, I don't have any flour anymore 😱 Recipe As An Example Frank Müller
  7. 7. • Complexity grows disproportionately in distributed environments • Error handlings and rollbacks even more • Keeping business logic on client side is hard to synchronize • Implementations and version in web and apps will differ • Runtime for business logic has to be scalable too Complexity in Distributed Environments Frank Müller Complexity In Distributed Environments
  8. 8. The Idea Of Declarative APIs
  9. 9. • Move responsibility from client to a controller • Describe wanted state in a well defined document • Store document in a database • Notify interested controllers about wanted state changes • Let controller perform changes and document them in database • Let controller also perform rollback in error case Don't Control, Just Describe Frank Müller
  10. 10. • Services care for low level tasks • Controllers care for business logic • Controllers continuously reconcile the wanted state with the current state • Two options: ‣ Call the services ‣ Write documents for nested common business logic Responsibilities Frank Müller
  11. 11. apiVersion: api.bettercode.eu/v1 kind: BreadBaking metadata: name: raisin_mare client: frank_mueller spec: count: 1 weight: 1000gr template: name: mare addons: - name: raisins weight: 200gr Example Of Document Frank Müller
  12. 12. Declarative Environments Frank Müller API Server Bread Bakery 
 Controller 1. ... 2. ... 3. ... 4. ... 5. ... Stew 
 Controller BBQ 
 Controller
  13. 13. • Define controller specification • Implement controller specification as data structure • Implement controller processing additions, changes, and deletions of documents • Start controller with subscription to changes of interested documents (can also be others than the own ones) • Listen to notifications and process them Process Frank Müller
  14. 14. Take A Look At Kubernetes
  15. 15. • API server receives documents via HTTP • Documents are stored in high-available database etcd • Scheduler compares wanted with current state and assigns based on resources, restrictions, locations, and dependencies to nodes • Controller Manager manages resources and deployments, monitors differences between current and wanted cluster state and performs changes via API Kubernetes Master Frank Müller
  16. 16. • Kubelet on each node performs installation if needed • Kube-Proxy retrieves container images from internet or own repositories • Container runtime like Docker or containerd run the individual containers Kubernetes Nodes Frank Müller
  17. 17. Kubernetes Architecture Frank Müller Master Controller 
 Manager API Server etcd Client 
 (e.g. kubectl) Scheduler 
 Internet Node kubelet kube-proxy Docker Pod Pod Node kubelet kube-proxy Docker Pod Pod
  18. 18. • Own controllers can run in a cluster • They subscribe to changes of standard objects and/or self- defined objects • Subscriptions may be filtered by meta-data, e.g. to react only on ConfigMaps labeled for own controller • API documents are specified via Custom Resource Definitions (CRD) • Changes are applied as according Custom Resources Controllers Frank Müller
  19. 19. apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: talks.api.bettercode.eu spec: group: api.bettercode.eu versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: Custom Resource Definition Frank Müller type: object properties: title: type: string speaker: type: string time: type: integer scope: Namespaced names: plural: talks singular: talk kind: Talk shortNames: - tlk
  20. 20. • Deployment of a microservice • Configuration of staging, cloud provider, network, and scaling • Configuration of needed backend resources like volumes, databases, caches, queues, logging, monitoring, and search • Applying document (Custom Resource) leads to installation, update, or reconfiguration of microservice • CRD became quite large Example Of Controller Usage Frank Müller
  21. 21. Why Not Commercial APIs Too?
  22. 22. Declarative Business Environment Frank Müller Service A Service B Service C External 
 Service Controller X Controller Y API Server Controller 
 Manager Scheduler
  23. 23. apiVersion: api.bettercode.eu/v1 kind: BreadBaking metadata: name: raisin_mare client: frank_mueller spec: count: 1 weight: 1000gr template: name: mare addons: - name: raisins weight: 200gr Custom Resource For Baking Bread Frank Müller
  24. 24. factory := informers.NewSharedInformerFactory(client, time.Second*30) svcInformer = factory.Core().V1().Services().Informer() svcInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: addServiceHandler, UpdateFunc: updateServiceHandler, DeleteFunc: deleteServiceHandler, }) go cd.svcInformer.Run(wait.NeverStop) Specification As Code Frank Müller type BreadBakingSpec struct { Count int Weight BreadBakingWeightSpec ... } type BreadBaking struct { metav1.TypeMeta `json:",inline"` metav1.ObjectMeta `json:"metadata,omitempty"` Spec BreadBakingSpec `json:"spec"` }
  25. 25. factory := informers.NewSharedInformerFactory(client, time.Second*30) svcInformer = factory.Core().V1().Services().Informer() svcInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: addServiceHandler, UpdateFunc: updateServiceHandler, DeleteFunc: deleteServiceHandler, }) go cd.svcInformer.Run(wait.NeverStop) Registering And Run The Controller Frank Müller func (b *BreadBakery) Register() { factory := informers.NewSharedInformerFactory(b.client, time.Second*30) breadBakingInformer = factory.Query("v1", "BreadBaking").Informer() breadBakingInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: b.addHandler, UpdateFunc: b.updateHandler, DeleteFunc: b.deleteHandler, }) go b.breadBakingInformer.Run(wait.NeverStop) }
  26. 26. factory := informers.NewSharedInformerFactory(client, time.Second*30) svcInformer = factory.Core().V1().Services().Informer() svcInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: addServiceHandler, UpdateFunc: updateServiceHandler, DeleteFunc: deleteServiceHandler, }) go cd.svcInformer.Run(wait.NeverStop) Handle Added Resource Frank Müller func (b *BreadBakery) addHandler(obj interface{}) { bb := obj.(*BreadBaking) // Check client and more. if bb.Client() != b.client { return } ... // Bake bread by calling according services. ... }
  27. 27. • Microservices and external software for individual business domains • Controller for business processes • Controller runtime for call documentation and distribution • Clients and controller send documents to API server • Documents allow to be handled individually • Status is always transparent Overview Frank Müller
  28. 28. • Own runtime similar to Kubernetes has to be build • Only cares for documentation and distribution of business process documents • Runtime alternatively could be Kubernetes itself • Still a less technical wrapper for Kubernetes API would be needed Runtime Frank Müller
  29. 29. Closing
  30. 30. • Complex business process are handled central • Processing is scalable • Versions are possible • Process calls are documented • Still different kind of thinking Closing Frank Müller
  31. 31. Thanks a lot and have a nice evening Image Sources 123RF Pexels iStockphoto Own photos

×