My name is Kas. I’m a Cloudflare employee and I wanted to share my story with you on International Transgender Day of Visibility.

I've been different for as long as I can remember. I've been the odd one out not just for the time I've spent in tech, but most of my life.

I'm transgender in that I am gender non-binary. I'm working with the word 'agender' right now, as it is the word that describes me best: I'm not a woman, or a man, just a human. I don't really have a gender, and I certainly don't identify with either binary label.

The agender flag

Being transgender in tech is difficult. There are many times where we have to work harder, smarter, and give up so much to stay afloat. Times where you have to weigh the benefits of correcting your pronouns against the title of the person who is to be corrected (are they a customer? Your bosses' bosses' boss?). Times where you don't know if you can even be 'out' with your coworkers, because you just don't know if, or how, they'll treat you differently, or fairly.

Being agender or outside the binary represents its own special quirks: I get asked a lot if I'm OK with going to women's groups; I quickly explain that I am not a woman, but I try to be an ally to women, and see if the invite still applies. On International Women's Day, I got a bit of well-meaning attention as a ‘Woman in Tech.’ I had to think for a bit: should I just bite the bullet and accept the attention while glossing over my identity? In the end, I decided to speak up and redirect the attention to actual women-- And yes, before you even think to ask, I mean ALL women, including and especially trans women.

I'm lucky to be at Cloudflare; my coworkers respect my pronouns, and I'm treated fairly. We even have an organization, Proudflare, that advocates for LGBTQIA+ Cloudflare employees and folks in general. It's still hard to be visible and trans in tech. For those who are out, and proud, and loud; be sure to recognize their work. Think about the extra work trans folk put in to be visible while trying to remain safe and healthy. I can't and won't speak for the entire trans community, but I can respect their experiences and I can listen to them.

I guess that's the one thing I might ask of the reader here: listen to trans people. Really listen. And, if they seek to be visible, help them. Share their work.

That’s what happened to me just a few short weeks ago when I joined Cloudflare. The task: to create a light-up version of our Data Center map – we’re talking more than a hundred LEDs tied to the deployment state of each and every Cloudflare data center. This map will be a part of our booths, so it has to be able to travel; meaning we have to consider physical shipping and the ability to update the data when the map is away from the office. And the fun part – we are debuting it at SF Developer Week in late February (I even get to give a talk about it!) That gave me one week of software time in our San Francisco office, and a little over two and a half in the Austin office with the physical materials.

What the final LEDs will look like on a map of the world.

So what does this have to do with Serverless? Well, let’s think about where and how this map will need to operate: This will be going to expo halls and conferences, and we want it to update to show our most current data center statuses for at least that event, if not updating once a day. But we don’t need to stay connected to the information store constantly-- nor should we expect to, over conference or expo WiFi.

The data stored about each data center has two distinct categories; data relevant to the data center itself, and data about how that data center should be rendered on the map. These are relatively simple data structures, however: for a data center, we want to store what city the data center is in, the latitude and longitude, and the status. We arbitrarily assign an ID integer to each data center, which we'll use to match this data with the data in the other store. We’re not going to pick and choose which data centers we want; just pull them all down and let the microcontroller figure out how to display them.

Speaking of, this is where the data store relevant to the display comes in. LEDs are on strands numbered 0-7, and are represented by an LED numbered 0-63. We need to store the ID of the data center we created for the first store, the strand number, and the LED number in the strand.

Both of these sets of data can be stored in a key-value store, with the ID number as the key and a JSON object representing either the data center or its representative LED on the map as the value. Because of this, coupled with the fact that we do not need to search or index this data, we decided to use Workers KV data stores to keep this information.

We needed two APIs around the data centers, and we needed them fast– both in the more immediate sense of having only a few weeks to complete the project, and in the sense that we needed the data to download relatively quickly over non-ideal internet situations. We also know this map will be traveling all over the world– we'd need the API to work and have at least a decent latency no matter where the map was geographically.

This is where the hundreds of LEDs comes in handy– each one represents a data center that we could deploy serverless Workers to. We can deploy the API to the data center before we leave from the comfort of the office, and it'd be ready for us when we hit the conference floor. Workers also, unsurprisingly, work really well with Workers KV data stores; allowing us to rapidly develop APIs around our data.

In the end, we ended up with this architecture diagram; 2 Workers KV data stores, and 2 serverless Workers; all of which can be deployed across the world in order to make sure the physical map has the updated data every time we head to a new show.

In the next post in this series, we'll take a look at the physical architecture of the sign:

We'll also take a look at the system we built that uses the architecture laid out in this post that consumes this data and turns it into an LED map – so keep an eye out for it next month!

Interested in deploying a Cloudflare Worker without setting up a domain on Cloudflare? We’re making it easier to get started building serverless applications with custom subdomains on workers.dev. If you’re already a Cloudflare customer, you can add Workers to your existing website here.

Reserve a workers.dev subdomain