Verified Commit 979047e6 authored by MrMan's avatar MrMan

Lots of writing

parent 2f4ab7dc
......@@ -2,11 +2,279 @@
% Victor Adossi
% April, 2019
# Roadmap #
- What is a backend?
- Past
- C programs
- Java & Servlets
- Reverse Proxies
- Present
- VMs
- Containers
- Container Orchestration
- Future
- ???
# Disclaimer #
I wasn't personally writing software in 1990/1997, and I'm not a computer science/sofware engineering historian. We're going to discuss in very broad strokes, and there will be mistakes.
If you notice some inaccuracies, write them down/keep them in mind until the end and my email will be available so you can enlighten me (and I'll update the slides).
# What is a backend?
# It starts with a "simple" question
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. We can call this a "web" server, but as we'll soon see, lately the middle layer of the three tier architecture concerns itself with serving *data* most of all.
## In interview question form ##
"What happens when someone types into your browser, and hits enter?"
## From a frontend engineer's perspective ##
"Where can I pull the data?"
## From a devops engineer's perspective ##
"How many instances do you need?"
A backend looks like a lot of things to different parts of a team but it has to do one very specific thing -- **answer requests from clients**.
# A simple Python backend #
import socket
HOST, PORT = '', 8888
listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
listen_socket.bind((HOST, PORT))
while True:
client_connection, client_address = listen_socket.accept()
request = client_connection.recv(1024)
client_connection.sendall("HTTP/1.1 200 OK\n\nHello, World!")
Building A Web Server, Part 1 (
# Our first definition #
Fundamentally, a backend needs to:
- Bind to a socket (at a certain address and port)
- Accept socket connections
- Receive some bytes for a given request
- (Optionally) Parse the received request
- Return some bytes as a response (in this case "Hello, World")
Put simply, we need to **receive a request, and return a response**
If that sounds too easy to be true -- you're right, it is. We're atop many layers of abstractions that enable the code to be relatively simple:
- Python runtime
- Operating System
- Sockets
- Networks, TCP/IP, Ethernet, etc
# The Past #
## How have people solved this problem in the past? ##
# The Past - C programs (~1990) #
Cern's `httpd` was the first web server, it's written in C.
C was one of relatively few options for writing software back then -- writing a backend in C in this day and age is very dangerous -- while C is very powerful, much of that power is raw, and is very easy to use in an unsafe manner.
We'll pretend this server worked much like (as the fundamentals are the same) the Python web server we had above, no need to look at C code today.
# What did we gain? #
Not to be understated, but as you might expect, building web servers is fundamental to the emergence of the World Wide Web.
At this point, backends can **receive a request and return responses** (remember, this is technically all it takes to have a "backend" as we've defined it).
# The Past - Java & Servlets (~199x) #
Java rose as safe-yet-performant alternative to C, and people started using it to write web servers. Here's a current example:
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class ServletLifeCycleExample extends HttpServlet {
public void init(final ServletConfig config) throws ServletException { ... }
protected void service(
final HttpServletRequest request,
final HttpServletResponse response
) throws ServletException, IOException {
public void destroy() { ... }
# What did we gain? #
Building servers in Java enables:
- Memory Safe(r) web servers
- Modular, pluggable web servers
- Making web server development more approachable for developers
The ability to use a safer, memory-managed language like Java increases the velocity of everyone hacking 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.
# The Past - CGI (~199x) #
New technology enables us to abstract away the web server itself:
- Performant, modular web servers (ex. Apache)
- Common Gateway Interface (CGI)
- New "scripting" languages (PHP, Python, Perl) to write programs in
PHP (1994) is what happens when we optimize a language for web development, and just sprinkle in some dynamic behavior:
<title>Hello World</title>
<?php echo "Hello, World";?>
# The Past - CGI (continued) #
So what does our flow look like now?
- A request comes in to the Apache webserver (C)
- Apache looks through it's configuration to find a handler
- The CGI protocol is used to call the relevant script/program
- The results of the script/program are sent to the user as a response
# What did we gain? #
The emergence of Apache and the CGI pattery is yet another step change in ease of use:
- Even more modular web servers
- The ability to easily use new, better programming langauges
Backends we write with the support of CGI can ***focus on business logic (leaving request/response wrangling to an "outer" web server)**, while achieving all our previous goals.
# The Past - LAMP #
One of the biggest step changes in productivity after CGI was the discovery/adoption of the LAMP stack:
- **L**inux - free, easy to use server operating system
- **A**pache - capable, modularized web server
- **M**ySQL - advanced application data management
- **P**HP - low-friction application runtime
This paradigm is/was **dominant** -- it reportedly made up for over 50% of internet traffic at one point.
# What did we gain? #
With the adoption of LAMP:
- Writing complex applications is now *much* easier
- More companies are able to enter the web sphere
- 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.
# The Past - Reverse Proxies #
Processes aren't really the past, per-say -- in the end *some* process is running *somewhere*, but the idea that you don't need
NGINX config example with upstream backends
# What did we gain? #
With the adoption of reverse proxies we gained:
- A simpler model for multiplexing applications
- Simplification of the role of the "outer" web server (Apache -> NGINX)
While this might seem like a little thing, but for every way that reverse proxying is *simpler* than CGI, more new developers and programming languages can be used.
The emphasis on reverse proxying instead of CGI spurred investment in better software libraries/ecosystems for various languages.
# Crossing over into a new era #
Remember our fundamental description of a backend: **receive a request, return a response**.
We've developed technology that makes it easier to do this in a safer and less error-prone manner than just writing completely custom applications in C:
- 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
- Easy use of commodity hardware for servers w/ Linux
- Widely adopted advanced data manipulation via MySQL
- Simpler, scalable systems with a focus on proxying
# Present #
## How do we solve this problem today? ##
# The Present - VMs #
As more and more computing power, memory, and harddrive space become available, you're probably going to want to run
How do you stop one (possibly compromised) `apache` process or `php` script from breaking your system?
Virtual Machines (VMs) are one of the widely adopted solutions to this problem -- allowing some process to run in a completely virtualized machine, offering *isolation* and *security*.
With separate processes running in VMs, one crashed (or malicious) process can now no longer crash others or fatally harm the host system. New hardware with more resources can be safely utilized efficiently.
# The Present - VMs (continued) #
Wouldn't it be really hard to make a completely virtual "machine" that mimics your computer? Yes -- but over the years it's gotten better:
- CPUs have gotten VX instructions (which allows a VM to pass through certain OPCODEs straight to the HOST)
- Linux released Kernel-based Virtual Machine ("KVM") support in 2007 which can take advantage of hardware support, runs much faster than userland code
- What happens when you type
# The End
......@@ -9,7 +9,7 @@ DATA_DIR ?= data
ENTR ?= entr
find 2018/04/* | $(ENTR) -rc make 2018-04-mercari-dev-meetup
find 2018/04/* | $(ENTR) -rc make 2018-04-mercari-dev-meetup-pdf
2018-04-mercari-dev-meetup: 2018-04-mercari-dev-meetup-html 2018-04-mercari-dev-meetup-pdf
......@@ -29,8 +29,9 @@ Victor Adossi
<div id="it-starts-with-a-simple-question" class="slide section level1">
<h1>It starts with a “simple” question</h1>
<p>Often an interview question:</p>
<li>What happens when you type</li>
<li>“What happens when someone types into your browser, and hits enter?”</li>
<div id="the-end" class="slide section level1">
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