EP190: Cloudflare vs. AWS vs. Azure
Sentry, Now With Logs (Sponsored)
Failed checkouts, dropped jobs, timeouts that don’t even throw errors ➡️ these are the issues that slow your team down.
With Sentry Logs, you can trace every step, from the user’s request through your code to the log line. And because Logs connect automatically with your errors, traces, and even replays, all your debugging context lives in one place.
TLDR: Sentry has Logs. More context, fewer tabs, faster fixes, more time shipping.
This week’s system design refresher:
Cloudflare vs. AWS vs. Azure
Popular Backend Tech Stack
HTTP vs. HTTPS
Forward Proxy versus Reverse Proxy
Concurrency is NOT Parallelism
SPONSOR US
Cloudflare vs. AWS vs. Azure
Cloudflare is much more than just a CDN and DDoS protection service. Let’s do a quick comparison of Cloudflare, AWS, and Azure.
Cloudflare has rapidly expanded beyond its traditional CDN roots, launching a suite of modern developer-first services like Workers, R2, D1, and so on. These offerings position it as a serious edge-native alternative to other cloud providers.
Here are the key cloud capabilities that Cloudflare supports:
Edge Compute and Serverless
Object and Blob Storage
Relational Databases
Containers
Sandboxes
Workflows
AI Agents SDK
Vector and AI search
Data Connectivity
AI Infrastructure
Content Delivery Network
DNS
Load Balancing
Over to you: Have you used Cloudflare’s new offerings? What are your thoughts on them?
Popular Backend Tech Stack
HTTP vs. HTTPS
When you open a website, the difference between HTTP and HTTPS decides whether your data travels safely or in plain sight. Here’s what actually happens under the hood:
HTTP:
Sends data in plain text, anyone on the network can intercept it.
The client and server perform a simple TCP handshake: SYN, SYN-ACK, ACK
Fast but completely insecure. Passwords, tokens, and forms can all be read in transit.
HTTPS (SSL/TLS):
Step 1: TCP Handshake: Standard connection setup.
Step 2: Certificate Check: Client says hello. Server responds with hello and its SSL/TLS certificate. That certificate contains the server’s public key and is signed by a trusted Certificate Authority.
Your browser verifies this certificate is legitimate, not expired, and actually belongs to the domain you’re trying to reach. This proves you’re talking to the real server, not some attacker pretending to be it.
Step 3: Key Exchange: Here’s where asymmetric encryption happens. The server has a public key and a private key. Client generates a session key, encrypts it with the server’s public key, and sends it over. Only the server can decrypt this with its private key.
Both sides now have the same session key that nobody else could have intercepted. This becomes the symmetric encryption key for the rest of the session.
Step 4: Data Transmission: Now every request and response gets encrypted with that session key using symmetric encryption.
Over to you: What’s your go-to tool for debugging TLS issues, openssl, curl -v, or something else?
Forward Proxy versus Reverse Proxy
A forward proxy sits between clients (users) and the internet. It acts on behalf of users, hiding their identity or filtering traffic before it reaches the external web.
Some applications of a forward proxy are:
Protect users while browsing the internet.
Helps organizations restrict access to certain websites.
Speeds up web browsing by caching frequently accessed content.
A reverse proxy sits between the internet (clients) and backend servers. It acts on behalf of servers, handling incoming traffic.
Some applications of a reverse proxy are:
Distributes traffic across multiple servers to ensure no single server is overwhelmed.
Handles SSL encryption/decryption so backend servers don’t have to.
Helps protect backend servers from DDoS attacks.
Over to you: What else will you add to understand forward proxy and reverse proxy?
Things Every Developer Should Know: Concurrency is NOT parallelism
In system design, it is important to understand the difference between concurrency and parallelism.
As Rob Pyke(one of the creators of GoLang) stated:“ Concurrency is about 𝐝𝐞𝐚𝐥𝐢𝐧𝐠 𝐰𝐢𝐭𝐡 lots of things at once. Parallelism is about 𝐝𝐨𝐢𝐧𝐠 lots of things at once.” This distinction emphasizes that concurrency is more about the 𝐝𝐞𝐬𝐢𝐠𝐧 of a program, while parallelism is about the 𝐞𝐱𝐞𝐜𝐮𝐭𝐢𝐨𝐧.
Concurrency is about dealing with multiple things at once. It involves structuring a program to handle multiple tasks simultaneously, where the tasks can start, run, and complete in overlapping time periods, but not necessarily at the same instant.
Concurrency is about the composition of independently executing processes and describes a program’s ability to manage multiple tasks by making progress on them without necessarily completing one before it starts another.
Parallelism, on the other hand, refers to the simultaneous execution of multiple computations. It is the technique of running two or more tasks or computations at the same time, utilizing multiple processors or cores within a computer to perform several operations concurrently. Parallelism requires hardware with multiple processing units, and its primary goal is to increase the throughput and computational speed of a system.
In practical terms, concurrency enables a program to remain responsive to input, perform background tasks, and handle multiple operations in a seemingly simultaneous manner, even on a single-core processor. It’s particularly useful in I/O-bound and high-latency operations where programs need to wait for external events, such as file, network, or user interactions.
Parallelism, with its ability to perform multiple operations at the same time, is crucial in CPU-bound tasks where computational speed and throughput are the bottlenecks. Applications that require heavy mathematical computations, data analysis, image processing, and real-time processing can significantly benefit from parallel execution.
SPONSOR US
Get your product in front of more than 1,000,000 tech professionals.
Our newsletter puts your products and services directly in front of an audience that matters - hundreds of thousands of engineering leaders and senior engineers - who have influence over significant tech decisions and big purchases.
Space Fills Up Fast - Reserve Today
Ad spots typically sell out about 4 weeks in advance. To ensure your ad reaches this influential audience, reserve your space now by emailing sponsorship@bytebytego.com.
This overview provides an "idealized" view of how Cloudflare has evlved and the core components of HTTP, TLS, Proxies and Concurrency, however it misses many of the trade offs that you will typically see when developing and deploying applications on these platforms. While Cloudflare's new Platform offerings have been well received, there are many questions to answer for developers who need to move past basic Worker Apps, such as vendor lock in, managing multi region state and debugging in a completely distributed architecture at the Edge, none of which are show stoppers, however all are very important considerations that far exceed the capability check list.
Also, the backend technology stack diagram, while technically correct, illustrates a problem most teams do not experience as a result of selecting the wrong programming language or framework, rather most teams experience problems due to underestimating migration complexity, entangled domain boundaries, or the cost of supporting fifteen microservices that should have remained as single services.
While the technical explanation of HTTP versus HTTPS is correct, in practice the difficulties experiencd by real world applications are not the handshakes themselves, but the complexities of debugging certificate chains, cert renewal across multiple region fleets and supporting clients that still provide buggy TLS implementations. Typically, curl verbose works fine until it does not.
Similarly, the Proxy portion of this overview is also accurate, however one of the largest omissions in terms of Observability and Caching Rules is critical to the operation of Reverse Proxies. Most of the mystery bugs I solve can be attributed to either misconfigured Reverse Proxies performing request normalization or quietly removing headers. This is where these concepts transition from purely theoretical.
Finally, with regards to Concurrency versus Parallelism, while Rob Pike's quote is frequently referenced, it is often forgotten that the true cost of the design is that most outages I see are related to Concurrency Issues such as races, starvation and deadlocks masquerading as performance issues. In my experience, parallelism is almost always the easier part of solving concurrency issues, provided that the design itself is sound.