Ahh, the Internet, the second-to-final frontier. People are inspired by its utility and its reach; you want to build, you want to create, you want to fix things! As technical tools get better, the ability to turn ideas into functional applications requires less-and-less coding. This article is for product people, those on their grind trying to bring functional products and services to the masses. We'll show you why "Delivery Networks" are the next thing you need to know about. Engineering background not required.
We'll start with an admission. Our Fly.io landing page is, at the moment, geared towards developers. We hope to first entice those trying to solve these same technbical problems before pitching the service to a more general audience. Onwards, to educational self-scrutiny.
Here's a quote from the page:
... It's a bit like a global load balancer, a smart reverse proxy, a library of powerful Middleware...
Indeed, that's quite a mouthful for a person who just want to know why something will be a boon to the construction and dispersal of their products. Fly, like other established and emerging services, is a Delivery Network.
By abstracting some of the more challenging distributed systems problems into clean interfaces, these services can save you both time and money and help you ship better products. They can increase the bandwidth of one individual and allow them to implement features and functionalities that, historically, would been pain-staking work for an experienced team.
Let's roll into a simplified breakdown of the three components above to see why having their essence at your finger-tips is a good thing for you.
A Global Load Balancer
A Load Balancer is a piece of software or hardware that sits in-front of an array of servers. It receives and disperses traffic. It's the maitre d' at the fancy restaurant that is your infrastructure, pointing visitors to empty tables. Its ultimate job is to help facilitate scale by spreading traffic in an even way across the server hardware behind it.
Load Balancers enable horizontal scale. Where once-upon-a-time, servers would grow UP -- as in, they would receive more ram, more CPU, and more disk space, they now grow sideways, are replicated. This makes a server more disposable, a link in the chain that can be struck up and down, willy-nilly.
A Load Balancer allows a server to become a functional unit. Need a hand receiving front-end traffic? Add another server unit, make your load balancer aware, then see your traffic disperse across all available units. Another important thing a Load Balancer might do is terminate a Transport Layer Security (TLS) connection.
TLS is the fortified S in HTTPS. HTTPS adds network over-head because of the handshaking process it adds to the beginning of a visitor's connection. As traffic arrives at a network, it behooves the engineering team to "terminate" - which is to say "decrypt" - the HTTPS connection so that data can move faster while unencrypted within their theoretically safer internal network. You can speed up HTTPS by having the Load Balancer closer to the user so that the back-forth-back encryption process is shorter.
When a Load Balancer achieves global status, that means there are many of them in many places instead of just one. Before the major players in the technical space started swallowing everything into opaque global networks, teams hosted their servers within a single location.
A single location makes it a challenge to deliver speedy applications and quick HTTPS. For example, if you have a server in Vancouver, but your users hang-out in Chicago, the speed of light, the basis for connection speeds, is capped based on distance and thus, so too are your site speeds -- too bad. Now, through global networks, distances are much shorter and so speeds are faster.
That's the long and short of it. A Load Balancer is a tool that disperses traffic, speeds up secure connections, and facilitates smoother scaling.
A Smart Reverse-Proxy
The first thing we'll do is some de-marketization. Proxies aren't smart, really. People, animals, and ineffable cosmic entities are smart. We call them smart reverse-proxies because they're not typical reverse-proxies. Through them, you can do nifty things. They're not smart, though. They can't power themselves, make art, voice opinions, or write their own code or anything like that.
Erm -- so, what is a reverse proxy? A reverse-proxy is similar to a Load Balancer, which can be confusing. Load balancing is a function of many reverse-proxies. It, too, can terminate SSL. It can perform caching, which can speed up your applications. If the Load Balancer is the maitre d', the one who ensures that people evenly distribute across empty seats, then the reverse-proxy is the one who suggested you visit that restaurant in the first place.
We can get deep into the weeds here, but we'll resist. It's good to know that a Load Balancer evenly distributes traffic while a reverse-proxy receives and routes traffic based on the type of request that it received. It can be the first point of contact for your visitor's requests prior to the request arriving at your servers.
Both reverse-proxies and/or Load Balancers are considered edge-servers and Points-of-Presences -- terms you may have heard when looking into Delivery Networks. Fly edges, for example, are reverse-proxies that load balance and execute Middleware.
A Library of Powerful Middleware
Again, minor marketing evisceration...
Powerful Middleware are pre-built features that can be applied to the request-response cycle. The request response cycle is the full path from a visitor requesting your site, your application processing the action, and then the server sending a response back to the visitor. Many things happen during this cycle; we felt that we could call them "smart" reverse-proxies because of how "powerful" Middleware function.
Middleware takes that same logical premise: you can deploy a library of pre-packaged code to empower useful features. But instead of plunking that code into your user's client, slowing down their explorations and cluttering your applications up, they're deployed from a global network of reverse-proxies.
They're called Middleware because the edge-server - the Point-of-Presence (PoP), the reverse-proxy - is in the middle of the request-response cycle. They're marketed as powerful because they can do a lot of technical heavy lifting for you. This makes your application code render faster to your end-user and disperses processing time across several, often specialized entities; speed is key and Middleware are all about speed.
WHAT DOES IT ALL MEAN!?
"Out with it, you nerd! Tell me why I want you!" -- Ah, yes, we're there now. We've made it out of the technical hulla-ballooey unscathed. A modern delivery network melds all of these features together. Here's why this is magical.
One Hostname to Rule Them All
When you dream of a project, one of the first dominoes to fall is the domain name. It's your brand, your handle, the name that will be on the marquee. Next, you want to get your product up and running with haste.
If you're selling a physical product then you may consider a solution like Shopify. Pick a theme, attach your domain and in no-time flat you have a functioning web-store available at your branded domain. But, what if you want to grow? What if you want to attach a blog for some expansive content marketing? What if the store was just the first step, the next step is an application you're out-sourcing? Soon, you have a domain and a bunch of pieces. Maybe it looks like this.
onehostname.com: A Shopify store-front.
medium.com/onehostname: Your Medium blog.
onehostnamicus.herokuapp.com: Your try-stuff-on-before-you-buy-it application.
You don't want to link out to these sites; you'd be bleeding that sweet, sweet SEO juice if you did! If you fork your properties into different locations, you aren't building authority for your central domain. More on SEO to follow.
Now, imagine you have a service whereupon you attached your domain. Once attached, you can then mount any number of backends, applications, or services to that domain. Once mounted, you can set-up rules to decide which
/paths on your domain route to which places. Everything on One Hostname. It's like lego for grown-ups; swap things around, arrange them how you like, always searching for the perfect pieces in the box to frankenstein into something magnificent. This is convenience but it's also empowerment.
A Global Network is faster than a regionally isolated network. Without getting too deep, we'll look at how things get faster.
Why are fast applications important? Revenue!
We've written on that very topic: Why App Speed Matters: Revenue.
We mentioned one example earlier involving TLS termination in the HTTPS process: the closer your users, the shorter the distance travelled, the less render speeds compound on account of needing multiple trips for encryption. Another key source of performance improvement is edge-caching. Here's how it works.
There are two users living in Edmonton, Alberta. Your application is connected to a delivery network, but everything is hosted within India. That's a loooong way away. Luckily, your delivery network has an edge/PoP within Chicago. The first Edmonton-based user connects to your application from Chicago.
The initial connection is always faster due to the shortened distance, but the rest of the load is slow because the edge/PoP needs to travel from Chicago -> India -> Edmonton. However, the assets that the first user retrieved are now cached within the Chicago edge/PoP!
Now, when the second Edmontonian visits your application the assets that they need are cached and ready within Chicago. The majority of heavy assets don't need to travel all the way from India. Given the shorter distance, it's fast. Fast == revenue!
There are several key factors that a delivery network might improve in the world of SEO...
Time-to-First-Byte (TTFB): Search Engines need a way of ballparking how fast a user's page is. The easiest way to do that when you have millions and millions of sites to rank is with TTFB. TTFB is the time it takes for a server to respond with data to a visitor. A fast TTFB around the world means your sites receive positive ranking signals for performance; faster is better!
One Hostname: Instead of forking authority across different domains or sub-domains (subdomain.domain.com), using subfolders (domain.com/subfolder) ensures that all authority gained is gained within the right brand.
HTTPS: HTTPS is of ultimate importance to a safe Internet. Applying it also gives you better ranking signals; sites protected by HTTPS are ranked higher.
Localization: By leveraging Geo-Location Middleware, you can develop versions of your pages in multiple languages. Want to reach the Russians? Translate, route Russian visitors to your Russian pages, and gain rankings within Russian channels.
The goal of this article was twofold: First, to introduce you to the technical concepts that delivery networks appealing to web developers. Second, to provide a clear demonstration of why these services are vital to anyone building things on the Internet.
You want to get right to building a product. The less friction and the less technical burden required to build things, the quicker your dreams can become a reality. A Delivery Network can take a flat service and give it global dimensionality. Seize it, brave product-person!
Fly is a platform that helps you build and launch dynamic applications to users around the world. It's a bit like a global load balancer, a smart reverse proxy, a CDN, a library of powerful Middleware; woven together, it's a fast, powerful, and intuitive network that creators like you control. It's free to sign-up, as are your first 2,000,000 requests and 100GB of data transfer every month.
Spread your wings with Fly
Faster apps, simpler tools, happier visitors.Free Signup