Verified Commit a7aef592 authored by MrMan's avatar MrMan

Finish first draft

parent e8999500
......@@ -12,8 +12,9 @@
- The LAMP stack
- Reverse Proxies
- The Present (AKA the very recent past)
- VMs
- PaaS
- Virtual Machines (VMs)
- Platform as a Service (PaaS)
- Infrastructure as a Service (IaaS)
- Containers
- The Future?
- How does one keep up?
......@@ -298,7 +299,7 @@ Barrier to entry for new langauges to be used is now an ecosystem that contains
Now backends can be used for **websites with larger userbases, with flexibility in implementation language, and with *slightly* simpler architecture**.
# Crossing over into a new era #
# Before we cross over into a more recent past... #
We've come a long way -- let's step back and remember our fundamental description of a backend: **receive a request, return a response**.
......@@ -327,9 +328,9 @@ With separate processes running in VMs, one crashed (or malicious) process can n
# The Present - VMs (continued) #
Wouldn't it be really hard to make a completely virtual "machine" that mimics a whole computer? Yes -- but over the years it's gotten better:
But wouldn't it be really hard to make a completely virtual "machine" that mimics a whole computer? Yes -- so we optimized:
- CPU extend CPUs with new Virtual Machine Extensions ("VMX") instructions (Intel's VT-x and AMD's AMD-V)
- CPU manufacturers extend CPUs with new Virtual Machine Extensions ("VMX") instructions (Intel's VT-x and AMD's AMD-V)
- Linux gets Kernel-based Virtual Machine ("KVM") support in 2007
\scriptsize
......@@ -338,80 +339,178 @@ https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
# What did we gain? #
Now we can relatively performantly run isolated processes as "backends". If we put it all together:
Most of the complexity of VMs is hidden from the backend developer. The process now looks something like this:
- A process in a language of our choice that started in a VM
- An "outer" web server like Apache or NGINX receives a request
- An "outer" web server like Apache (which can reverse proxy) or NGINX receives a request
- The outer web server processes and passes some request to the VM
- The process (which may succeed or crash) inside the VM processes the request
Now we can write backends that are **more secure and better isolated, leading to safer use of more resources**.
Now we can write backends that are **more secure and better isolated, which use abundant resources in a safer manner**.
# The Present - PaaS #
# The Present - Infrastructure as a Service (IaaS) #
Here's an idea, if we have well known "stacks" like LAMP and Ruby on Rails, well known databases like MySQL, and VMs as a reasonable way to isolate them, why not automate the experience of deploying software?
Now that you can easily and safely use server hardware it makes a *lot* more sense to sell extra capacity. Maybe one could even buy and maintain capacity for the express purpose of selling it!
Heroku burst onto the scene in 2007 offering exactly this premise -- you provide the code, they provide the infrastructure, and they provide the scale.
Amazon Web Services (~2002/2006), by far the most popular "cloud provider" today is the culmination of that idea.
Elastic Compute Cloud ("EC2") and other offerings are only possible to operate reasonably safely with the isolation provided by VMs!
# The Present - Platform as a Service (PaaS) #
Simple concept: If we have well known "stacks" like LAMP and Ruby on Rails, well known databases like MySQL, and VMs as a reasonable way to isolate them, why not automate the experience of deploying software?
Heroku (2007) burst onto the scene offering exactly this -- you provide the code, they provide the infrastructure and the scale.
Today, the idea of a build pack has become so well known that it's been spun out of Heroku all together and is being adopted as a near-universal interface*.
\scriptsize
https://buildpacks.io
# The Present - Containers #
What if there was an easier way to isolate processes running on a machine *without* spinning up a complete VM.
Simple concept: Lighter weight isolation for processes.
VMs are the gold standard, but in many cases they're not completely necessary -- due to the way linux is built, simply obscuring/hiding interfaces at the kernel boundary (primarily the filesystem and limiting syscalls), can offer "good-enough" isolation without sacrificing performance.
# The Present - Containers (continued) #
As the saying goes, "Containers do not exist" -- they are a combination of two Operating System features:
- C-Groups (control of resources; compute, RAM, disk I/O, etc)
- Namespaces (visibility of various resources; process IDs, **filesystem**s, etc)
Containers are *not* VMs, but they achieve better-than-nothing isolation by using these two tools to make it *effectively impossible* for containerized programs to perform certain actions.
Namespaces are especially effective means of UNIX-y operating systems, since "everything is a file". If a spinning hard drive is represented by `/dev/sda`, and you can't *see* `/dev/sda`, you (usually) cannot write to that disk.
# The Present - Containers (continued) #
Containers are generally by-definition *less secure* than VMs and have had their share of growing:
- Container runtimes (`docker`, `containerd`, `cri-o`) gaining non-root user support
- `seccomp` support (limiting syscalls)
- `apparmor` / `SELinux` support (enforcing access control on system resources)
- `user` namespaces (`root` inside a container but *not* `root` outside)
- Capabilities & capability dropping support (reduce blast radius of compromised programs)
- Various kernel-level features, integrations, and bugfixes
\scriptsize
User namespaces progress (2012) - https://lwn.net/Articles/528078
# The Future #
## So where are backends going now/next? ##
# Disclaimer #
A few things to keep in mind:
- I know even less about the future than I know about the past
- You (probably) should not base your outlook on 1 slide in a short talk
- There are no silver bullets, and there are no werewolves. Good engineering is elegant, not magical.
# The Future - More client-side rendering #
##Why?##
## Why? ##
- Offloading rendering to more powerful clients means smaller, simpler, more focused backend services
- Weaker client? Don't worry, we've come full circle with "isomorphic" apps and Server Side Rendering ("SSR")
- What about weaker clients? Don't worry, client-side rendering has also gone full circle with "isomorphic" apps and Server Side Rendering ("SSR")
- Specialization of *types* of backends (ones that serve data, others that serve webpages)
- Faster iteration for separate teams (see: microservices)
## Why not? ##
- Maybe you should just use your Rails/Django templating layer, instead of setting up 1/2+ new frontend tools
# The Future - More shades of isolation #
## Why? ##
- There is space to be explored between raw process and VM
- Minimal VM Managers (AKA "Hypervisors"); NEMU, Firecracker, etc
- GVisor
- A program wraps yours and pretends to be the kernel
- Unikernels
- Leave out the bits of the kernel you don't need
- Go faster with more direct/optimizable hardware access
- Much smaller attack surface, less code normally means less bugs
## Why not? ##
- VMs might be good enough (for your use case)
- Containers might be good enough (for your use case)
# The Future - Container Orchestration #
##Why?##
## Why? ##
- Containers simplify deployment (basically fat binaries v2.0)
- Containers offer better isolation that raw processes, and no need to manage OS primitives on a machine (users, groups, etc)
- Automation is (generally) good
- Consistent management of a pool of servers
- Consistent management of a pool of machines as one
- Research-theoretical resource efficiency via bin-packing
- Consistent deployment across clouds (Kubernetes is supported by AWS, Azure, Google Cloud Platform, and others)
# The Future - Functions as a Service #
## Why not? ##
TODO
- Essential complexity is high for container orchestration systems
- Accidental complexity is also often non-zero
Why?
# The Future - Functions as a Service #
- Intense focus on business logic
## Why? ##
- Intense focus on business logic often means faster business success
- Near-optimal potential iteration speed
# The Future - Service Oriented Architecture (SOA) & Microservices #
## Why not? ##
- Not as portable as containers, due to different provider implementations (this is changing)
- Might be too granular
- Cold start complexity
- Persistent server vs function tradeoff becomes tricky at scale (watch out for network/supporting infrastructure cost)
TODO
\scriptsize
KNative - https://cloud.google.com/knative
Serverless cross-platform Framework - https://serverless.com
Why?
# The Future - Service Oriented Architecture (SOA) & Microservices #
- Simpler, more scalable systems
## Why? ##
- Simpler, independently scalable systems
- For most businesses flexibility initially trumps robust design (see: Mongo)
### Hot Take ###
The only discernable difference between SOA and microservices is a relience on a central message bus
# The Future - Continuous Deployment #
### Hot Take #2 ###
All well-designed monoliths are actually just extremely closely co-located bundles of micro-services
TODO
# The Future - Continuous Deployment #
Why?
## Why? ##
- Automation is important
- Systems that are deployed more frequently spend less time being broken*
- It's easier and safer to deploy thatn it's ever been before
\tiny
\*assuming errors go *down* over time
\normalsize
## Why Not? ##
- The tooling is hard to build
- Attempting to automate exposes you to some fundamental hard problems (automated release quality checks in noisy environments)
- Essential complexity is even higher (see: Istio)
# The Future - ??? #
No one knows what the future will actually hold, but most of it is here, it's just unevenly disributed*.
......@@ -420,55 +519,54 @@ No one knows what the future will actually hold, but most of it is here, it's ju
\* https://en.wikiquote.org/wiki/William_Gibson
# How does one keep up with all this? #
# How does anyone manage to keep up? #
No one keeps up with *everything*.
Things are moving very fast, but remember that fundamentals move slowly (if at all), since everything is built on them.
Personally when evaluating new technology I start by considering three things:
When evaluating new tools:
- What is the thing *supposed* to do and why?
- What did people use before?
- What does this new tool/approach bring to the table?
- What are the alternatives?
After spending some time looking at these things, you can boil down the new technology down to one sentence in your head to make it easier to digest, and refine your knowledge the next time it comes up. If the new technology is *really* interesting, take a few hours and read the architecture/documentation/code.
**If a tool can/does not mention nor convince you of it's value proposition quickly, just postpone investigation.** If it's important you'll (probably) see it again.
Also remember, keeping up is *relative* -- you don't have to be a core contributor to know the what and why of a tool.
Know at least the "what" and "why", make a one-sentence summary in your own head, and refine your knowledge as things shift. If the new tool is important, you'll see it again.
## Keeping up case study: Prometheus ##
# Keeping up case study: Prometheus #
**What is the thing supposed to do and why?**
Collect (application|infrastructure|...) metrics. People need metrics to make decisions (ex. knowing when disks are almost full).
Collect (application|infrastructure|...) metrics. People need metrics to make decisions (ex. how much hard drive space do you have left?).
**What did people use before?**
- literal human intervention (Q: "hey is X up?", A: "yep, looks like it")
- manual bash scripts (that email?)
- `cron` + bash scripts (that email?)
- literal human intervention
- bash scripts (+/- `cron`, +/- automated emails)
- Nagios
- Graphite
**What does this new tool/approach bring to the table**
# Keeping up case study: Prometheus (continued) #
- An focus on high label cardinality of metrics
- Labels versus hierarchical metric names
- Avoids aggregations for real data
\small
**What does this new tool/approach bring to the table?**
- Labels versus hierarchical metric names, better support for high cardinality
- Raw data queriying (no forced aggregations)
- Simplicity of deployment, with most batteries included (gathering, displaying, alerting)
- Standardization attempts (this is recent)
**What are some alternatives?**
- Graphite
- Nagios
- InfluxDB (if you add Kapacitor)
- netdata
- Zenoss (slightly more fleet focused)
- Zabbix (slightly more fleet focused)
- InfluxDB + Kapacitor
- Fleet focused tools:
- netdata
- Zenoss
- Zabbix
Inclusion of a comparison page in the documentation of a tool is a *very good* sign (Prometheus has one).
Inclusion of a comparison page in the documentation of a tool is a *very good* sign (Prometheus has one of these).
# The End #
......@@ -478,7 +576,7 @@ Thanks for listening
If you've got any corrections, complaints, or comments, feel free to reach me using the information below:
Victor Adossi ([email protected])
Victor Adossi ([email protected], [email protected])
GPG: ED874DE957CFB552
......@@ -493,19 +591,21 @@ Need help getting your organization to the past? I probably can't help with that
# Blooper Reel: Hot takes on interviewing (YMMV) #
Interviews are tests of an employer as well as an employee.
## Some things good companies do: ##
- Layered questions that increase in difficulty
- Questions at are very relevant to daily tasks
- Optional take-home assignments
- Train employees to be good interviewers (ex. giving hints, avoiding adversarial atmosphere)
- Train employees to be good interviewers
- Give feedback on interviews when possible
- Ask fizzbuzz
## Some things bad companies do: ##
- Read your resume (clearly for the first time) in the interview room
- Ask how many X will fit in some Y (ex. X=balls Y=school bus)
- Read your resume for the first time in the interview room
- Ask puzzle questions like how many X will fit in some Y
- Treat interviews like timed tests
- Ask questions completely unrelated to job responsibilities
- Never ask for feedback on their interview process
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment