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.

Transcript

1. Everything old is new
   Yesterday's internet as today's infrastructure
   Adelbert Chang
   
   @adelbertchang
   
   AI Engineer @ Target
   

   View Slide

2. https://landscape.cncf.io/
   

   View Slide

3. https://kubernetes.io/
   “Kubernetes (K8s) is an open-source system for automating
   deployment, scaling, and management of containerized
   applications.”
   

   View Slide

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.”
   

   View Slide

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.”
   

   View Slide

6. https://linkerd.io/
   “Linkerd is an ultralight service mesh for Kubernetes. It gives you
   observability, reliability, and security without requiring any code
   changes.”
   

   View Slide

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.”
   

   View Slide

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.”
   

   View Slide

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.”
   

   View Slide

10. https://landscape.cncf.io/
    

    View Slide

11. https://landscape.cncf.io/
    

    View Slide

12. View Slide

13. ARPANET circa 1969
    

    View Slide

14. November 1984 August 2002
    October 1983
    

    View Slide

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.”
    

    View Slide

16. “Keep it simple. Do one thing at a time, and do it
    well.”
    

    View Slide

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.”
    

    View Slide

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.”
    

    View Slide

19. View Slide

20. View Slide

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.”
    

    View Slide

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.”
    

    View Slide

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.”
    

    View Slide

24. https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar
    

    View Slide

25. https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar
    https://www.khanacademy.org/computing/ap-computer-science-principles/the-internet/tcp-fault-tolerant-transmission-protocol/a/internet-routing-protocol
    

    View Slide

26. https://www.nginx.com/blog/what-is-a-service-mesh/
    

    View Slide

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.”
    

    View Slide

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.”
    

    View Slide

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.”
    

    View Slide

30. 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
    Nelson
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

39. F
    1.2.3
    G
    1.0.9
    C
    2.3.6
    D
    2.2.0
    E
    4.12.8
    B
    5.4.6
    A
    1.1.6
    Nelson
    

    View Slide

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))
    

    View Slide

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))
    

    View Slide

42. Nelson
    

    View Slide

43. View Slide

44. • The tech may be different, but the core
    principles are not
    

    View Slide

45. • The tech may be different, but the core
    principles are not
    • System design principles from the 1980's
    are still applicable today
    

    View Slide

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
    

    View Slide

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
    

    View Slide