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
2. https://landscape.cncf.io/
3. https://kubernetes.io/ “Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications.”
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.”
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.”
6. https://linkerd.io/ “Linkerd is an ultralight service mesh for Kubernetes. It gives you observability, reliability, and security without requiring any code changes.”
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.”
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.”
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.”
10. https://landscape.cncf.io/
11. https://landscape.cncf.io/
13. ARPANET circa 1969
14. November 1984 August 2002 October 1983
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.”
16. “Keep it simple. Do one thing at a time, and do it well.”
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.”
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.”
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.”
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.”
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.”
24. https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar
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
26. https://www.nginx.com/blog/what-is-a-service-mesh/
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.”
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.”
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.”
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
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
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
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
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
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
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
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
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
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
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))
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))
42. Nelson
44. • The tech may be different, but the core principles are not
45. • The tech may be different, but the core principles are not • System design principles from the 1980's are still applicable today
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
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