Everything old is new: today's infrastructure as yesterday's Internet

Everything old is new: today's infrastructure as yesterday's Internet

In the age of cloud computing, what was once boring infrastructure has become incredibly exciting. From containers to service discovery to cluster schedulers, both industry and academia have been innovating at an alarming pace. With so many systems rapidly evolving in a domain fraught with trade-offs, it has become difficult to see the proverbial forest for the trees. In this talk we will try to see how we can evaluate this new landscape of systems by exploring classic networking papers and seeing what the design principles of yesterday's Internet have to say about the design decisions of today's infrastructure.

Fb8e986500c5059b2a6c0b2184bb0faf?s=128

Adelbert Chang

November 14, 2019
Tweet

Transcript

  1. 3.
  2. 4.

    https://kubernetes.io/ “Kubernetes (K8s) is an open-source system for automating deployment,

    scaling, and management of containerized applications.” https://www.nomadproject.io/ “Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications.”
  3. 5.

    https://kubernetes.io/ “Kubernetes (K8s) is an open-source system for automating deployment,

    scaling, and management of containerized applications.” https://www.nomadproject.io/ “Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications.” https://mesos.apache.org/ “Mesos abstracts CPU, memory, storage, and other compute resources away from machines, enabling fault-tolerant and elastic distributed systems to easily be built and run effectively.”
  4. 6.

    https://linkerd.io/ “Linkerd is an ultralight service mesh for Kubernetes. It

    gives you observability, reliability, and security without requiring any code changes.”
  5. 7.

    https://linkerd.io/ “Linkerd is an ultralight service mesh for Kubernetes. It

    gives you observability, reliability, and security without requiring any code changes.” https://istio.io/docs/concepts/what-is-istio/ “Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, with few or no code changes in service code.”
  6. 8.

    https://getnelson.io/ “Nelson fuses years of field experience with rigorous formal

    methods to provide a continuous delivery system that "just works". Users are empowered to focus on building their products, whilst operators gain guarantees that applications are meeting the organizational best practices.”
  7. 9.

    https://getnelson.io/ “Nelson fuses years of field experience with rigorous formal

    methods to provide a continuous delivery system that "just works". Users are empowered to focus on building their products, whilst operators gain guarantees that applications are meeting the organizational best practices.” https://www.spinnaker.io/ “Spinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence. Created at Netflix, it has been battle-tested in production by hundreds of teams over millions of deployments. It combines a powerful and flexible pipeline management system with integrations to the major cloud providers.”
  8. 12.
  9. 15.

    B. Lampson, Hints for Computer System Design “These are not

    novel (with a few exceptions), foolproof recipes, laws of system design or operation, precisely formulated, consistent, always appropriate, approved by all the leading experts, or guaranteed to work.”
  10. 17.

    “Keep it simple. Do one thing at a time, and

    do it well.” “...service must have a fairly predictable cost, and the interface must not promise more than the implementer knows how to deliver. Especially, it should not promise features needed by only a few clients, unless the implementer knows how to provide them without penalizing others.”
  11. 18.

    “Keep it simple. Do one thing at a time, and

    do it well.” “...service must have a fairly predictable cost, and the interface must not promise more than the implementer knows how to deliver. Especially, it should not promise features needed by only a few clients, unless the implementer knows how to provide them without penalizing others.” “Make it fast, rather than general or powerful...The trouble with slow, powerful operations is that the client who doesn’t want the power pays more for the basic function.”
  12. 19.
  13. 20.
  14. 21.

    “In a system...it becomes apparent that there is a list

    of functions each of which might be implemented in any of several ways: by the communication subsystem, by its client, as a joint venture, or perhaps redundantly, each doing its own version.”
  15. 22.

    “In a system...it becomes apparent that there is a list

    of functions each of which might be implemented in any of several ways: by the communication subsystem, by its client, as a joint venture, or perhaps redundantly, each doing its own version.” “The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system... Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.”
  16. 23.

    “In a system...it becomes apparent that there is a list

    of functions each of which might be implemented in any of several ways: by the communication subsystem, by its client, as a joint venture, or perhaps redundantly, each doing its own version.” “The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system... Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.”
  17. 27.

    “Design for variation in outcome...Do not design so as to

    dictate the outcome. Rigid designs will be broken; designs that permit variation will flex under pressure and survive.”
  18. 28.

    “Design for variation in outcome...Do not design so as to

    dictate the outcome. Rigid designs will be broken; designs that permit variation will flex under pressure and survive.” “Modularize the design along tussle boundaries, so that one tussle does not spill over and distort unrelated issues.”
  19. 29.

    “Design for variation in outcome...Do not design so as to

    dictate the outcome. Rigid designs will be broken; designs that permit variation will flex under pressure and survive.” “Modularize the design along tussle boundaries, so that one tussle does not spill over and distort unrelated issues.” “Design for choice, to permit the different players to express their preferences.”
  20. 30.
  21. 31.

    F 1.2.3 G 1.0.9 C 2.3.6 A 1.1.5 E 4.12.7

    D 2.1.8 B 5.4.5 D 2.2.0 Nelson
  22. 32.

    F 1.2.3 G 1.0.9 C 2.3.6 A 1.1.5 E 4.12.7

    D 2.1.8 B 5.4.5 D 2.2.0 Nelson
  23. 33.

    F 1.2.3 G 1.0.9 C 2.3.6 A 1.1.5 E 4.12.7

    D 2.1.8 B 5.4.5 D 2.2.0 E 4.12.8 Nelson
  24. 34.

    F 1.2.3 G 1.0.9 C 2.3.6 A 1.1.5 D 2.1.8

    B 5.4.5 D 2.2.0 E 4.12.8 Nelson
  25. 35.

    F 1.2.3 G 1.0.9 C 2.3.6 A 1.1.5 D 2.1.8

    B 5.4.5 D 2.2.0 E 4.12.8 B 5.4.6 Nelson
  26. 36.

    F 1.2.3 G 1.0.9 C 2.3.6 A 1.1.5 D 2.1.8

    B 5.4.5 D 2.2.0 E 4.12.8 B 5.4.6 A 1.1.6 Nelson
  27. 37.

    F 1.2.3 G 1.0.9 C 2.3.6 D 2.1.8 B 5.4.5

    D 2.2.0 E 4.12.8 B 5.4.6 A 1.1.6 Nelson
  28. 38.

    F 1.2.3 G 1.0.9 C 2.3.6 D 2.1.8 D 2.2.0

    E 4.12.8 B 5.4.6 A 1.1.6 Nelson
  29. 39.
  30. 40.

    Nelson runBackgroundJob("auditor", cfg.auditor.process(cfg.storage)(cfg.pools.defaultExecutor)) runBackgroundJob("pipeline_processor", Stream.eval(Pipeline.task(cfg)(Pipeline.sinks.runAction(cfg)))) runBackgroundJob("workflow_logger", cfg.workflowLogger.process) runBackgroundJob("routing_cron", routing.cron.consulRefresh(cfg) to

    Http4sConsul.consulSink) runBackgroundJob("cleanup_pipeline", cleanup.CleanupCron.pipeline(cfg)(cfg.pools.defaultExecutor)) runBackgroundJob("sweeper", cleanup.Sweeper.process(cfg)) runBackgroundJob("deployment_monitor", DeploymentMonitor.loop(cfg))
  31. 41.

    Nelson runBackgroundJob("auditor", cfg.auditor.process(cfg.storage)(cfg.pools.defaultExecutor)) runBackgroundJob("pipeline_processor", Stream.eval(Pipeline.task(cfg)(Pipeline.sinks.runAction(cfg)))) runBackgroundJob("workflow_logger", cfg.workflowLogger.process) runBackgroundJob("routing_cron", routing.cron.consulRefresh(cfg) to

    Http4sConsul.consulSink) runBackgroundJob("cleanup_pipeline", cleanup.CleanupCron.pipeline(cfg)(cfg.pools.defaultExecutor)) runBackgroundJob("sweeper", cleanup.Sweeper.process(cfg)) runBackgroundJob("deployment_monitor", DeploymentMonitor.loop(cfg))
  32. 42.
  33. 43.
  34. 45.

    • The tech may be different, but the core principles

    are not • System design principles from the 1980's are still applicable today
  35. 46.

    • The tech may be different, but the core principles

    are not • System design principles from the 1980's are still applicable today • In this era of rapidly evolving and heavily marketed systems, we need these principles to guide us to make good decisions
  36. 47.

    • The tech may be different, but the core principles

    are not • System design principles from the 1980's are still applicable today • In this era of rapidly evolving and heavily marketed systems, we need these principles to guide us to make good decisions • May your systems be simple, correct, and tussle-resilient