Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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.

Adelbert Chang

November 14, 2019
Tweet

More Decks by Adelbert Chang

Other Decks in Programming

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