Radar 2.0 was built on the learnings of Radar 1.0 and was launched last month during Cloudflare's Birthday Week as a complete product revamp. We wanted to make it easier for our users to find insights and navigate our data, and overall provide a better and faster user experience.
We're building a Supercloud. Cloudflare's products now include hundreds of features in networking, security, access controls, computing, storage, and more.
This blog will explain how we built the new Radar from an engineering perspective. We wanted to do this to demonstrate that anyone could build a somewhat complex website that involves demanding requirements and multiple architectural layers, do it on top of our stack, and how easy it can be.
Hopefully, this will inspire other developers to switch from traditional software architectures and build their applications using modern, more efficient technologies.
The following diagram is a birds-eye view of the Radar 2.0 architecture. As you can see, it's divided into three main layers:
This post is also available in 简体中文, 日本語, 한국어, Deutsch, Français, Español.
During Birthday Week 2022, we announced a $1.25 billion funding program for startups building on our developer platform, Cloudflare Workers. This was done in partnership with 26 leading VC firms who have been investing in or seeking to invest in Workers-based startups.
Today, we’re excited to reveal the first cohort of Launchpad Startups as well as 14 additional VC partners, bringing the Launchpad to $2 billion in potential funding from 40 VC firms in total.
We are excited to welcome 14 additional firms to the Workers Launchpad, which you can find included in the image below. They have worked with hundreds of companies that have grown to become leaders in their areas including Asana, Canva, Figma, Netlify, Vercel, Area 1 Security (which Cloudflare acquired in 2022), and many others. Notably, they also represent a diverse group of investors who support startups across North and South America, Europe, and Asia.
Many of these investors have seen the competitive advantages of building on Workers through their own portfolio companies firsthand and are looking forward to providing the Continue reading
Recently, we wrote about a new fragment architecture for building Web applications that is fast, cost-effective, and scales to the largest projects, while enabling a fast iteration cycle. The approach uses multiple collaborating Cloudflare Workers to render and stream micro-frontends into an application that is interactive faster than traditional client-side approaches, leading to better user experience and SEO scores.
This approach is great if you are starting a new project or have the capacity to rewrite your current application from scratch. But in reality most projects are too large to be rebuilt from scratch and can adopt architectural changes only in an incremental way.
In this post we propose a way to replace only selected parts of a legacy client-side rendered application with server-side rendered fragments. The result is an application where the most important views are interactive sooner, can be developed independently, and receive all the benefits of the micro-frontend approach, while avoiding large rewrites of the legacy codebase. This approach is framework-agnostic; in this post we demonstrate fragments built with React, Qwik, and SolidJS.
Many large frontend applications developed today fail to deliver good user Continue reading
Henk made an interesting comment that finally triggered me to organize my thoughts about network-level host multihoming1:
The problems I see with routing are: [hard stuff], host multihoming, [even more hard stuff]. To solve some of those, we should have true identifier/locator separation. Not an after-thought like LISP, but something built into the layer-3 addressing architecture.
Proponents of various clean-slate (RINA) and pimp-my-Internet (LISP) approaches are quick to point out how their solution solves multihoming. I might be missing something, but it seems like that problem cannot be solved within the network.
Henk made an interesting comment that finally triggered me to organize my thoughts about network-level host multihoming1:
The problems I see with routing are: [hard stuff], host multihoming, [even more hard stuff]. To solve some of those, we should have true identifier/locator separation. Not an after-thought like LISP, but something built into the layer-3 addressing architecture.
Proponents of various clean-slate (RINA) and pimp-my-Internet (LISP) approaches are quick to point out how their solution solves multihoming. I might be missing something, but it seems like that problem cannot be solved within the network.
As Kubernetes continues to gain popularity, engineers have to know how Kubernetes works, and why it might make sense in their environment. What benefits does Kubernetes have in your environment and ultimately, what do technologies like containerization do for organizations. In this blog post, I’ll provide some basic background on containers and Kubernetes, and some […]
The post A Kubernetes Primer appeared first on Packet Pushers.
Network engineers normally use and support DNS as a service, but don’t tend to deploy, manage, and interact with DNS servers at an application level. For this episode of the Hedge, Andreas Taudte joins Tom Ammon and Russ White to discuss the many lessons learned from planning and deploying DNS as a service.
VMware Cloud on AWS provides a range of powerful security and networking capabilities. From enforcing granular security rules for traffic using NSX Advanced Firewall, to managing complex routes between your AWS environment and external resources via Transit Connect, there’s no shortage of tools available for supporting your business’s unique requirements when you leverage AWS as part of a VMware-based SDDC strategy.
To showcase some of the most powerful security and networking features of VMware Cloud on AWS, we’ve prepared a set of short videos where Ron Fuller, Senior Technical Product Manager at VMware, explains how the features work and how to get started using them. If you’re looking for a quick introduction to key security and networking concepts that impact VMware Cloud on AWS workloads, these videos are for you.
Keep reading for links to the videos, along with summaries of what you’ll learn from each one. We recommend watching the videos in order because Ron explains core Software-Defined Data Center (SDDC) concepts as he progresses through the videos, although viewers who are already familiar with SDDC may prefer to skip ahead.
On today’s Day Two Cloud we talk through the idea of “zero standing privilege”. Zero standing privilege is an evolution of credentials management that goes beyond always-on usernames and passwords and more advanced forms of privileged access management to help lock down access to sensitive systems. Our sponsor is strongDM and our guest is Britt Crawford, Director of Product.
The post Day Two Cloud 172: Lock Down Access With Zero Standing Privilege (Sponsored) appeared first on Packet Pushers.