Verified Commit b2641491 authored by MrMan's avatar MrMan

one round of edits

parent de867db0
......@@ -11,12 +11,12 @@
- Common Gateway Interface
- The LAMP stack
- Reverse Proxies
- The Present (AKA the very recent past)
- Present (AKA the very recent past)
- Virtual Machines (VMs)
- Platform as a Service (PaaS)
- Infrastructure as a Service (IaaS)
- Containers
- The Future?
- Future?
- How does one keep up?
# Disclaimer #
......@@ -27,17 +27,17 @@ If you notice some inaccuracies, write them down/keep them in mind until the end
# What is a backend?
Backend can refer to a lot of things, but we'll be mostly focusing on backends as used by/created for serving web/mobile traffic, in the "three tier architecture" style.
"Backend" can refer to a lot of things, but we'll be mostly focusing on backends as used by/created for serving web/mobile traffic, in the "three tier architecture" style.
## In interview question form ##
"What happens when someone types somewebsite.com into your browser, and hits enter?"
"What happens when someone types somewebsite.com into their browser presses the enter key?"
## From a frontend engineer's perspective ##
"Where can I get the data?"
## From a devops engineer's perspective ##
## From an operations engineer's perspective ##
"How many instances do you need?"
......@@ -86,8 +86,8 @@ Too easy to be true? It is. There are many layers of abstractions below that ena
- Python runtime
- Operating System
- Sockets
- HTTP, TCP/IP, Ethernet, Networking, etc
- Hardware
# Past #
......@@ -114,11 +114,11 @@ https://www.w3.org/Daemon
Not to be understated, but as you might expect, building web servers is fundamental to the emergence of the World Wide Web.
We've achieved the basic functionality required of any backend -- **receive a request and returning responses**.
We've achieved the basic functionality required of any backend -- **receiving requests and returning responses**.
# The Past - Java & Servlets (~199x) #
Java rose as safer, reasonably performant, cross-platform alternative to C, and people started using it to write web servers. Here's a current example:
Java arose as a safer, reasonably performant, cross-platform alternative to C, and people started using it to write web servers. Here's a current example:
\tiny
......@@ -161,7 +161,7 @@ Building servers in Java enables:
The ability to use a safer, memory-managed language like Java makes it easier to build things on the early internet
At this point, backends can **receive a request and return responses in a safe-yet-performant manner**, along with access to Java's easy-to-use rich ecosystem of libraries.
At this point, backends can **receive requests and return responses in a safe-yet-performant manner**, along with access to Java's easy-to-use rich ecosystem of libraries.
# The Past - Common Gateway Interface (~1997) #
......@@ -170,7 +170,7 @@ Write *any* program that receives information about a web request through `stdin
In this era we get to witness:
- The rise of performant, modular web servers (ex. Apache)
- New, "lighter" languages like PHP, Python, Perl can easily power web sites
- PHP, Python, and Perl rapidly gain popularity
- `.cgi` showing up in URLs all over the internet
PHP (1994) is what happens when we optimize a language for web development, and just sprinkle in some dynamic behavior:
......@@ -193,7 +193,7 @@ What does our journey to receive a request and produce a response look like now?
- A request comes in to the Apache webserver (C)
- Apache finds the relevant handler program
- CGI is used to call the handler program
- The CGI protocol is used to call the handler program
- The results of the program are sent to the user as a response
We've got at least 3 things to worry about:
......@@ -204,16 +204,16 @@ We've got at least 3 things to worry about:
# What did we gain? #
The emergence of Apache and the CGI pattern is yet another step change in ease of use:
Apache & CGI introdce a stepwise productivity improvement:
- Even more modular web servers
- The ability to easily use new, more focused programming langauges
Backends we write with the support of CGI can **focus more on business logic** and leaving request/response wrangling to an "outer" web server, while achieving all our previous goals.
Backends we write with the support of CGI can **focus more on business logic** and offload request/response wrangling completely, while achieving all our previous goals.
# The Past - LAMP (2000+) #
One of the biggest step changes in productivity after CGI was the assembly/adoption of the LAMP stack:
Another stepwise change in productivity after CGI was the assembly/adoption of the LAMP stack:
- **L**inux - free, customizable server operating system
- **A**pache - capable, modularized web server
......@@ -232,8 +232,7 @@ https://en.wikipedia.org/wiki/LAMP_(software_bundle)
With the adoption of LAMP:
- Writing complex applications is now *much* easier
- Adoption of LAMP and the web skyrockets
- More individuals/companies are able to get on the web
- Adoption of LAMP and the web form a virtuous cycle
- Linux, MySQL, PHP, and open source in general benefit greatly from the adoption/support
Backends we write now can **more easily render webpages, perform complex data operations, and run cheaply on commodity hardware**, while achieving all our previous goals.
......@@ -246,7 +245,7 @@ Apache was fast, but didn't do so well with concurrent connections, which became
NGINX was written with the explicit goal of outperforming Apache, and solving the C10K problem
NGINX's worker thread & asynchronous event loop driven approach (versus Apache's thread-per-request\*) allowed massive scale with limited resources (one core), but it achieves this by doing *less* (it doesn't handle dynamic content).
NGINX's worker thread & asynchronous event loop driven approach (versus Apache's thread-per-request\*) allowed massive scale with limited resources, but it achieves this by doing *less* (it didn't handle dynamic content).
\scriptsize
......@@ -307,10 +306,10 @@ We've developed technology that makes it easier to do this in a safer and less e
- Easy use cases are easy (ex. `apache` and a folder of files),
- More complicated use cases (ex. dynamic content, database queries) are very managable
- Safer programs in languages like Java, PHP, Perl, Python and Ruby
- Safer languages like Java, PHP, Perl, Python and Ruby
- Easy use of commodity hardware for servers w/ Linux
- Widely adopted advanced data manipulation via MySQL
- Simpler, scalable systems with a focus on proxying
- Focus on reverse proxying means simpler ("isomorphic"), more scalable systems
# Present #
......@@ -354,11 +353,13 @@ Most of the complexity of VMs is hidden from the backend developer. The process
Now we can write backends that are **more secure and better isolated, which use abundant resources in a safer manner**.
We've also increased reproducibility -- you can build the VM that's meant to run in production right on your own system.
# The Present - Infrastructure as a Service (IaaS) #
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!
Amazon Web Services (~2002/2006), by far the most popular "cloud provider" today is the culmination of that idea.
Amazon Web Services (~2002/2006), by far the most popular "cloud provider" today is the culmination of that idea (and some others).
Elastic Compute Cloud ("EC2") and other offerings are only possible to operate reasonably safely with the isolation provided by VMs!
......@@ -368,7 +369,7 @@ Simple concept: If we have well known "stacks" like LAMP and Ruby on Rails, well
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*.
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
......@@ -377,7 +378,7 @@ https://buildpacks.io
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.
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 (user privileges, filesystems, syscalls), can offer "good-enough" isolation without sacrificing performance.
# The Present - Containers (continued) #
......@@ -386,9 +387,9 @@ As the saying goes, "Containers do not exist" -- they are a combination of two O
- 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.
Containers are *not* VMs, but they achieve better-than-nothing isolation by using these two tools to make it *very difficult* for containerized processes to reach host resources.
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.
**Namespaces are especially effective means of isolating 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) #
......@@ -401,6 +402,8 @@ Containers are generally by-definition *less secure* than VMs and have had their
- Capabilities & capability dropping support (reduce blast radius of compromised programs)
- Various kernel-level features, integrations, and bugfixes
I've purposefully left out Linux Containers (`lxc`) here -- they're similar but slightly different.
\scriptsize
User namespaces progress (2012) - https://lwn.net/Articles/528078
......@@ -423,7 +426,7 @@ A few things to keep in mind:
- Offloading rendering to more powerful clients means smaller, simpler, more focused backend services
- 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)
- Specialization of *types* of backends (some serve data, some serve webpages)
- Faster iteration for separate teams (see: microservices)
## Why not? ##
......@@ -474,14 +477,16 @@ A few things to keep in mind:
## Why not? ##
- Not as portable as containers, due to different provider implementations (this is changing)
- Might be too granular
- Granularity - too much of a good thing?
- Cold start complexity
- Persistent server vs function tradeoff becomes tricky at scale (watch out for network/supporting infrastructure cost)
\scriptsize
KNative - https://cloud.google.com/knative
Serverless cross-platform Framework - https://serverless.com
OpenFaaS - https://www.openfaas.com
# The Future - Service Oriented Architecture (SOA) & Microservices #
......@@ -504,7 +509,7 @@ All well-designed monoliths are actually just extremely closely co-located bundl
- 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
- It's easier and safer to deploy than it's ever been before
\tiny
......@@ -520,7 +525,7 @@ All well-designed monoliths are actually just extremely closely co-located bundl
# The Future - ??? #
No one knows what the future will actually hold, but most of it is here, it's just unevenly disributed*.
No one knows what the future will actually hold, but it's actually here already, it's just unevenly disributed*.
\tiny
......@@ -538,7 +543,9 @@ When evaluating new tools:
- What does this new tool/approach bring to the table?
- What are the alternatives?
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.
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 #
......
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