Employee resource groups (ERGs) are important to a company’s success. They foster community and a sense of belonging, help drive organizational change, and improve the overall quality of an organization’s culture. Most importantly, they help organizations become more diverse, equitable, and inclusive. I’d love to share the history of ERGs at Cloudflare, as well as how they function and help influence the company.

When I joined Cloudflare in 2017, one of the first things I did was search “LGBTQ” in our company chat. A chat room of a dozen or so employees titled “LGBT at Cloudflare'' popped up. There was evidence of some historic chatter in the room, and it was clear some employees had gathered for drinks after work before. I immediately introduced myself to the group, and asked if they would be okay with me setting up a meet & greet event. We booked a conference room, ordered lunch, found an article to discuss, introduced ourselves, and collectively decided we wanted to continue hosting such events. In our second meeting, we decided we should make things official by deciding on a name. This was the birth of Proudflare, our employee resource group (ERG) for LGBTQIA+ employees and our allies, and the first official Cloudflare ERG. I was honored to serve as Proudflare’s first global leader.

Cloudflare employees have founded and advanced fifteen other ERGs since 2017. Afroflare, our ERG for people of the African Diaspora, was the next ERG to form, later in 2017. The most recent is Flarability, our accessibility ERG. All of our groups are focused on fostering community, celebrating diversity, supporting career development, and educating those around us, but serve different communities. We decided early on that if each ERG focuses on education, celebration, and inclusion, we’ll be successful in supporting our underrepresented communities and stimulating positive change at our company. We have come a long way and still have a lot of change to make, but I can safely say that we have definitely helped make Cloudflare more diverse, inclusive, and equitable.

Scroll down to read the mission statements of each of Cloudflare’s ERGs. You may also read more about our ERGs through blog posts they’ve published at Cloudflare.

Our definition: At Cloudflare, ERGs are employee-led and company-supported groups of underrepresented and/or marginalized employees or groups of employees who are focused on key Corporate Social Responsibility initiatives. These employees join together in the workplace based on shared characteristics, life experiences, or initiatives. ERGs are generally based on creating a community of support and belonging, enhancing career development of their members, and contributing to the development of a more inclusive culture at Cloudflare.

ERGs are led by passionate volunteer employees who serve in roles as global leaders, regional leads, initiative leads, communications leads, and executive advocates. We ERG leaders agreed early on to support each other in our work, so we formed an Inclusion Council. This council is made up of all ERG leaders as well as Cloudflare’s inclusion workshop facilitators and serves as a steering committee in order to surface and incite feedback on diversity, equity, and inclusion (DEI) topics. We meet monthly, in rotating time zones so we may include leaders from all regions. Some of our most successful ERG partnership initiatives were forged in our Inclusion Council meetings between Womenflare and Afroflare, Asianflare and Desiflare, Mindflare and Proudflare, Latinflare and Afroflare, and more.

Most ERGs leverage executive advocates to help gain support from our senior executives and help those executives become more involved in DEI initiatives. Advocates meet regularly with ERG leaders, review company-wide or external-facing ERG communications, amplify the voices and visibility of ERGs through written communications and participation in events, and advocate for the ERG at the executive level. An example of a successful partnership between an Executive Advocate and an ERG is our CTO, John Graham-Cumming and Womenflare. John has held several meetings with Womenflare members to listen to their needs and experiences, share company decisions, and find ways to better advocate for the women of Cloudflare. He also meets with Womenflare’s leaders biweekly to help with major initiatives and any roadblocks to progress.

The most important function of an ERG is to create a sense of belonging and community amongst their members and allies through chat room conversations and regular connection opportunities. ERGs typically also produce initiatives around global education and celebration opportunities such as Women’s Empowerment Month, Black History Month, Hispanic Heritage Month, etc. These initiatives include DEI discussion events, company-wide presentations, company-wide emails, blog posts, social media campaigns, Cloudflare TV segments, publication of antiracism resources, spotlighting of underrepresented and marginalized employees, advising Cloudflare teams on decisions such as inclusive benefits package selection and accessible office space construction, and helping to promote inclusion education programs.

Through these connection opportunities and initiatives, ERGs influence the overall organization. They attract more allies and encourage them to take DEI actions, help educate employees on systemic barriers to DEI, and help make the workplace more inclusive and enjoyable for everyone. I see ERGs as impactful grass-roots movements within a company and I’ve witnessed their positive impact firsthand.

Thank you for reading about Cloudflare’s ERGs. Sixteen ERGs is a good number, but I’m really looking forward to supporting the foundation and growth of even more, and helping our existing ERGs flourish. If you are interested in starting an ERG at your company or learning more about ERG best practices, I encourage you to check out the Human Rights Campaign’s article, Establishing an Employee Resource Group.

Our mission is to help build a better Global Afro-community at Cloudflare and beyond. We support each other's growth, share our community’s stories, and help to make Cloudflare a more diverse and inclusive company.

We provide a supportive environment for all employees of Asian and Pacific Islander heritage, work to create more awareness of the struggles our community has faced and continues to face today, and celebrate our rich shared cultures.

We provide community and resources for parents and families, and welcome allies, people who are interested in becoming a parent, or who are family-oriented.

We foster networking and build a sense of community amongst Cloudflare employees using the rich South Asian culture as a platform to bring people together.

We curate and share resources about disabilities, provide a community space for those with disabilities and our allies to find support and thrive, and encourage and guide Cloudflare’s accessibility programs.

Greencloud is a sustainability-focused working group made up of Cloudflare employees who are passionate about the environment and addressing the climate crisis.

We provide a forum for the Jewish people of Cloudflare where we support each other and celebrate our shared heritage.

The mission of Latinflare is to help create a more diverse workplace, create a sense of community + belonging for Latinx employees, and connect with the communities where we work.

We provide the Cloudflare community resources around mental health, as well as increase awareness and destigmatize mental health more broadly throughout our communities.

With a shared goal of education, we recognize the heritage and cultural presence of Native American employees at Cloudflare and illuminate the historical impact of policies and racism that continue to fuel prejudice and injustice, even to this day.

Our mission is to Educate and Celebrate, Globally! We find ways to support and provide resources for the LGBTQIA+ community and make sure that the Cloudflare community is a welcoming, inclusive place for all.

Ensure the Cloudflare community is welcoming and inclusive to those abstaining from alcohol and/or drug use by increasing awareness and destigmatizing the decision to choose sobriety.

We encourage the recruitment and retention of veterans of military service from any military around the world. We also provide a supportive environment and community space for those who have served to network.

Our mission is supporting women's professional development and success within Cloudflare.

Our mission is to provide community experience and resources to help women in our sales organization to grow professionally and support each other collectively.

Womenflare's mission is to create a community where all who identify as women feel supported and represented at Cloudflare.

Thirty-one years ago, on the anniversary of the National March on Washington for Lesbian and Gay Rights, we first observed National Coming Out Day as a reminder that one of our most basic tools is the power of coming out. One out of every two Americans has someone close to them who is gay or lesbian. For transgender people, that number is only one in 10.

Coming out - whether it is as lesbian, gay, bisexual, transgender or queer - STILL MATTERS. When people know someone who is LGBTQ, they are far more likely to support equality under the law. Beyond that, our stories can be powerful to each other.

Each year on October 11th, National Coming Out Day continues to promote a safe world for LGBTQ individuals to live truthfully and openly. Every person who speaks up changes more hearts and minds, and creates new advocates for equality.

For more on coming out, visit HRC's post.

Source: https://www.hrc.org/resources/national-coming-out-day

Last National Coming Out Day, I shared some stories from Proudflare members in this blog post. This year, I wanted to shift our focus to the experience and challenges of coming out in the workplace. I wanted to share what it was like for some of us to come out at Cloudflare, at our first companies, and point out some of the stresses, challenges, and risks involved.

Check out these five examples below and share your own in the comments section and/or to the people around you if you'd like!

While my first experience of coming out professionally was at my previous company, I thought I’d share some of the differences between my experiences at Cloudflare and this other company.

Reflecting retrospectively, coming out was so immensely liberating. I've never been happier, but at the time I was a mess. LGBTQIA+ people still have little to no legal protection, and having been initially largely rejected by my parents and several of my friends after coming out to them, I felt like I was at sea, floating without a raft. This feeling of unease was compounded by my particular coming out being a two part series: I wasn’t only coming out as transgender, but now also as a lesbian.

Eventually, after the physical changes became too noticeable to ignore (around 7 months ago), I worked up the courage to come out at work. The company I was working for was awful in many ways; bad culture, horrible project manager, and rampant nepotism. Despite this, I was pleasantly surprised that what I told them was almost immediately accepted. Surely this was finally a win for me? However, that initial optimism didn’t last. As time went on, it became clear that saying you accept it and actually internalizing it are completely different. I started being questioned about needed medical appointments, and I wasn’t really being treated any different than before. I still have no idea if it played into the reason they fired me for “performance” despite never bringing it up before.

As I started applying for new jobs, one thing was always on my mind: will this job be different? Thankfully the answer was yes; my experience at Cloudflare has been completely different. Through the entire hiring process, I never once had to out myself. Finally when I had to come out to use my legal name on the offer letter, Cloudflare handled it with such grace. One such example was that they went so far as to put my preferred name in quotes next to my legal one on the document. These little nuggets of kindness are visible all over the company - you can tell people are accepting and genuinely care. However, the biggest difference was that Cloudflare supports and celebrates the LGBTQIA+ community but doesn’t emphasize it. If you don’t want it to be part of your identity it doesn’t have to be. Looking to the future I hope I can just be a woman that loves women, not a trans-woman that loves women, and I think Cloudflare will be supportive of that.

My coming out story? It involves an awful lot of tears in a hotel room in Peru, about three and a half thousand miles away from anyone I knew.

That probably sounds more dramatic than the reality. I’d been visiting some friends in Minnesota and I was due to head to Peru to hike the Machu Picchu trail, but a missed flight connection saw me stranded in Atlanta overnight.

A couple of months earlier, I’d kind of came out to myself. This was less a case of admitting my sexuality, but more finally learning exactly what it is. I’d only just turned 40 and, months later, I was still trying to come to terms with what it all meant; reappraising your sexuality in your 40s is not a journey for the faint of heart! I hadn’t shared it with anyone yet, but while sitting in a thuddingly dull hotel room in Atlanta, it just felt like time. So I penned my coming out letter.

The next day I boarded a plane, posted my letter to Facebook, turned off my phone, and then experienced what was, without question, The. Longest. Flight. Of. My. Life. This was followed, perhaps unsurprisingly, by the longest taxi ride of my life.

Eventually, after an eternity or two had passed, I reached my hotel room, connected to the hotel wifi and read through the messages that had accumulated over the past 8 hours or so. Messages from my friends, and family, and even my Mum. The love and support I got from all of them just about broke me. I practically dissolved in a puddle of tears as I read through everything. Decades of pent up confusion and pain washed away in those tears.

I’ll never forget the sense of acceptance I felt after all that.

As for coming out at work, well, let’s see how it goes: Hi, I’m Mark, and I’m asexual.

I started my career working in consulting in a conservative environment where I was afraid that coming out would cause me to be taken less seriously by my male coworkers. I remember casually mentioning my partner at the time to a couple of close coworkers to gauge their response. They surprised me and turned out to be very accepting and insisted that I bring him to our Holiday Party later that year. That event was the first time I came out to my entire office and I remember feeling very nervous before stepping into the room.

My anxiety was soon quelled with a warm welcome from my office leadership and from then on I didn’t feel like I was dancing around the elephant in the room. After this experience being out at work is not something I think greatly about, I have been very fortunate to work in accepting environments including at Cloudflare!

Nearly a decade has passed since I first came out in a professional setting, when I first started working at a global investment bank in Manhattan. The financial services industry was, and continues to be, known for its machismo, and at the time, gay marriage was still illegal in the United States. Despite being out in my personal life, the thought of being out at work terrified me. I already felt so profoundly different from my coworkers as a woman and a person of colour, and thus I feared that my LGBTQIA+ identity would further reduce my chances of career advancement. I had no professional role models to signal that is was okay to be LGBTQIA+ in my career.

Soon after starting this job, a close friend and university classmate invited me to a dinner for LGBTQIA+ young professionals in financial services and management consulting. I had never attended an event targeted at LGBTQIA+ professionals, let alone met an out LGBTQIA+ individual working outside of the arts, academia or nonprofit sectors. Looking around the dining room, I felt as though I had spotted a unicorn: a handful of out senior leaders at top investment banks and consulting firms sat among nearly 40 ambitious young professionals, sharing their coming out stories and providing invaluable career advice. Before this event, I would have never believed that there were so many people “like me” within the industry, and most certainly not in executive positions. For the first time, I felt a strong sense of belonging, as I finally had LGBTQIA+ role models to look up to professionally, and I no longer felt afraid of being open about my sexuality professionally.

After this event, I felt inspired and energised. Over the subsequent weeks, my authentic self began to show. My confidence and enthusiasm at work dramatically increased. I was able to build trust with my colleagues more easily, and my managers lauded me for my ability to incorporate constructive feedback quickly.

As I reflect on my career trajectory, I have not succeeded in spite of my sexuality, but rather, because of being out as a bisexual woman. Over the course of my career, I have developed strong professional relationships with senior LGBTQIA+ mentors, held leadership positions in a variety of diversity networks and organisations, and attended a number of inspiring conferences and events. Without the anxiety of having to hide an important part of my identity, I am able to be the confident, intelligent woman I truly am. And that is precisely why I am actively involved in Proudflare, Cloudflare’s employee resource group for LGBTQIA+ individuals. I strongly believe that by creating an inclusive workplace - for anyone who feels different or out of place - all employees will have the support and confidence to shine in their professional and personal lives.

I really discovered my sexuality in college. Growing up, there weren’t many queer people in my life. I always had a loving family that would presumably accept me for who I was, but the lack of any queer role models in my life made me think that I was straight for quite some time. I just didn’t know what being gay was.

I always had a best friend - someone that I would end up spending all my time with. This friend wouldn’t always be the same person, but inevitably I would latch on one person and focus most of my emotional energy on our friendship. In college this friend was Daniel. We met while pledging a business fraternity our freshman year and quickly became close friends. Daniel made me feel different. I thought about him when I wasn't with him, I wanted to be with him all the time, and most of all I would get jealous when he would date women. He saw right through me and eventually got me to open up about being gay. Our long emotional text conversation ended with me asking if he had anything he wanted to share with me (fingers crossed). His answer - “I don’t know why everyone assumes I’m gay, I’m not.” Heart = Broken.

Fast forward 6 months and we decide to live together our Junior year. I slowly started becoming more comfortable with my sexuality and began coming out. I started with my close friends, then my brother, then slightly less close friends, but kept getting hung up on my parents. Luckily, Daniel made that easier. That text from Daniel about not being gay ended up being not as set in stone as I thought. We started secretly dating for almost a year and I was the happiest I have ever been. The thrills of a secret relationship can only last so long and eventually we knew we needed to tell the world. We came out to our parents together, as a couple. We were there for each other for the good conversations, the tough conversations, the “Facebook Official” post, and coming out at our first corporate jobs (A never ending cycle). We were so fortunate to both work at warm, welcoming companies when we came out and continue to work at such companies today.

Coming out wasn’t easy but knowing I didn’t have to do it alone made it a whole heck of a lot easier. Happy four-year anniversary, Dan.

To find resources about living openly, visit the Human Rights Campaign’s Coming Out Center. I hope you'll be true to yourselves and always be loud and proud.

To read more about Proudflare and why Cloudflare cares about inclusion in the workplace, read Proudflare’s first pride blog post.

Last Friday, at the end of Cloudflare’s 9th birthday week, we announced Workers Sites.

Now, using the Wrangler CLI, you can deploy entire websites directly to the Cloudflare Network using Cloudflare Workers and Workers KV. If you can statically generate the assets for your site, think create-react-app, Jekyll, or even the WP2Static plugin, you can deploy it to our global network, which spans 194 cities in more than 90 countries.

If you’d like to learn more about how it was built, you can read more about this in the technical blog post. Additionally, I wanted to give you an opportunity to meet with some of the developers who contributed to this product and hear directly from them about their process, potential use cases, and what it took to build.

Check out these events. If you’re based in Austin or San Francisco (more cities coming soon!), join us on-site. If you’re based somewhere else, you can watch the recording of the events afterwards.

Growing Dev Platforms at Scale & Deploying Static Websites

Serverless platforms like Cloudflare Workers provide benefits like scalability, high performance, and lower costs. However, when talking to developers, one of the most common reactions is, "this sounds interesting, but what do I build with it?"

In this talk, we’ll cover how at Cloudflare we’ve been able to answer this question at scale with Workers Sites. We’ll go over why this product exists and how the implementation leads to some unintended discoveries.

Speaker Bio:Victoria Bernard is a full-stack, product-minded engineer focused on Cloudflare Workers Developer Experience. An engineer who started a career working at large firms in hardware sales and moved throughout Cloudflare from support to product and to development. Passionate about building products that make developer lives easier and more productive.

When building a platform for developers, you can’t anticipate every use case. So, how do you build new functionality into a platform in a sustainable way, and inspire others to do the same?

Let’s talk about how we took a globally distributed serverless platform (Cloudflare Workers) and key-value store (Workers KV) intended to store short-lived data and turned them into a way to easily deploy static websites. It wasn’t a straightforward journey, but join as we overcome roadblocks and learn a few lessons along the way.

Speaker Bio:Ashley Lewis headed the development of the features that became Workers Sites. She's process and collaboration oriented and focused on user experience first at every level of the stack. Ashley proudly tops the leaderboard for most LOC deleted.

Agenda:

• 6:00pm - Doors open

• 6:30pm - Talk 1: Inspiring with Content: How to Grow Developer Platforms at Scale

• 7:00pm - Talk 2:  Extending a Serverless Platform: How to Fake a File System…and Get Away With It

• 7:30pm - Networking over food and drinks

• 8:00pm - Event conclusion

• DATE/TIME - October 3, 6:00pm-8:00pm

• LOCATION: Cloudflare Austin

Register Here »

• DATE/TIME - October 14, 6:00pm-8:00pm

• LOCATION - Cloudflare San Francisco

Register Here »

While you’re at it, check out our monthly developer newsletter: The Serverlist

Have you built something interesting with Workers? Let us know @CloudflareDev!

Sign up below to have The Serverlist sent directly to your mailbox.

Photo by Serge Kutuzov / Unsplash

Are you based in Moscow? Cloudflare is partnering with Yandex to produce a meetup this month in Yandex's Moscow headquarters.  We would love to invite you to join us to learn about the newest in the Internet industry. You'll join Cloudflare's users, stakeholders from the tech community, and Engineers and Product Managers from both Cloudflare and Yandex.

Tuesday, May 30, 2019: 18:00 - 22:00

Location: Yandex - Ulitsa L'va Tolstogo, 16, Moskva, Russia, 119021

Talks will include "Performance and scalability at Cloudflare”, "Security at Yandex Cloud", and "Edge computing".

Speakers will include Evgeny Sidorov - Deputy Head of Services Security Team at Yandex, Ivan Babrou, Performance Engineer at Cloudflare, Alex Cruz Farmer, Product Manager for Firewall at Cloudflare, and Olga Skobeleva, Solutions Engineer at Cloudflare.

Agenda:

18:00 - 19:00 - Registration and welcome cocktail

19:00 - 19:10 - Cloudflare overview

19:10 - 19:40 - Performance and scalability at Cloudflare

19:40 - 20:10 - Security at Yandex Cloud

20:10 - 20:40 - Cloudflare security solutions and industry security trends

20:40 - 21:10 - Edge computing

Q&A

The talks will be followed by food, drinks, and networking.

View Event Details & Register Here »

We'll hope to meet you soon.

Разработчики, присоединяйтесь к Cloudflare и Яндексу на нашей предстоящей встрече в Москве!

Cloudflare сотрудничает с Яндексом, чтобы организовать мероприятие в этом месяце в штаб-квартире Яндекса. Мы приглашаем вас присоединиться к встрече посвященной новейшим достижениям в интернет-индустрии. На мероприятии соберутся клиенты Cloudflare, профессионалы из технического сообщества, инженеры из Cloudflare и Яндекса.

Вторник, 30 мая: 18:00 - 22:00

Место встречи: Яндекс, улица Льва Толстого, 16, Москва, Россия, 119021

Доклады будут включать себя такие темы как «Решения безопасности Cloudflare и тренды в области безопасности», «Безопасность в Yandex Cloud», “Производительность и масштабируемость в Cloudflare и «Edge computing» от докладчиков из Cloudflare и Яндекса.

Среди докладчиков будут Евгений Сидоров, Заместитель руководителя группы безопасности сервисов в Яндексе, Иван Бобров, Инженер по производительности в Cloudflare, Алекс Круз Фармер, Менеджер продукта Firewall в Cloudflare, и Ольга Скобелева, Инженер по внедрению в Cloudflare.

Программа:

18:00 - 19:00 - Регистрация, напитки и общение

19:00 - 19:10 - Обзор Cloudflare

19:10 - 19:40 - Производительность и масштабируемость в Cloudflare

19:40 - 20:10 - Безопасность в Яндекс.Облаке

20:10 - 20:40 - Решения безопасности Cloudflare и тренды в области безопасности

20:40 - 21:10 - Примеры Serverless-решений по безопасности

Q&A

Вслед за презентациям последует общение, еда и напитки.

Посмотреть детали события и зарегистрироваться можно здесь »

Ждем встречи с вами!

Sign up below to have The Serverlist sent directly to your mailbox.

We're on the upper floor of County Hall

Our Auditorium is large enough to hold up to 250 attendees, but can also host a small group as well. It may be used for talks, workshops, panels, networking sessions, and more.

There is a large entry way for people coming into our 6th floor lobby where check-in may be managed. Once inside the event space, you will see a large, open kitchen area which can be used to set up event food and beverages. Beyond that is Cloudflare's All-Hands Auditorium space, which may be used for your events.

We have several gender-neutral toilets for your guests' use as well.

You may welcome your guests here. The event space is just to the left of this spot.

We can rearrange seating, based on the format of your meetup or event. The most common set-ups are Theatre Seating (chairs only, facing the video wall) and Workshop Seating (tables & chairs, facing the video wall).

An example of Workshop Seating with our video screens on.

Cloudflare will gladly provide light snacks and beverages including beer, wine or cider, and sodas or juices we have in our kitchen area. You are welcome to order additional food if you can be present to receive it and set it up. (We recommend appetizers/food that can be kept at room temperature, since we do not allow open-flame sternos.)

If your meetup is eligible, we may even be able to sponsor your additional food orders. Check out our pizza reimbursement rules for more details.

Our kitchen area is attached to the event space

If this all sounds good to you and you're interested in hosting your technical meetup at Cloudflare London, please fill out this form with all the details of your event. If you'd like a tour of the Auditorium before booking it, we will gladly show you around and go through date options with you.

Host at Cloudflare London »

You may also email us directly with any questions you have.

We hope to meet and host you soon!

We also warmly welcome meetups in our San Francisco All-Hands space. Please read and submit this form if your meetup is Bay Area-based.

Sign up below to have The Serverlist sent directly to your mailbox.

Sign up below to have The Serverlist sent directly to your mailbox.

We've partnered with the WebAssembly SF meetup group to curate three talks from Zack Bloom of Cloudflare, Laurie Voss of npm, and Robert Aboukhalil of Invitae.Event Type: MeetupLocation: Cloudflare HQ, San Francisco, CADate: February 20, 2019

View Event Details & Register Here »

Cloudflare engineers are delivering three serverless talks in downtown Oakland: How Workers Work, Security: the Serverless Future, and Building a Serverless World (Map) with IoT and Workers.Event Type: MeetupLocation: At My Sphere, Oakland, CADate: February 21, 2019

View Event Details & Register Here »

Cloudflare will be at Developer Week Bay Area. Be sure to check out Single-Process Serverless, Building an Iot World (Map) with Serverless, and Make Your Existing Application Serverless talks.Event Type: ConferenceLocation: Oakland Convention Center, Oakland, CADate: February 20-24, 2019

Register Here for a free Open conference ticket »

Check out our first edition of The Serverlist below and sign up here to have this newsletter delivered to your inbox.

The talk below was originally presented and recorded at Serverless Computing London in November 2018. If you’d like to join us in person to talk about serverless, we’ll be announcing 2019 event locations throughout the year on the docs page.

Cloudflare's Zack Bloom spoke at Serverless Computing London Conference

Many of the technical challenges of serverless (cold-start time, memory overhead, and CPU context switching) are solved by a new architecture which translates technology developed for web browsers onto the server. Learn about how serverless platforms built using isolates are helping to expand the kinds of applications built using serverless.

Zack Bloom helps build the future of the Internet as the Director of Product for Product Strategy at Cloudflare. He was a co-founder of Eager, an app platform for non-technical website owners, which was acquired by Cloudflare in 2016. He is also the creator of open-source projects which total over fifty-thousand stars on Github.

Check out our Workers recipes we have listed on our docs here »

To cap off 2018 we decided hit the road (and then head to the airport) with our Real World Serverless event series in San Francisco, Austin, London, Singapore, Sydney, and Melbourne. It was a great time sharing serverless application development insights we’ve discovered over the past year as well as demonstrating how to build applications with new services like our key value store, Cloudflare Workers KV.

Below is a recording from our Singapore Real World Serverless event. It included three talks about Serverless technology featuring Tim Obezuk, Stanley Tan, and Remy Guercio from Cloudflare. They spoke about the fundamentals of serverless technology, twelve factors of serverless application development, and achieving no ops at scale with network-based serverless.

If you’d like to join us in person to talk about serverless, we’ll be announcing 2019 event locations starting in the new year.

Fundamentals of Serverless Technology - Tim Obezuk (0:00-13:56)

Tim explores the anatomy of Cloudflare’s serverless technology, Cloudflare Workers, and how they can be used to improve availability, build faster websites and save costs. Workers allows you to run Javascript from 150+ data centers around the world.

The Serverless Twelve Factors - Stanley Tan (13:56-22:46)

Developers all know the benefits of the Twelve-Factor App methodology. It is now the industry standard for building modern web app services. Let’s take a look at how this applies to a serverless platform.

Achieving No Ops at Scale with Network-Based Serverless - Remy Guercio (22:46-49:21)

While most major serverless platforms have done an effective job of abstracting the concept of a single server or group of servers, they have yet to make it as easy to deploy globally as it is to deploy to a specific region. Building global applications with region-based serverless providers still requires a significant effort to set up both frontend load balancing and backend data replication. Let’s explore how network-based serverless providers are helping developers build applications of all sizes with a true No Ops mentality.

Check out our Workers recipes we have listed on our docs here »

Our Austin Real World Serverless event (in partnership with the ATX Serverless User Group Meetup) included two talks about Serverless technology featuring Victoria Bernard and Preston Pham from Cloudflare. They spoke about working out backend knots with Workers and building a router for the great good.

Working out Backend Knots with Workers - Victoria Bernard (0:00-15:19)

Cloudflare Workers is a platform the makes serverless development and deployment easier than ever. A worker is a script running between your clients' browsers and your site's origin that can intercept requests. Victoria went over some popular use cases of how proxy workers can dramatically improve a site's performance and add functionality that would normally require toying with complicated back-end services.

Build a Router for Great Good - Preston Pham (15:20-33:53)

Serverless computing is great, but requires routing or some kind of API gateway. Preston built a simple JavaScript routing library for serverless Worker scripts and explained how you can do this too. He built a router from the ground up, similar to other web application frameworks like flask or express.js.

Check out our Workers recipes we have listed on our docs here »

Stay tuned for more serverless technology video content.

On October 11, 1987, about 500,000 people marched on Washington for Lesbian and Gay Rights. This was the second demonstration of this type in the capital and it resulted in the formation of several LGBTQ organizations.

In the late 1980s, the LGBTQ community recognized that they often reacted defensively to anti LGBTQIA+ actions and the community came up with the idea of a national day for celebrating coming out. The anniversary of the 1987 march was chosen as that national day.

Each year on October 11th, National Coming Out Day continues to promote a safe world for LGBTQ individuals to live truthfully and openly.

Source: https://www.hrc.org/resources/coming-out

Here are seven examples of the coming out stories that surfaced from a company-wide awareness campaign. I hope you’ll enjoy reading these and will find inspiration in them. Let’s all be loud and proud and supportive of our (often silent) community members in their own coming out processes.

We were teenagers when my cousin (then male) originally came out as gay. We were and still are very close. We were born the same year, traveled Europe as small children, understood various languages and were both very adaptable middle children. Both our families settled in California when we returned to the US and continued to see each other regularly over the years. This gay coming out was no surprise to our large Latino family. We always accepted her just the way she was. It was later on when we were in college, I took a call from her when she was elated to tell me she was now, "working as a woman." That's when everything came into focus and we cried together over her transition to her true female self. She is an inspiration to me, my husband, our children and all the extended family who hold her dear, among many others. I couldn't be more proud of her and count myself lucky to be related to such a talented, honest, creative, beautiful and hard working woman.

From Rachel

My first love happened when I was sixteen years old. We dated for four years and had what I considered was a normal break up for that age. He wanted to pursue dreams in LA and I wanted to be in the Bay Area close to my family. We both agreed we were too young for long distance, so we amicably went our separate ways and promised to remain friends. We stayed in touch over the years and tried to maintain that we could remain best of friends despite being broken-hearted. I went to visit him a few times and noticed some trends in his friends. He had a lot of gay friends and we went to gay bars while I was there. I chopped it up to the industry that he was in (male model), but I would be lying if I didn't say I started to feel suspicious. Finally by the third time I came to visit, it just seemed so apparent that he had found another part of himself: one that seemed to make him feel at home. I cornered him one evening in a bar and said, "Please just tell me," and his response was, "Why? You already know," to which I said, "Because I need to hear it from you." He then turned to me and said, "I am gay". I looked at him, I kissed him, and my response was and will always be, "And I still love you. You are still the same person to me.”  

What people don't know is that because he had been a model I was teased about my "gay" boyfriend while we dated. What people don't know is that I was suspicious of this at the end of our relationship, but at twenty years old how do you talk to someone about that? It was obvious he was closed off and I wasn't ready to admit that I thought my boyfriend of four years was gay. What I did know was that my feelings were not what were as important as what he was going through. I knew him. I knew how he fought this. I knew how he saw that in his head that the happily ever after was supposed to be me or a version of me (aka female) with a white picket fence and children. I knew if I told him how crushed I was at the time it would upset him. So I told him what I truly believe inside my soul to be true and that was, "You are and will always still be the same person you have always been to me. You are the same good human that puts everyone else first and are one of the most loyal people I know. You treated me with respect, have always been so loving, and showed me what I good relationship was. I am so proud of you for showing me who you truly are inside and I will stand by your side the rest of my life."    

I was best woman in his wedding to a man. Some people don't understand our story. Some people ask me if I felt like our relationship wasn't real because he turned out to be gay. To that, I say our relationship was more real than most. His final choice in sexuality has nothing to do with that. Again, he has and always will be the same person to me. It doesn't change our history. We were a boy and a girl who at the time fell in love and who have now since found the loves of our lives in other people. His just happened to be a man.

From Daan

Around the age of thirteen, I knew that I had more romantic attractions towards the same sex. I didn’t have a crush, as many love stories tend to start, but I noticed my fellow students showed much more interests in girls than I did and so I came to the conclusion I was gay. It was that simple, quick and painless. In the next few months I told my friends about it, in my way I was proud about it, proud that I was able to be different.

>> Fast forward four years.

Growing up in the liberal lights of Amsterdam I’ve never had the feeling that coming out was a subject I had to worry about. My mother went to Paris with my sister for the weekend and I had the house for myself and during this weekend I remembered I never told my parents that I was gay, it was just never a thing. I decided that when she returned I would tell her. After she returned on Sunday I asked her to sit down because I wanted to tell her something important, she turned all white and asked: what happened? I told her that everything is fine and that I wanted to tell her that I was gay and would come home with a guy at some point. She directly got up from her chair and, I remember this like nothing else, she said “please, never scare me again, I thought something serious happened, you don’t have to tell me you’re gay, as a mother I know”. After that I went to my dad (my parents are divorced) and he replied the same that he already knew and that’s all good. In a way I expected nothing else but I was still happy the way it went. I wish everyone the same and have supportive friends. Don’t be worried about the world, put yourself on the first place and the right people will come to you.

From Malavika

There is no single coming out story - nearly every day involves coming out. Of course, it is most difficult to come out to the people who are most important to you or whose judgement impacts your life in significant ways, but being out and coming out is a continuous process.

As a bisexual person, coming out becomes even harder: what label do I use? Is it easier to say I am a lesbian? Is it easier to just not say anything at all when I am married to a man? When I first started coming out in a professional context in my early twenties, I simply identified as a lesbian. The label bisexual is often treated either flippantly or with suspicion. But, several years into my first job, I had a serious relationship with a man. I had to come out once again, but this time as a bisexual! It was actually even harder to come out the second time, because at this point, my coworkers and mentors had known me for years as a lesbian. I even had senior executives who were gay invested in my career because of my identity as a lesbian, and I felt as if I would disappoint them by being with a man. Even my mother didn't quite understand my sexuality. Concerned that I was not being true to myself, she told me, "If you like women, you should marry a woman, you don't have to please me or society, I just want you to be happy."

I am now happily married to a man, but I still feel it is important for me to be out as a bisexual woman. It is important for bisexual individuals to maintain this identity, because identifying as straight or gay ignores the totality of our romantic experiences. And with that, I come out once again, proudly, as bisexual.

From Rex

The day after the Supreme Court legalized same-sex marriage, I asked my mom what she thought about it. I told her that she should be happy because it means I can get married one day. She cried a bit. But not for long. It didn't start easily, but 3 months later, they were ready to meet my boyfriend and make him part of the family. From there it has been coming out every day to different people, but it makes me happiest to be myself and not a wolf in sheep's clothing.

From Sherry

I love telling this story—my son Juliao came out to me at age six.

We had just moved to Santa Monica. Being new to the area, I set out to make new connections on the then popular platform MySpace. One day, a friend named Luna came over to hang out. We were chatting in Juliao’s bedroom while he was playing with his rather large collection of My Little Ponies. I mentioned to Luna that I found it remarkable that most of the folks I had reached out to over the social media platform were gay. I elaborated that they were the most interesting and the best looking.  

Juliao chimed in, “I’m gay” in a very matter of fact way, shrugging his shoulders. Luna and I turned to him, amazed. Luna replied, “How do you know, Juliao? What does that mean?” Juliao quickly answered, “When two boys love each other.” [Like duh.]    

We didn’t make a “big enchilada” of his revelation, though inside I was beaming. I was extremely proud that he could articulate a part of his identity so clearly and fearlessly.

From Andrew

I was 24 years old when I first fell in love with a man. Before I met him, I actually thought I was dating men as part of an experimental phase in life. My boyfriend went to school in New York and I lived in Boston, so I'd sneak away on weekends to visit him and lie to my family and friends about where I was and what I was doing.  After we broke up, I knew I needed to come out to my friends and family. I hated that I had been lying to them and to myself.      

It took me a couple weeks to work up the courage to send my mother, father, and brother an email, sharing what was going on. I concluded the email with, "I can't really predict how you'll take this, so I'll probably be avoiding you for a while.  Send me an email when you can to let me know when it's not awkward to talk to you."  

My family welcomed the news swiftly with warmth and support. I was very fortunate to have a wonderful, loving family.

To find resources about living openly, visit the Human Rights Campaign’s Coming Out Center. I hope you'll be true to yourselves and always be loud and proud.

To read more about Proudflare and why Cloudflare cares about inclusion in the workplace, read Proudflare’s pride blog post.

For details of our other upcoming Real World Serverless events in Austin, Singapore, Sydney, and Melbourne, scroll to the bottom.

Video transcript:

Moderator: Okay, welcome to Cloudflare, everybody. I'm so pleased that you're here. This is the second event of our real world serverless event series. We had our first one in San Francisco just last week, and we were so excited to fly over here, both me and Jade and some other Cloudflare employees, and tap into this community here, because this is our second largest office.

We also frankly, love coming here to London to visit and engage with the developer community here. Let me hand this over to Jade and she'll speak a little bit about Cloudflare, and then we'll get started with speaker number one.

[applause]

Jade: Hello, everyone. Welcome to Cloudflare. It's on, okay cool. How many of you know what Cloudflare is? That's great. [laughs] I guess we can get started. We run about 10% of the internet as measured by request. Data centers in 154 places worldwide. Very recently, we launched a Serverless platform called Cloudflare Workers which allows you to write code that runs in Cloudflare data centers.

You'll be hearing about various things related to that, about practical real-world concerns and best practices when deploying serverless applications. You'll also be hearing from someone who worked on the integration with this Serverless framework all today. Without further ado, who's speaking first, by the way? Henry. Henry, come on up. Henry is our first speaker today.

[applause]

Henry: Cool, let me bring this up. Okay, we can get started. A little bit about myself, real quick. I work at Cloudflare which is as Jade just said, not a given. I work on our go-to-market strategy team, basically trying to make sure that our new products such as Cloudflare Workers actually are a success to our business. In that position, I have a unique view on both our engineering side as well as our sales side.

This talk is going to be quite high level, not very technical as opposed to the following talks. To those who are quite new to Serverless and the entire concept of running stuff and functions in the cloud, this is hopefully going to be interesting for you. To those of you who already know all of this, I'm going to try and maybe bring up a few ideas that you potentially haven't thought about yet that I've been exposed to in the last couple of weeks.

Real quick, we have an intro and very brief market overview, like apart from Cloudflare who is doing this kind of stuff and then some opportunities in the Serverless space. We're going to talk a lot about buzzwords. I came up with another one after seeing this tiny comic down here in Latin, because why the hell not? Basically, this just means a man made cloud, as in a literal cloud that's been built by humans. Because that's what I'm going to be talking about.

I hope you can all see this. If you think about it traditionally how you run software on your Internet, you run it on a server like a proper machine that's somewhere in a closet or a data center which is called an On-premise. One of the companies that I just took out here is Dell. They manufactured those SAPs.

You can buy server. It's a huge upfront cost, you have to maintain it. You probably have some networking team that has to plug all the cables in, make sure there's electricity, put on the software basically do literally everything. If your company, scales you have to buy more of them and if you company has to scale down, you somehow have to get rid of them or keep paying for them. The cost is per machine importantly. Some smart people thought, "Okay, that's really not ideal. That's not a good way of running a business.

What if your start up you can't really afford thousands of dollars on an actual server? They came up with infrastructure as a service. People literally give you their infrastructure as a service. So that's what DigitalOcean does and several other companies as well and you just go to those companies and you spin up a virtual machine and you're good to go. You can run your software there, but you still have to maintain your operating system, you still have to install stuff to make sure your program runs, web servers, everything. There's still a lot of stuff you have to maintain.

The good thing, and we'll see it here this is billed by the hour. You no longer have to worry about having a huge up front cost, but you can actually just scale this by adding a new instance for your virtual machine or adding a new server virtually. That's where Heroku comes in.

If this is a bit much for you and you don't want to maintain your operating system and wasteful things like that, you can just use a platform as a service. That's what Heroku does. You don't actually have to install anything anymore. You just use that platform and you run your code there. To those of you who are familiar with serverless and running functions in the cloud, this might already look a little bit like serverless, but it's not quite there yet. The important distinction is that this is still billed by the hour. Even if nobody uses you application and it's just sitting there being idle, you're still paying for the stuff. That's where functions come in, or functions as a service.

I took out Amazon here. Again, I don't think that these are the only people who do this stuff. There a lot of people who do this, I just took all the people who currently dominating the space or who are the first ones to do it. The important thing with functions is that you're not paying for this per request. So you don't have to think about how much RAM the machine is consuming or about any kind of CPU stuff and things like this. You literally just write a function and it does something. It's a unit of application logic if that makes sense.

It's a tiny piece of the logic of your application which represents this function and then you can have lots of functions which represent your overall architecture in the end. Of course, these can also interact with each other. I'm not saying that on-premise is evil or that everyone should use DigitalOcean and nobody should buy Dell service. Sometimes you might have to use one or the other and sometimes you might even use all four. It really depends on your specific scenario.

One final one that I just wanted to include here, there's obviously also SAS which just removes all abstraction there is. You don't even have to build any software anymore, like the software stack, you literally just click a button and you have your software. It's finished you don't have to write any code. It's like the ultimate level of obstructing your stack, basically.

Again, here you don't pay per request but you pay per user. That's just as a side note. Now, where does Cloudflare come in? We had Cloudflare in the end, and well the buzzwords. There you go. Basically, just going to reiterate this again real quick. We started with the Dell service on the left, the on-premise ones; then we went to virtual machines with DigitalOcean; and then I talked about Amazon and AWS.

If you  are familiar with AWS lambda, that's serverless. The idea is basically that you just have your function which runs on an Amazon data center and that's where Cloudflare comes in with another buzzword and an important distinction between serverless and originless. If you run your function on AWS lambda, it runs in a very specific location somewhere in a data center which you can choose. You can, for example, say this function runs in London. Which then also means that every time somebody requests this function to run that request will be sent to London and back which takes potentially a lot of time right and we can't change the speed of light. We at Cloudflare thought we would make the server less framework and basically put it into every one of our Cloudflare edge notes. Every location where we have a data center can run these functions.

We bring the serverless part where we take all of the infrastructure abstraction away and stuff and we add one more thing that you don't have to worry about, which is you don't have to worry about location anymore. You deploy your code and it runs everywhere in the world instantly.

Now we have some more buzzwords down here, courtesy of Cisco. Fog computing was a marketing term invented by Cisco, mostly related to IoT devices and if you delve into this whole serverless space a bit more, you're going to hear a lot about IoT.

We at Cloudflare don't do that much related to IoT and I wanted to avoid it on purpose first, because there's so much more that you can do with serverless but anyway, fog computing was invented, so to speak, or invented by marketing people anyway, in the context of IoT devices. Where Cisco basically said that if you have your IoT devices that send lots of data into your cloud for processing, that takes a lot of time. It makes more sense to do some processing on the edge, so to speak, before it gets to the cloud computer and that's what they refer to as fog computing.

You can see that all of these terms are more or less interchangeable, but the important part is to remember that we're trying to bring the computation as close as possible to the end user or to the end device. That's what functions do and we had Cloudflare typically use the edge to refer to our nodes, every data center we have. Other people sometimes refer to the edge as your actual device. You can run code on your phone, obviously but that just depends on the way you look at it.

Again, why we're doing this, why do we care if we are close to the end user? I just brought up this example again, because we were talking about IoT. If you have a smart speaker, like an Alexa and you ask Alexa about the weather in London, I'm sure maybe they just have a default response and it says the weather in London is always terrible, but typically, you would ask Alexa, how's the weather in London, and then Alexa would send some kind of requests to cloud server somewhere, that server would then probably send another request to an API, get the weather, return it to the user, and they will know that it's raining in London.

Basically, the closer we have this computational part to the user, the faster they will hear how the weather is in London. It makes sense to have this API request which asks for the weather come from somewhere in the same location as this devices. If somebody is hosting the cloud application which asked for the weather in San Francisco but the user is in London it makes absolutely no sense to to send that request to San Francisco, ask for the weather there, then return it back to London. With Cloudflare Workers, or many other platforms, you can easily implement something like this.

Actually, regardless of where you are, the code will always return quickly to the user. We reduce the run-through time. At the same time, we also reduce cost. If you think back to our Heroku or DigitalOcean example, if we have a smart speaker on our home, we're probably not constantly talking to it, or at least if we are, that would be weird. We really only want to have an infrastructure cost every time we actually have a request going to that device. Again, that's something that cloud functions solve.

The same thing that I am talking about here for IOT devices applies to websites as well so, every time I request something on my phone, it sends a request somewhere to a server, and I want that request to be fast, and I only want to pay for that request from an infrastructure-provider perspective when it actually comes in, and not constantly.

If you're completely new to this space, here's a list of some of the major players. As you can see, AWS is dominating the space, which is largely because they've been around since 2014. They were kind of the first ones to do functions as a service, and also they do a lot of other things. AWS has a whole bunch of things that integrate with their function as a service platform, building a pretty nice and holistic serverless environment.

The important thing to notice here though is, we're comparing apples to oranges. If you think back to what I explained previously about the difference between serverless and originless, you'll realize that actually, Cloudflare Workers is running everywhere. AWS Lambda is only running in one single location. That's not to say that Cloudflare Workers is better and that AWS Lambda, that's worse, but not the case. They're just different use cases and scenarios in which each of these solutions would make more sense than the other. We'll see how this develops, but it's just something to keep in mind when you develop your own applications.

Now something even more abstract, I hope you can read this. Basically, we have an infrastructural concern, and we have a multi-cloud concern. If you move your entire application stack to let's say Cloudflare Workers, you're going to expect it to never go offline of course, but that's the same thing you expect from every other vendor that you work with. However, inevitably, at some point, you may or may not have an outage. Anything could happen. As you can see and as you might already all know, people implement secondary CDNs, they implement Secondary DNS, what people haven't really thought about yet is how to implement secondary edge computes or secondary functions as a service. What happens if your serverless platform goes offline?

I thought about this and one solution would be to just put an additional serverless platform in front of it, which then routes the requests to let's say, AWS Lambda, and Google Cloud Functions. Then again, you have a third vendor so you're effectively solving your lock-in by locking yourself in even further. That's just an interesting challenge I want to leave you with. If you  come up with a great solution, might be a good business to start at some point. Regardless, even if you don't try to solve the whole secondary edge compute problem, workers is actually and in general, these functions as a service are great way of implementing a multi-cloud strategy, because you can effectively on every request that you got to your website, route your traffic to a different cloud provider according to different criteria.

If you have your content on, let's say, Google Cloud, and let's say AWS, you can decide on the fly which one is cheaper, at this very point in time, and then you route your traffic to AWS because it's five cents less than Google at this time. Then maybe an hour later or if the request actually comes from a different region in the world, you might want to route it to the other data center and so on. You can implement some pretty interesting vendor strategies using serverless computing. Even more opportunities.

To those of you who've already had some experience with serverless code that you wrote, you probably did something in these two regions. You probably did something that had a fairly minor impact. It may have been a temporary fix, it may have been a permanent fix, but you probably didn't put the future of your business and you didn't bet that on the serverless platform that you were using. Maybe you fixed a typo on your site because you were too lazy to SSH into your server and to do it properly, but then the next day you would actually log in and fix a typo. That's a temporary fix with a minor impact.

Another example is maybe your business name is misspelled in some places on your website like capitalized in a weird way, but it's actually like this is happening across the entire marketing side so you can't just quickly fix that everywhere. You just put in a worker, very minor impact while we just capitalize the F, doesn't change the word, but we'll leave it in permanently because why not? What I'm increasingly starting to see is people are using serverless technology as a form of a major impact scenario. One interesting way of using serverless is to actually enable your cloud migration or to patch your legacy infrastructure temporarily. Maybe you have an on-premise system and you're not happy with it, maybe you had some security vulnerabilities and you already planned to migrate to let's say DigitalOcean in the future. Well, you're not doing it immediately. So in the meantime, you can just do serverless to patch all of your leaks and keep your Website running for let's say half a year. Still, this is pretty critical stuff, so if it breaks your business would be in trouble.

Also, if you're trusting your business reputation or even revenue on a serverless platform, you probably want to use a continuous deployment integration tool to do so. You don't want to log into some IDE or some web portal and maybe make a mistake somewhere and be unable to roll back, you want to have some additional control here.

Actually, Cloudflare recently started supporting the serverless framework with Workers. So that's a step in that direction.

Then, this is extremely rare, but I think we're going to start seeing this happen a lot more in the future.

It's people who basically more or less build the entire application using serverless. For example, they would have their entire marketing side. So the entire public facing part of their Website in an originless architecture. The site does not have a server anymore that it runs on, it completely lives on, for example, Cloudflare's app service.

Also mentioned IoT integration here, for example, if you build a new smart speaker and you implement it with serverless, obviously if that breaks, that would be a pretty major impact on your business.

I also saw an interesting case study by AWS Lambda on Netflix. So Netflix does some of their media encoding using serverless technology. You all know Netflix if something like this breaks, it has a major impact on the business. At Cloudflare we see more and more people with a similar setup, whereby everything they do hinges on the fact that our workers are delivering their content fast and securely.

What I find interesting is that this is becoming a skill. People put this on their LinkedIn profiles. Almost bet that somebody here may be an expert on serverless, and maybe put something like that on their profile. Obviously, not only do people have this in their skill set, but also in their job titles. If somebody here in this audience have this skill I would love to meet them. If that happened by coincidence, that would be great, but the point is basically, this is a job description. This is no longer just an abstract thing that people talk about and it's intentionally started with the buzzwords. It looks like something really abstract that nobody really actually knows what it is but people make a living doing this. I got the inspiration to search for this in the first place. Because we at Cloudflare saw this job posting where somebody literally searched for somebody who's proficient at writing AWS Lambda code and Cloudflare Workers code. This is a skill set that you may want to develop in the future if you don't already have it.

With that, I'm going to leave you to the actual experts who know how to write this stuff and stop talking about it in a high level way. Because it is, in fact, not magic, it works, and we at Cloudflare are already doing it. Thank you so much.

[applause]

Moderator: Okay, all the way from San Francisco, Stephen Pinkerton. [applause]

Stephen: Everyone, thanks for being here. Thank you, Andrew. Heads up I'm very jet lagged, we're going to try to get through this together. I'm going to talk a little about real world serverless. I'm a product manager at Cloudflare. I work on some products adjacent to workers. Some things in the makes, some things in the works and something we actually shipped last week that I'll talk about in a moment.

Before this job, I worked in a couple of different engineering capacities in embedded software distribution systems.

If you have a Monzo card, I worked at Monzo. We'll talk about what is serverless, why it might be useful for you for side projects or for your business, and then how you can get started using it and where we see serverless right now and where we see it going in the future.

What is it? Serverless is really a way to build applications and write code in a way that doesn't need to be concerned about the underlying infrastructure on which it runs. You really get to express what your product does in the most concise way possible without worrying about how you're actually going to deliver that experience to customers.

We have a serverless product. We've built integration with the open source serverless framework which is a really convenient way to write platform independent code that you can deploy to different cloud providers. Our serverless offering Cloudflare for workers is now integrated with it. It's a really community way to deploy code, manage configuration within version control which was previously impossible. You manager entire application with a team, deploy it really easily, it makes testing much easier it's very cool. I recommend checking out.

How many people will use the serverless open source framework? That's cool, okay. Awesome thank you for coming. Okay. Why does serverless make sense? We'll take a step back and talk about the history of computing or the history of getting paged. A while ago depending on your needs as someone who like maybe writes code, you used to write applications that would run on your own hardware. You buy computers, you put them in a data center or in a room or you co-locate these computers in someone else's data center and you'd have to worry about networking, you have to worry about configuration management, how you deploy code, how you secure all these networking, it was all very complicated.

If something went wrong, if a cat or a person tripped over a networking cable, you got paged and it was your fault and you had a fix it. Now, we live in the cloud era. I'm sorry for saying cloud era, but we live in an era now where applications run isolated from each other. You can run these applications in a way that you maybe rent time on serverless providers, you may be rent time in terms of like microseconds or milliseconds if you're printing specifically CPU time on a service provider.

All of this is really analogous to you need somewhere to live. You can build your own house, you can buy a pre-built house, you can rent an apartment, you can buy an apartment, you can stay in a hotel and it really depends on what your needs are. If you need somewhere to live every night of the year or if you just need somewhere to stay for a couple of nights. Your requirements are different and the same applies for application.

A lot of people have different opinions about where the Internet is going and we really see it as how do you get code running as close to your customers as possible? One way that people are thinking about this might be possible is some sort of mobile age. Where your code is actually running in a data center or on servers at cell towers that are within maybe a couple of miles of where people's handheld devices are.

It really makes you ask the question of like what business are you in? This really comes down to how do you add value to your customers? What do your customers care for and how do you add value to them? Do you add value to your customers with technologies like this? Do your customers care that you run engine X? Or that you have a really cool Reddit set up or that you use micro-services in Net CD and LinkedIn, some sort of crazy infrastructure, or do they care about the experiences that you're delivering to them?

Really makes you ask that question and realize that your customer doesn't care about these things and maybe you shouldn't as well that you could free up your time your and resources by instead architecting your applications in a way that doesn't need to be concerned for these.

If you work in tech or you work in a technical capacity, you can just throw your job description down to something like this. Where you're trying to deliver some experience to some person in some part of the world really fast. So, why does this matter.? You might have heard of the famous AWS statistic that 100 milliseconds of latency is 1% of revenue. That's an important number to remember because maybe it makes sense to focus on that and not how cool your infrastructure is. It basically who you can pass the pager to who you want to be accountable. Do you want someone who's an expert at managing servers to be accountable for running your servers? Or do you want to do it yourself in addition to delivering an experience for your customers?

Something interesting I hope you noticed about this slide is that most of the world doesn't see the internet through windows that look like this. Devices used around the world generally don't look like an iPhone or Mac, people use all sorts of devices and so the experience you deliver to them is really what matters.

Serverless is a really powerful tool for expressing your business logic to your customers. It really just lets you focus on the product that you're going to deliver. This really means that you should focus on building products and delivering value and less on infrastructure. What can you do to do the minimal amount of work to provide the most value to your customers? Basically, where is your focus? This really applies to someone building a personal project or if you're working at a large company.

As an engineer, you should be afraid of a couple of things. As an engineer you should probably be afraid of code, you should be afraid of infrastructure because everything that can break will break, and everything is a liability. This goes back to who do you pass the pager to, to solve these problems for you. Because I would much rather have a larger company manage servers configuration management networking and someone like me. I'd much rather not figure out how to code locate a computer in a data center near my house. I don't think that really makes sense. Who do you pass the pager to in these problems? It really comes down to paying someone else to solve heart problems for you so that you can focus on your customers.

Of course, this comes with an asterisk. Serverless isn't a one size fits all solution. With engineering everything is complex and you probably have existing applications so you can't go serverless tomorrow. There are cases when it makes sense for these when you should be delivering to your customers to build your own patching layers and manage your own infrastructure.

We'll talk about the current state of serverless, how you can get started with it and then where we see serverless going. First-gen serverless is really an adaptation of the current model of computing where you maybe rent compute time by the hour you're leasing CPU time on someone else's servers. It really comes to standardizing a couple piece of technology that all of that relies on.

Serverless relies on containers that are running your application and running web servers. One problem that has come up a lot and you've probably heard about was the COLD-SAT problem, that's really a result of web servers not being optimized for spinning up really quickly to deliver requests on demand.

It also relies on the model of regional deployment where you have to pick where your application is going to be deployed and distributing your application is a very difficult concern for someone who is a developer and someone who's managing data. All I know like the current generation of serverless is really, really powerful and it's let people focus on the real problems that matter to their customers.

Right now you can go write code and deploy it and let people interact with it without worrying about public configuration, without worrying about networking or a lot of very hard problems that are time-consuming and people have solved many many times.

It's gotten us really far but it really relies on the previous generation of computing. Something that goes along with this previous generation is just complex billing, that many of you may have experienced if you use serverless technologies.

Now, tell me what this number is. This is the number of ways in which you can be billed for using AWS Lambda. You may have heard that serverless can be expensive depending on what cloud provider you're using and your use case. It can also be complex. You're running a business and you need to know how much it's going to cost to run your application and all a lot of these services are usage-based, so you don't get a bill until the end of the month. If your application or your project gets on the front page of hacker news, if you experience spikes in traffic, you want to be able to predict what you're going to be paying for this.

I'm sure you've seen the blog post before about people who don't expect the insane bills that they might get from a cloud provider. You see these all sort of problems of the current model. Although it's gotten us very far.

These are kind of requirements that we see as kind of the next generation of serverless, that you shouldn't be tied down to a region. Deploying your code to be fast and it should be global. You shouldn't worry about where your code is deployed. It should be accessible to your customers at low latency without variance in latency as well, something that you may see now with web servers needed to be eating to be restarted as you get more requests coming in. Your billing should be predictable. Your billing, your latency or how your application behaves should all be predictable.

With that in mind, I'll talk a little bit about workers. Workers is our answer to serverless and it's architected in a very interesting way where we look at the model of web browsers and how people run back in code right now. We asked ourselves if things are really being done the right way. This blank here is really like how your application might run right now where you run it behind a Web server like Apache or Nginx and someone accesses it in Chrome.

There's some problems with this. It's like Apache and Nginx aren't designed to be started up on demand to deliver requests in high volume. They're very good at delivering requests in high volume but they're not optimized for this COLD-SAT problem. People have been making very impressive strides on solving this problem, but the whole architecture is not on your side.

We looked at the way that web browsers run code and we thought that that might be an interesting way to let you run applications. A web browser executes JavaScript extremely quickly. As soon as you download JavaScript, you can start executing it and in some browser insert JavaScript runtime implementations, you're executing JavaScript before you even download all of it.

What if we take existing technology and standards and let you run code that you would normally think about running in the browser on the server. There is a service workers API, I won't get into that if you're interested in learning more about the technology behind this. Look up Kenton Varda's talk on YouTube. He is the architect behind all this.

Essentially there are some assumptions you can make about code that you run in a web browser where if you have drops running in two tabs, JavaScript in one tab can't modify the state of JavaScript running in the other tab and that's a really powerful form of isolation that you get. It also means that tabs are very lightweight that a lightweight concept that we're all aware of, it's much faster to open a new tab in a browser than it is to open up Chrome every time you want go to another website. A new instance of Chrome.

The latter is really about analogous to how web servers act right now. You speed up new processes and to speed up a new process with containers and everything. We really want to think of things as threads as tabs at your own encoding and the tabs with this code or running in isolation from each other. That's what we actually did with workers. We took the V8 runtime and we wrote some code on top of it, we put it across our 150 data centers around the world. You can take JavaScript that you would think about running in the browser and actually run it everywhere. The benefits you get are crazy.

Probably the most significant one, if you're concerned about using JavaScript is that you're not going to experience the extreme variance and latency that you may be right now with several applications where you hit your application, you hit an endpoint that's running a servers application and it might hurt your copyright or may need to go provision a new container for you. Start off engine X and start up your application.

There are benefits to this model, but you're going to be paying for it latency. It's interesting because the ideal of serverless is really that you should be paying for what you use. This really isn't what's happening. If you have high demand serverless application with lot of requests, you might have noticed or heard other people doing this where you have a cron job that consistently makes requests to your severless application to keep it awake and to keep your cloud provider from removing some of those containers and sort of scaling your operation back. You're no longer actually paying for just what you use, you're paying an extra amount just keep your application awake.

You may have some other breakdowns as well that people have done where they've modeled latency in their application. It turns out like optimizing latency in a serverless application isn't the same as you might do in a traditional application. All of a sudden you're optimizing the way your code is run on a serverless provider but the whole point of using a service framework would be to not worry about these problems and to let someone who's more qualified solve these problems for you.

Another very interesting model around what we've been doing is you get to treat this entire network of code that you deploy your code across all of these data centers around the world, and that you no longer have to worry about thinking about this as some big distributed application or distributed network. It's really a single computer that you can think about this as running your code and you can reduce it further. It's a single function running your code.

The fundamental unit here is an event that happens in your application. I also would recommend Kenton Varda talks, he goes to a lot of detail about this. It's a completely new way to write code that we've seen our customers are very powerful things with. On top of this if you deploy serverless applications you may complain that deployments take a long time and some cloud providers like me have 30 minutes to globally to deploy your application. Even if you're using a regional model where you need to specify what regions your code is going to, and you shouldn't be concerned about what region your code is being deployed to, like a deploy should be global it should be fast, your code should startup fast, your code should scale quickly as your request volume increases and pricing should be predictable.

You should have a solid idea of the variables that are being used to charge you for pricing or to charge you for your application. This is all stuff that we've learned from talking to our customers, and we've seen them use serverless applications for different things and come to us with questions about our other offerings but also with workers. How do I make services work for me?

People see the benefit of it, but sometimes like the first generation of it is just complex and it can be expensive. Something interesting that we've achieved with this and that the data really speaks is that, the cold startup time for the average worker is about five milliseconds and so that's where any workload you could deploy a worker, get on hacker news in a minute, your total scale in a predictable fast way.

I'm going to pull the plug for this integration that we made with the serverless framework I definitely recommend checking it out. Especially if you use workers already. It's a really easy way to manage your code with them, solve everything in version control. There's some great documentation on it. I highly recommend it. Just want to make a shout out to the engineers Avery and Norvik Cloudflare who worked on this. It’s something we're really proud of and we actually did this hot class week in San Francisco as well incarnation with the serverless team in San Francisco. It’s been really fun to work on.

Sevki: Hi, I’m Sevki I’m a software engineer at Cloudflare and if you haven’t had enough of this, we're going to talk about APIs and how that relates to H-computing. I have a very not so secret motive for giving this talk, I want to change your mindset about how you  think, how everyone thinks APIs should work.

Not to go over this over and over again, but this is what servers used to look like when I was growing up. It was a server in the back room or utility closet where cleaning supplies were. Then we went to this which I believe Google and Amazon just built this so they can put this on Reddit Cable Porn sub Reddit, makes for an amazing picture.

You don’t really care where your server is running, it’s just one of those machines. I think the CTF Netflix at some point said, they were asking him, "Why are you  using SSDs," and he famously said, "I'm not running SSDs, I only care about performance, Amazon is running the SSDs. Whenever one fails, they swap it out, they put it back in. I don’t care."

The future of computing even looks even more obstructed away from us where we don’t really have to care what operating system we're running on. We just care about the fact that we're running some sort of JavaScript code or Python code or something like that. We are stretching away all the operating system stuff that’s related to it. If someone said, you’re Lambda code or your WorkerScript is running on OpenBSD instead of Linux, would you care? I probably would not.

That’s the place we want to go, we don’t want to think about, "Okay this is the carnal patch that I’m running. For this operating system I’m currently running or the vulnerabilities, whatnot." We really want to only care about the code that we're deploying and nothing else.

In the end, not too late at the point, but we run from a server in the utilities closet to a server running in us-east-1b to no computers, but it's still one location that it runs on. I really want you  to think about, why code running on Cloudflare work is being very global is interesting.

Edge, when we say edge computing, edge in edge computing refers to the edge of the cloud, so it is the closest thing, closest computing units that are available to your users with the exception of the ones that they're looking at when they're running into each other on the station. There is a really, really important thing for you  to think about: what is the latency when someone refreshes their Twitter feed? What happens then? What happens when they're swiping on Tinder? How fast it is.

Matthew our CEO, very-- I was going to say he was very famous, but apparently not that famous, said, "We’re not there yet, but what we want to do is get to 10 milliseconds of 99% of the global population." Anywhere you might have a user, anywhere you might have someone, eyeballs that you want to attract, where latency matters, for the 99% of them, we want to be within 10 milliseconds. That is really, really important for us that we are closer to your users than to your region servers.

Now, we sort of think about all this interaction between our users and our servers, but in all honesty, it’s probably a little bit more like this. We probably want to be here. We don't want to be close to your server, we want to be close to your user. That really matters to us, because we really care about performance.

One of our colleagues Zack made a comparison of performance between Workers, Lambda and Lambda@Edge and this is the architect of Workers channelling Rita who is the program manager for Workers. We still have this mindset that- What are things that are cacheable? What are things that we want to put behind Cloudflare or a CDN? What are things we don't want to put behind the CDN? We probably do something like in our CI/CD pipelines, bundle JavaScript images, CSS files. We put hashes after them. We know that they're cached whatever.

When we're downloading them we know the correct version that we're downloading. Their libraries upon libraries built for this exact same reason. We can cache these things. We don't really think about API calls as being cached. Like, Jade mentioned earlier where now all these things like, machine learning and whatnot are becoming very, very popular. We're not really thinking about the cost of, "Okay, how much is it going to cost me to make another translation request to Watson? How much is it going to cost me if I make a request to Google's image recognition service? We're not really thinking about those things but more and more people are actually looking for those stuff. We really want to be able to at the edge when before someone is uploading something, we want to be able to do boost detection. We want to be able to figure out if a particular image that is being uploaded to our website is copyrighted material so we can stop it before it hits and becomes a extra cost for our support staff to deal with the abuse claim. Deal with the takedown notice or so on and so forth.

We don't really think about those things as being cachable but we think they are. We think authenticated pages should be put behind Cloudflare admin tools. We certainly do this internally. All our API calls are behind Cloudflare. All our admin tools and whatnot we put behind Cloudflare and there are reasons for this.

Your restricted content like, when the GDPR think it how many US-based websites just went offline for the entire European regions? They're using things like Cloudflare and whatnot to go, "Okay, this is coming from the origin is such-and-such country we're going to block it." We're now starting to think about these things and serverless end points as well.

You don't really have to think about workers as being a independent platform on its own. It can be complementary to all these things that already exist like, Google Cloud, Azure functions or Lambda or something like that or IBM's Watson or hosted services like that. This is our of the curses of working for Cloudflare is that the number of data centers update so much that we have to make these maps interactive so we can download the list of pops, and actually this doesn't really look right. Does anybody have? Yes, I think we should make those orange. He said setting up his first demo. What is our official orange for workers? Oh, sorry.

I should probably know this by now. Let's check if that's right. That looks about right. Let's see how fast that actual script is deploying. That's how fast Workerscripts deployed. No need to applaud for that. That is the global map of how many PoPs we have; points of presence and literally just as I click save it goes out on uploads it everywhere. It is really, really fast and it is extremely gratifying to be able to push code and then it's deployed in seconds. I think our current Max top limit for how long it will take is about 30 seconds, but I've never seen anything take that long. I think it's just something we say to basically, cover ourselves, but it really doesn't take that long.

What does all this have to do with GraphQL and this entire thing I was telling you about? Certainly, Henry and Stephen talked about this as well, where we really, really want these experiences to be as performant as it as it can be. So if I go back to this, what were you really want to be doing is because these things from Cloudflare, origin, a Cloudflare's edge to your origin. We can do a lot of things like do your argo-tunnel and whatnot and do smart routing and whatnot. Because we have this global network, we can route your requests from the orange cloud to your origin servers very, very fast. What we really want to be able to do is, we want to be able to get this distance as short as possible as well, because this really matters. If the round trip doesn't have to go all the way to your origin servers, that's a win. That's a win because your server is going to have less load, this person's batteries not going to die because they're waiting on HTTP connection to close and many of those add up. We really, really want to be able to fast.

One of the ways that some folks at Facebook some time ago, I think around 2015 figured out how to do this is by batching the bunch of these codes, so you don't have to open a new socket for every single call you make, and then incur the cost of doing a TLS handshake, a TCP handshake, and whatnot, and you just complete all those at one go and that is called GraphQL.

Here is what the GraphQL looks like. This is graphical, the GraphQL editor that the GraphQL team built. Let's actually try to write a query. I'm going to put this microphone down for a bit. I hope it doesn't make a huge punk sound. Notice as I'm typing, and this is one of the great things about GraphQL, is that you get autocomplete, because your entire API is defined in the schema.

It also gives you hints about what you need to put in and what not to put in. What we're going to do is, this is a GraphQL server that I wrote on top of our one-dot one APIs, which resolves DNS queries and returns us the data for it.

We're going to put the name, let's keep that in the company called Cloudflare. Then we're going to put the type in, autocomplete, thank you very much. Then we'll do quad A and then we get all the fields that we want, filled in automatically. Now, this is great, but what is really also great about this pattern is that you can shape your data without changing the server site code. That gives you the ability to iterate quickly. If you're writing a mobile application, you don't have to raise a ticket, to get the backend folks to change what the resulting data shape that you want to look like. You can just change it yourself. The interesting thing, so if I wanted to maybe get rid of the TTL and get rid of the name, let's get rid of the site as well, let's run that code and run again. Works.

What if I would want to have, multiple of these? Sorry, it's hard typing with one hand. Let's do IBM here. Now, I'm getting also errors as I'm typing them. The reason I'm getting an error here is, it says there's a conflict for resolve, because we already have something called resolve. As you can see on this side, this is the field that we return in our data object. What we're going to do is, we're going to call this IBM, and do this, then we're going to call this CF. Do that.

Is this an error? Not really, IBM doesn't have a quad A record. They're not like IPv6 yet. Shame on them. If I do, IPv4, go old school, that comes back. Thank you. One of the interesting things, as you can see is, these are separate. I'm going to go into the code in a bit. These are separate API queries that we're bunching together. We're doing them on the server site. Now the great thing about this is, I am going to go into the console. Let's look at our network.

Everyone okay? Right. As we can see, we're doing two different resolutions on our end and we're getting 47, 12, 24, 17, 22 milliseconds for not that small of a query that we're doing. Well, if we wanted to actually multiply these add more, let's call this MS. Good thing's Microsoft has a quad A record for the IPv6 right now. Let's see. No. Microsoft. LG. Or let's look at the MX records. Interesting. Yes, outlook.com.

If we do this over and over again you will see that all these things are resolving fairly quickly like 15 milliseconds, 19 milliseconds. If I keep going, it's going to probably even out somewhere around 10 to 20-ish milliseconds. The reason for that is we're caching these very, very aggressively on the worker. Let's actually jump into the code that does that. Everyone can read this? All right. This is our starting point. All this code is available. I'm just going to go through a few points of these but all this code is available on GitHub. You can go and play with it. I encourage you to play with it because if you clone the repo in three simple commands, you can build, when I say build, bundle your Workerscript into a single thing and deploy to cloudflareworkers.com. If any of you  are familiar with Rappler or Go playground or something like that. This is our playground for workers. You can go and write scripts. You don't have to sign up. You don't have to do anything. Just go in, put your code in and it works.

In the repo, there are three-- I'll just show you the repo. I'll show you the repo later. All right. Let's do this first.

Basically, first what we want to do is we're going to decode the code that we get. If you go and look at the GraphQL documentation online, you will see that most of it is set up for doing something like express or something like that where you need to set up an HTTP server. With Cloudflare Workers you just get the request. With the request we actually register an event I haven't included in this slide, but in the full code, this all will make sense. We handle the GraphQL request that receives an event, which is a fetch event, we're going to decode that query.- This is basically very simple boilerplate code that you need to have in the GraphQL implementation of Cloudflare, but I just wanted to put this here to show you that it literally is hundred something lines code to have a fully functional GraphQL server in workers. When GraphQL first came out, I really, really wanted to get into it, I just set up a server, how does that work, I have never found anything as simple as Cloudflare Workers to actually get started with GraphQL.

We basically do some house working, housekeeping. Because these are all worker scripts, use the standard web APIs, we basically get a body, we decode it literally by changing UTF-8 to strings. Then we do this one simple thing, which is the only external library that we have in this. It is the GraphQL resolver.

Let's look at the schema first and what a GraphQL schema looks like. The bits that were giving me autocomplete, and the e-names and whatnot, as you can see, these are the DNS record types that we have defined. If I go back here, and I close this bad boy and open this up and I look at the query I see resolve, name, string, type, record type, and answer. All these are documented and commented, it's all this code. We give this schema to GraphQL and GraphQL knows how to make introspection query out of it, and the introspection queries or also in GraphQL. You can actually find, for example, GitHub's or Facebook's or I don't know if Facebook has a public GraphQL, if they have, you can certainly go to github.com and look at their GraphQL API and their GraphQL API is defined in GraphQL and you can literally query through it to write tools and whatnot that you may want to use.

This is really the only query that we have for this particular GraphQL, code that we have which is resolve and it is the exact same signature for the function that we had. It basically says it needs a name that should be non-nullable type, and it will return to you an array of answers.

The GQL.query bit is the bit that we basically decode it and from the JSON object that gets posted to our server, we just take out the query bit and that is the GraphQL query that we send over here. This is the bit, It's a string that comes out of GQL.query right here. Let's look at the new route. What are we doing here? This is really the interesting bit of a GraphQL on workers or GraphQL anywhere really. We're passing in this event and we'll get into it in a bit.

We're basically here creating a root object. This root object has a constructor. Into it, we're passing event here. Basically, the signature for this function is basically Schema that you have to give it, the query that you have to give it and then route is optional, but basically it takes the Schema, it takes the query and it traverses through the query and figures out which fields of the object that you're passing into it to send back to you. If you take out like we did in this bit, if I put a name, it'll basically say when it's going through to query is going to say, "Hey, I want a distinct to me there as well," while that works.

Into this object, and this could be a very simple, plain old JavaScript object that we're passing in but we're passing in class and the reason for that will become clear in a bit. This bit is the only field. This could have been a field. We could have just basically said instead of having this be async function, we could have just had a string literal that will be returned from it, and that would have worked. Or it could have been the array of answer answer objects, and that would have worked. We could have basically hardcoded it. Well, what we're doing is we're returning a promise for what is to come to this object and that is going to enable us to take all these queries that we have, batch them, and paralyze them. As you can see, this resolve has a one to one mapping with the query as well. The X object that we have here is going to have a name and a type.

Let's go back to the event thing, why are we doing this? When we're constructing this root object, what we're doing is we're setting the resolvers field and that resolvers is a data loader. This is one of the patterns that Facebook folks came up with, and they use this very heavily on their back end services. What this does is, as you can see, it takes a object called keys, we don't know what it is, but we're probably sure those are keys. It has a batch resolver, and data loader does batch resolving by default and doesn't do single resolves, and there's a very good reason for that as well.

Let's go into that data loader thing and see what it does and more specifically why we're passing this event thing into the batch resolver. In the batch resolver, we're just going to take our keys iterate through them and we're going to resolve them one by one by passing IDs.

This is literally the only thing that actually does any queries outside. What we're doing here is, we're creating a new request. Again, this is all on the Mozilla Web API docs page, I think that everyone commerged on using MDM as the source of truth for the web APIs. We're saying this is an application slash/DNS JSON request that we're making. We're making it to cloudflaredns.com, we take the name and we put the type as query strings for this request. This was introduced two days ago. This is the very, very shiny new cache API that we have and Rita tweeted about this event. She has a blog post on the blog about how to use this. It's really, really cool. This is the the bit that we've been talking about where we want you  to think about, "Do I really have to make this request to IBM, Watson, or Google's machinery service to make this request and get it back. I have to do it again, then I have to pay ¢5 or however much you have to pay for it. No, you don't have to.

What you do is you open up your cache which we have them local to whatever pop you're connected to, then we match it with the request. This is why I'm basically up here constructing a new request. I go, "If the response is not empty really, I want to fetch this." What I then do is, this is why I've been propagating the event down, all the way down to here where I say, "Event, wait until cache put."

What this basically says to you, the Workerscript is, "Hey, you can keep writing. You can start writing." If I've received all my fetches and maybe six of these requests are batched together, a couple of them are cached a couple of them are not, you can start streaming the response back if you have everything you want ready. I'm going to keep this script working so you can cache all the requests that you've received. The next time someone comes in, these are all cached. We wait for the response and then we return it. That's pretty much all you have to do to get GraphQL on workers going.

There are a couple of other things that we do, because the object that we were passing into data loader were objects and not really single strings, what we're doing is basically concatenating two strings to say, "This is the domain name that I'm getting, this is going to be the cache key." Then we're basically here saying, "I'm going to use a simple map object that I have here. to use as my in memory cache." Then what we do is we basically stringify the responce, and that's our query result. That is literally all the code you need to get graft you out working on Cloudflare workers. That's me, the demand that I just made, the website is online here. The code is available on GitHub if you want to go and check that out. Like I promised, literally, all we have to do is MPM install, MPM ROM build, MPM RAM preview. Literally, to get this going on the Cloudflare workers playground is shorter than my entire talk. That's it. Any questions? Also this is where the documentation leaves. If you want to, you can email me at jake@cloudflare.com and I'm on Twitter and GitHub again.

Moderator: I'll now hand it over to our final speaker who has flown here from Madrid to speak not necessarily on our behalf, but his own behalf about his interesting workers use cases out in the real world. Paddy Sherry is a workers expert. We wanted him to come here and speak this evening. Thank you for coming here, Paddy.

[applause]

Paddy Sherry: Hello. So briefly about me. I work for Gambling.com Group. I'm a lead developer there. It doesn't have the quick switch. Anyway, we operate in the online gambling industry, and we do performance marketing. What that means is, we create lots of websites that offer reviews of online casinos, and present unbiased reviews, so people can come on and see which casinos are the best, and choose one based on their preferences. What we build on a daily basis are a global network of multilingual websites. We currently have 55 websites online. Another one just went online today, and they're based all around the world. The US, Australia, Europe, we have most continents, there's a website we're running there. We run everything through Cloudflare. Just get on to the tech stack.

These are some of our sites, gambling.com, bookies.com/sourcingcasinosource.co.uk. Our tech stack is entirely static websites served by the Cloudflare edge locations. There's no processing done on our servers when user request a page, everything is served by Cloudflare at their edge immediately. It basically means that we have an extremely fast collection of websites and we have minimal server cost because Cloudflare is serving everything for us. It's just a little graphic of basically what happens.

Obviously, the first request needs to get to a server so Cloudflare can cache it, but after that every single user no matter where they are they are getting served the website from a location close to them. It just means our platform is-- I don't want to say infinitely scalable but it's pretty robust.

The benefits of building our system this way is that it's fast. One of the number one things we're concerned with is speed is getting the website loading fast for users so we factor that into every technical decision we make and the primary benefit is that we have extremely fast websites.

They are also secure given all of the Cloudflare security features, we really don't have to worry too much about that side. They are served from the edge so there's nothing getting through to our server, we just let Cloudflare handle all of that. The combination of static HTML and speed is very SEO friendly and that means where we have somewhat of a head start in trying to rank highly in Google because of the technology choices we make.

We do have some limitations then and the primary one is static. Everything is the same for every user. When someone visits the homepage of a site it doesn't matter where they are coming from they all see the same content. Until now we've been doing okay with that, but about one year ago we decided that we need to start making these things dynamic and personalized in order to stay ahead of the competition. That's the primary problem that I face then as lead developer was trying to find a way to make all our static websites dynamic. Initially, I felt we were going to have to partly rebuild our platform and move to server rendered sites and have servers all over the world or use AWS to try and do it efficiently. For a while we were in a bit of deep period of research about how we were going to do this and then we heard about Workers so we were Cloudflare customer and we follow the blog and Workers was mentioned and straight away caught our attention. We applied to be part of the Beta and as soon as it came out we started using it, started experimenting it and very quickly within a couple of hours we could see this is going to solve some problems for us. Given that, we set about trying to do things with Workers.

The first one was geo-targeting. As I said, our websites rank very well in Google, but usually that is the English version of the site, so one of our websites is gambling.com and the homepage is tailored for a UK audience so it features UK casinos, but let's say some guy from the US lands on gambling.com, well, that content is of no benefit to him because the prices are in pounds, not dollars. Let's say if someone from Italy lands on the site, well he may not even be able to read it because it's not Italian and the prices are in pounds instead of Euros, so we were losing a lot of traffic that was coming to the sites because content wasn't tailored for what they need, so we tried to solve this with Workers.

The way we did it is with Cloudflare, they give you the option of detecting the country of the request so we just created a simple Worker that checks incoming country. It's a two letter code. If we have a local version of the site, then we offer the user a redirect if they want it so. Let's give you a little example of what it looks like. On the left is page and you can see it's entirely English. Currency is pounds. If a guy comes in from Italy, that's of no benefit, but once we deployed Workers, we're now able to show a banner at the top of the page which if anyone that can't read it, it basically says we have a local version of the site, would you like to go there?

So, now when someone comes from another country and lands on our site, we can show them a message, offer them the option of going to a more relevant version for them. The benefits of this is that we're not losing traffic and our bounce rate is not going up because people are actually staying on the site when they come and also users are getting what they want, so we're providing a better user experience via Workers. Second use case is restricting access to content, so I know some companies have very high requirements when it comes to security, protecting their systems, but sometimes military grade security isn't really required and I'll give an example. I submitted a guest post on the Cloudflare blog and while that was still in draft it was available on the internet. It was cloudflare.com/p/some random string. The content was nowhere near finished, there were spelling mistakes and everything, but people were able to access that before it was ready. Some people actually started linking to that article from within our company because they saw that they got mentioned and started promoting it that we got mentioned on the Cloudflare blog and it was nowhere near ready. It was just open to the public and that's something that we would have occasionally like.

Let's say, for example, we have a guest author who contributes an article and maybe we want to just put it online for that guest author to approve before we make it available to the public. What you can do with Workers is you can just say If there's a parameter and the URL allow access to the content. If it's not there, block them. Here's what it looks like. Without Workers, everyone can access the page. With Workers, we can block people unless they're either on to the end of URL?preview=true. Just a simple way of firstly preventing people seeing content before they should and secondly preventing it being crawled by Google before we want it to be crawlable. The benefits are that it was extremely simple to implement and it took 10 minutes. It's really easy for other people to understand how they actually need to manipulate the URL to get to the page.

Third use case is A/B testing. We like to experiment with lots of things like changing layouts and stuff and we use A/B testing tools to do that. There are some very good ones out there, but the problem is there's always a JavaScript that you add to the page. Then, once the user loads the website for briefs, they can for a moment see the original version and then the variant will snap into place. I think the correct term is flicker. It's a really bad experience in something we try hard to prevent, but we still need to A/B test to get the insights that will provide.

Without Workers, users would see something like this. They would see the original and then the variant would snap into place, but with Workers we can detect the response coming in, manipulate the page, load the variant and send it all back to the user with the variant already in place so there's no snap, user is not trying to click on something that is going to disappear afterwards. It's just a much better experience. We still get all the benefits of A/B testing and the data that it gathers for us. Then final one which is not something we're doing in production yet, but it's something we're working on. We have this website called footballscores.com. As you can imagine, it shows live football scores from around the world and it's currently running. It's a traditional server rendered site. We don't like that because it's not scalable and we really like doing static websites. With a static website, we can't show live scores. We're finding a way to make this a static website that is dynamic using Workers. When a user loads the page the Workerscript will go off to an API, get the score data and bring it back into the page. When the page loads, the user will see what's on the right. The scores already loaded.

Now, of course, we could do this without workers by firing a JavaScript request after the page loads, but then users would see this loading indicator and then the content would snap in. As I said, we don't like things changing after the page loads. With Workers we will be able to fetch data from an API, inject it into the page, and users will have it loading incredibly fast because it's a static site and it's served from an edge close to them.

Those are our use cases. The roadblocks that Workers removed for us is that it allowed us to make our static sites dynamic. We avoided having to undertake a major architecture change to server rendered sites or some other technology and it solved our problem a lot quicker than we expected. That's not to say we didn't look at alternatives. The first one we looked at was Lambda. We investigated that. We also looked at Netlify which is a platform for creating static sites which actually integrates with Lambda closely and then the Google and Microsoft offerings.

What we found was that the implementation of workers was incredibly simple. In the back end, in the Cloudflare dashboard before they integrated with the serverless framework we could just click Workers launch, you get a little window and you could be coding in a couple of seconds and finish the Worker in 10 minutes and deployed to your production website with no problems. Now, obviously with that flexibility comes great responsibility because you could easily leave a character out of place and take the site down. We have to be very careful with it, but it does give us the ability to do things very fast. That's why we went for Workers over any of the other offerings out there.

As I said, it's easy to implement at the top of our architecture, no additional cost, something like $5 a month or something. Nothing too major, but also the speed. As from the Cloudflare blog, we can see that it's faster than Lambda, it's faster than the others. Speed is, as I said, one of the number one things we're concerned with. If there's any possible way to see it have a millisecond, we will do that and we'll choose the right tool for the job. Given Workers are recent developments, they're not perfect and there are some things that we think would really help them develop and become more of a mainstream technology, that's access to more Workerscripts within the back end. Right now, we can only access one. If we could access multiple, it would be great. Having all of the code for a site in one file it's hard to navigate.

More documentation will be good when that comes. Recipes, so just snippets of code that you can use to do just regular things without having to write it all from scratch. Integrations with other tools, for example, an integration with Google Firebase would be great. If we wanted to integrate with an API, we have to do that all manually in JavaScript. It would be cool if there are some common tools that people want to integrate with that, we could just do that but with the click of a button. Also, we would really love to see your databases on the edge with any of our sites. If they need to get data, the Worker is still going to have to send a request back to an origin server, which could be on the other side of the world so the benefit of Workers is somewhat lost. If we could get together database closer to the user without having to have database servers all over the world, I think we would have our site as fast as they could possibly get. Those are some things that we think would really help along with some extra logging so we can see exactly what's going on.

That's it.

[END OF AUDIO]

October 2nd, 2018, 6:00pm-9:00pmIn partnership with ATX Serverless MeetupLocation: Downtown Austin

View Event Details & Register Here »

October 11th, 2018, 6:30pm-8:30pmLocation: Cloudflare Singapore - 120 Robinson Road, #15-01 (McCallum Street) Singapore 068913

View Event Details & Register Here »

October 15th, 2018, 6:30pm-8:30pmLocation: Tank Stream Labs - Bridge Street, Level 3, 17 - 19 Bridge St Sydney, NSW 2000 Australia

View Event Details & Register Here »

October 17th, 2018, 6:30pm-8:30pmLocation: Downtown Melbourne

View Event Details & Register Here »

Listen to what Kenton had to say about serverless technology in this twenty two minute podcast here.

Here's the transcript of the podcast as well:

Brian Douglas: Welcome to another installment of JAMstack Radio. In the room I've got Kenton Varda from Cloudflare.

Kenton Varda: Thanks for having me.

Brian: Thanks for coming all the way across San Francisco to chat with me in person. I'm curious who Kenton is, but I'm also curious what Cloudflare is. Can you answer both questions? Let's start with, "Who is Kenton?"

Kenton: I'm an engineer. I'm the architect of Cloudflare Workers. In a past life I worked for Google for several years. I was once known as the "protocol buffers person," I was the one who open sourced that. And I founded a company called Sandstorm that was later acquired by Cloudflare.

Brian: I'm familiar. I remember Sandstorm. Well, I remember the name and I vaguely remember that the acquisition happened. Interesting. You founded Sandstorm, you said?

Kenton: Yep. Jade Wang and I.

Brian: OK, yeah. I know Jade. I met Jade not too long ago. But that's a lot of inside baseball. How about Cloudflare? Now you're a part of Cloudflare. What is that thing?

Kenton: We have computers in 151 locations today and rapidly expanding, thousands of locations in the future. And we let you take that and put that network in front of your website in order to provide a few things. One is it's a large HTTP cache. We can cache your static content at the "edge." We call it the edge. The locations close to the end user, so that they can receive that content quickly.

We have a web application firewall which blocks malicious traffic, we have DDoS protection. We have absorbed the largest DDoS attacks in the world without any trouble and a whole bunch of other features. There's a long list of things that are implemented as a proxy in these locations before the requests go to your "origin server," as we call it.

Brian: OK, cool. And you folks have all these locations, do you own servers? Are you building these things out?

Kenton: Yes. We build the hardware and we send them to a variety of different types of locations. Sometimes it's ISPs that want to have our machines there, so they can serve their customers faster and use less bandwidth upstream. Sometimes it's data centers. It's a variety.

Brian: Cool. So, I'm curious. Your background is in a lot of infrastructure, too? Coming from Sandstorm, and now Cloudflare?

Kenton: Yep. And at Google. I've always done a little infrastructure. Search infrastructure at Google, access control infrastructure, key management. Lots of things.

Brian: Which makes sense on why you mentioned you're now "principal architect."

Kenton: We don't have titles.

Brian: You don't have titles? OK. I was going to ask if there is a Vice Principal Architect at all.

Kenton: I've taken to calling myself the architect of Cloudflare Workers, descriptively. When Sandstorm was acquired by Cloudflare in March of 2017, we came in and I was told, "We'd like to find a way to let people run code on our servers securely and quickly. But we don't know how to do it. What do you think?" And so I started that project, and built it out, and exactly a year after I joined we launched it on March 13 of this year.

Brian: Nice! Congratulations. This is the exact reason why I had you come on. Because Cloudflare Workers is something that I was aware of in the alpha or beta phase when it first was mentioned. I played around with the trial.

I want you to explain Cloudflare Workers, but also before you do that I want to explain what I did. Which is very trivial. Workers sit on the edge, and I made a Worker to change the word "cloud" to "butt."

Kenton: Classic.

Brian: It's very classic because the site that I was testing it on was Cloudflare.com. Whatever it replaced was pretty hilarious. I showed everybody in Slack, and then I moved on and never thought of it, until recently. Could you explain what Cloudflare Workers are?

Kenton: While you were working with the preview, which lets you see what your Worker would do to any random site. But normally you'd run these on your own site. Cloudflare Worker is a piece of JavaScript that you write that can receive HTTP requests that are destined for your domain, but receives them on Cloudflare servers at the edge, close to the end user.

It can run arbitrary code there. It can forward the request on to your origin, or it can decide to respond directly, or you can even make a variety of outbound requests to third-party APIs and do whatever you want.

HTTP in, HTTP out, arbitrary code in between.

Brian: Are there limitations to the JavaScript? Because when you say you could run JavaScript on the edge or on Cloudflare servers, this sounds dangerous. But you also prefaced this too, as well as the security aspect of it. People want to have that. How do you solve that problem?

Kenton: Right. This is the reason why it is JavaScript. We have a lot of customers and they all want to run their code in every location of ours. We need to make sure that we can run lots and lots of different scripts but not allow them to interfere with each other. Each one has to be securely sandboxed.

There's a lot of technologies out there for doing that. But the one that has received by far the most scrutiny, and the most real-world battle testing over the years, would be the V8 JavaScript engine from Google Chrome. We took that and embedded it in a new server environment written in C++ from scratch.

We didn't use Node.js because Node.js is not a sandbox. Not intended for this scenario. So we built something new. The JavaScript runs in a normal JavaScript sandbox and it is limited to an API that only lets it receive HTTP requests, and send HTTP requests to the internet. It does not allow it to see the local file system or interfere with anything else that might be running on that machine.

Brian: OK. Can we talk about use cases for Cloudflare Workers? What would somebody besides somebody like myself who spent all that time writing a joke app. Or Worker, rather. What are use cases you can do on the edge and write JavaScript in?

Kenton: Well, it's arbitrary code. There is infinite use cases. But I can tell you some common ones.

Some people just need to do some silly rewrite of some headers because it's easier to push something to Cloudflare than it is to update their own origin servers.

When you write the script and you submit it through the Cloudflare UI, it is deployed globally in 30 seconds. That's it. Boom, it's done. So that's an easy way to get things done, but it's the less interesting use case.

More interesting is you can do things like route requests to say, you're hosting your website out of S3 or Google cloud storage. You can write a Worker that fetches the content from there and then serves it as your website, and not actually have an origin server.

Other things people like is to optimize their usage of Cloudflare's cache. Historically an HTTP cache is a very fixed-function thing. You can't serve cache content but also have it be personalized. So say you're on a news site, and people have to log in because it's paid content, and then you want to display the site to them but at the top you want to say, "Hi. You're logged in as..." whoever.

Your content on a news site is very cacheable. But all of a sudden it can't be cached anymore because you're personalizing it. Well, you can do that personalization in a Worker after it's already come out of cache at the edge, and therefore serve your site much faster and use much less bandwidth.

But going beyond that, we've had people do HTML template rendering darkly at the edge based on API requests. That will save a lot of bandwidth.

Brian: That's a common use case for Apache servers where you'd take the JavaScript cookie and check to see who you are, where you came from and maybe even your location. And then be able to decide what to render based on the user. It sounds like something super complicated that was used very heavily with servers, and now you can just do it on Cloudflare's site.

Kenton: Or A/B testing. That's another thing that doesn't play well with caches, because you're serving different people different content for the same URL. You can implement that in a Worker now and you can take advantage of the cache.

Brian: Before we started recording I mentioned I had seen a talk at Apollo from the product manager for the team, which I escaped the name--

Kenton: Jonathan Bruce.

Brian: Jonathan, yes. He explained and he went through a couple of use case examples, and I saw A/B testing is one of them as well. It's nice to see a lot of this work move away from the servers. Not that they're trivial, but it sounds like it's an easier approach to do.

Kenton: Yes. Speaking of Apollo, over time we're seeing these use cases get more and more complicated. People started out doing very simple things. But Apollo is a great case. They've taken the Apollo GraphQL, they call it Apollo Server, it's a gateway for GraphQL.

Your GraphQL queries go in, and then it federates out to your Rest endpoints behind that.

They've managed to run the whole thing in a Worker. Which means now that can run on Cloudflare's "edge" and take advantage of the cache, which previously GraphQL queries generally aren't cacheable. Because they're all post requests and often each one's a little bit different and not canonicalized. And now you can fix that with code running at the edge.

Brian: Sorry to zoom back, because I have a lot of experience with Apollo and GraphQL as well. Is that what Apollo is doing personally? Or is this the preferred way for them to cache GraphQL queries when they're using Apollo Server?

Kenton: They are working on a version of Apollo Server that runs at the edge.

Brian: OK.

Kenton: It's not released yet. But soon.

Brian: I need to have them on for a follow-up conversation. They've been on this podcast quite a few episodes ago, so I definitely want to have them talk more about what they're doing on the server side, which is really cool.

You mentioned Google and you mentioned your experience, so it sounds like you've been working on the web and within servers for a while. I'm curious if we could take time to zoom out. You're working on Cloudflare Workers. What's your thought on where the web's going moving forward?

The reason we do this podcast, JAMstack Radio which is JavaScript APIs and markup, is because I personally think there's a shift of a lot of the processing and a lot of the work moving towards front end.

I would consider having Cloudflare own Workers as part of something I don't have to worry about, so I don't have to deal with it, it's an API. Do you see a shift of a lot of major companies using something like a Worker instead of running their own servers going forward?

Kenton: Serverless has been a popular term lately.

Brian: Very popular.

Kenton: People have realized that it's a lot of effort to maintain a server that's not really going to anything useful. You would prefer it to be just writing your code that's specific to your application, and not thinking about, "How do I initialize my server?" or, "What dependencies do I need to build in here?" And there has been this shift towards something called serverless.

My colleague at Cloudflare, Zack Bloom, likes to talk about going a step beyond that to what we call "originless." In serverless, like with Amazon Lambda, you still choose a location in the world where you or your function is running.

You're no longer managing individual servers, but you still have an origin. Typically US East one in Virginia. What I would like to see is, you don't think about where your code runs at all.

You write code and it just runs everywhere. That's what we call "originless," and that's what Cloudflare does.

Because when you deploy code to Cloudflare you do not choose which of our 151 locations it runs in, it is deployed to all of them and we'll run in whichever one receives the request from the users. Whichever one is closest to the user.

And it's not just about being close to the user, but also if you have code that interacts heavily with a particular API. Say the Stripe API, or the Twilio API. It would be great if that code could automatically run next to the servers that are implementing that API without you having to think about that.

I should not decide that my servers are going to run in Virginia, when my servers are talking to people who I don't even know where they are. So that's where I'd like to see it. People have been talking a lot about "edge" compute lately. We consider Workers to be an "edge" compute platform.

But it's funny, because Peter Levine at Andreessen Horowitz said, "The cloud is dead. The new thing is edge compute." But it seems to me that this idea that your code just runs everywhere is what the cloud was always supposed to be in the first place. That's what the metaphor meant. It's not in a specific place, it's everywhere. To me, we're finally getting there.

Brian: "Originless." I'm not sure if it's going to pick up as much steam as serverless. I think that one's got really good feet inside the marketing jaws of tech. But I like "originless," I like the fact that you can ship code and not have to worry about it. Me personally, I'm a tinkerer.

I ship a lot of JavaScript as of late, in the last couple years. I don't want to have to deal with the problems and the headaches of trying to manage my own thing. Just for example, I just cloned a project that happened to my SQL as a dependency. I had the 'brew install that thing and for whatever reason it still didn't work. Dependencies just weren't jiving together. It was a Ruby project, so they weren't jiving together.

But I shouldn't have to think about this as someone coming in four years later down the road trying to commit to this project. I just want to ship code.

I like the fact that I don't have to worry about things like caching and managing my headers and stuff like that. If I can tap into all that tech talent at Cloudflare, and people who are building these cool projects to complete that for me, and pay a small fee, hopefully.Actually, that's a good question. Cloudflare Workers, is it an add-on feature once I have a Cloudflare account. How do I get access to this?

Kenton: It's available to all Cloudflare accounts. The pricing is 50 cents per million requests handled with a minimum of 5 per month. You pay 5, you get your first 10 million, then 50 cents per million after that.

Brian: OK. I'm really excited about the idea of Cloudflare Workers. There's a lot of ideas that can be done. Is there any getting started guides, or tutorials people can get their feet wet with? With Cloudflare Workers?

Kenton: If you go to Developers.Cloudflare.com, or if you just go to CloudflareWorkers.com there's the preview service. The "fiddle," we call it. It's kind of like JSFiddle. You write some code, that's a Worker, and then you see in real time its effect on any web page that you choose. You can go there and try it out. You don't need a Cloudflare account and you don't need to sign in.

Brian: Oh, very cool. Awesome. I'm going to hopefully tinker with that again and build something a little nicer than what I already touched with the Workers. Excited to try that out. Curious, is there anything else Cloudflare is working on in the upcoming future? I know you're probably super focused on Cloudflare Workers so you don't really have the whole roadmap.

Kenton: Well, we're working on lots of things. My next goal with Workers is to introduce some storage. There's not a whole lot specific that I can say about that yet, but the challenge is interesting because we have a network of, as I said, over 150 locations today. In the next few years we expect to exponentially grow that.We expect to have machines in every cell tower, more or less. And we want a storage system that can actually take advantage of that. A storage system where each user's data, if you've built a service on Cloudflare and you store data for users that they interact with, each user's data should live at the Cloudflare location that's closest to that user so that they can interact with it with minimal latency.But there aren't a lot of storage technology out there that can scale to hundreds of nodes, much less thousands of nodes automatically today. It's a new and interesting challenge that I'm working on.

Brian: Cool. Exciting. I'm probably going to keep an eye out on the cloud for a blog, hopefully you're keeping that up to date. I look forward to whenever that gets launched or previewed. I'm going to transition us to JAM picks. I think we had a really awesome conversation about Cloudflare Workers.

These are going to be JAM picks, anything that keeps you jamming, keeps you going. Music picks, we've had a lot of those in the past. Food and tech picks as well. But I will go first.

My pick is Pinterest. Which sounds very weird to say this out loud. We had Zach on here talking about Pinterest and how they're trying to shift towards more of a male demographic, which listeners, if you didn't know I identify as male. I've been using Pinterest mainly because I'm expecting a child.

I'm not picking a bunch of baby stuff and putting on a board. I'm picking a lot of recipes. I find that on Pinterest, if I type in something I have in my cabinet I can get a bunch of recipes for one ingredient, and it's been super useful. Because I'm going to have some leave that I'm going to be taking off.

So I want to be Mr. Mom, hopefully. I'm going to try to achieve that status and do a lot of cooking. I've been setting myself up to do a lot of Pinterest boarding. I'm not even sure if that's a thing, if that's what they call it.

My other pick is going to be meal planning. I really like cooking. I work from home a lot. I really like leveraging the idea of cooking. On top of that, I'm going to wrap in one more pick. I'm definitely going to be trying out Cloudflare Workers. I've been using a Dropbox Paper, so I have a list of all the ideas I want to ship of side projects. I have some coding goals that I have during that time.

So those are my three picks. Kenton, hopefully I stalled long enough that you have decided the things that you are jamming on.

Kenton: I commute up here from Palo Alto on Caltrain every day, which means I get a lot of time to play video games on my Nintendo Switch.

Brian: Oh, nice.

Kenton: And one of my favorites lately is an indie game called Celeste. It's what I would call an agility platformer. Lots of jumping off walls, boosting and 2D side scrolling. It is a lot of fun.

Brian: I have follow up questions about that. How long have you had your Switch?

Kenton: Since sometime last year. Probably about a year ago.

Brian: OK. So you're earlier on the bandwagon. No, actually you were probably a year into it. I'm curious, how do you enjoy the controller? Do you always play it connected? Or do you separate the controller?

Kenton: Yeah, I play it connected because I'm on the on the train, so I have to hold it.

Brian: I just think those little things that come off, those little joypad joystick things are just a little too small for my taste.

Kenton: I do have that problem. My hands get sore, especially from this game Celeste. I had a callus on my thumb when I finished playing it.

Brian: That's hard core.

Kenton: It's intense.

Brian: Either it's hard core or you have a super long commute.

Kenton: It's about 45 minutes. And then I'm going to say I just got back from vacation last week, where I flew to my hometown of Minneapolis, and I just have to talk up the amazing park system and bike trail system there. Because all I did all week was just bike around. There's hundreds of miles of paved, dedicated, bike trails. You don't have to go on streets, and it's just amazing and beautiful in the summer.

Brian: Nice. I didn't know that about Minneapolis. I know the whole, is it like, "10,000 lakes?"

Kenton: "Land of 10,000 Lakes" is Minnesota. It's probably more like 100,000 lakes. There's a lot of lakes.

Brian: And at least a few bike trails.

Kenton: Yes.

Brian: Awesome. Well, Kenton, thanks for coming on to talk about Cloudflare Workers and the awesome city of Minneapolis. Listeners, keep spreading the jam.

Want a Real World Serverless event in your city? Interested in sharing your stories and experience deploying serverless apps in production? Email community@cloudflare.com and let’s put something together.

Check out the event details and register through the Eventbrite links below.

Photo by Tim Foster / Unsplash

Sept 11th, 2018, 6:00pm-9:00pmIn partnership with Serverless MeetupLocation: Heavybit - 325 9th St, San Francisco, CA 94103

View Event Details & Register Here »

Photo by Robert Tudor / Unsplash

Sept 18th, 2018, 6:00pm-9:00pmLocation: Cloudflare London - 25 Lavington St, Second floor SE1 0NZ London

View Event Details & Register Here »

Photo by Cosmic Timetraveler / Unsplash

October 2nd, 2018, 6:00pm-9:00pmIn partnership with ATX Serverless MeetupLocation: Downtown Austin

View Event Details & Register Here »

Photo by Jacob Peters-Lehm / Unsplash

October 11th, 2018, 6:30pm-8:30pmLocation: Cloudflare Singapore - 120 Robinson Road, #15-01 (McCallum Street) Singapore 068913

View Event Details & Register Here »

Photo by Simon Rae / Unsplash

October 15th, 2018, 6:30pm-8:30pmLocation: Tank Stream Labs - Bridge Street, Level 3, 17 - 19 Bridge St Sydney, NSW 2000 Australia

View Event Details & Register Here »

Photo by Kieren Andrews / Unsplash

October 17th, 2018, 6:00pm-8:00pmLocation: Hub Southern Cross, 696 Bourke St, Melbourne, VIC 3000

View Event Details & Register Here »

With Pride month now in our collective rearview mirror for 2018, I wanted to share what some of us have been up to at Cloudflare. We're so proud that, in the last 8 months, we've formed a LGBTQIA+ Employee Resource Group (ERG) called Proudflare. We've launched chapters and monthly activities in each of our primary locations: San Francisco, London, Singapore, and Austin. This month, we came out in force! We transformed our company's social profiles, wrapped our HQ building in rainbow window decals, highlighted several non-profits we support, and threw a heck of an inaugural Pride Celebration.

We’re a very young group — just 8 months old — but we have big plans. Check out some of our activities and future plans, follow us on social media, and consider starting an ERG at your company too.

On my first day at Cloudflare in October, 2017, I logged into Hipchat and searched LGBTQ. Fortunately for me, there was a "LGBT at Cloudflare" chat room already created, and I started establishing connections right away. I found that there had been a couple of informal group outings, but there was no regular activity, sharing of resources, nor an official group. Proudflare was born that day, and the ball kept rolling.

Our first official event was a Lunch & Discussion in December. We had a gathering of eleven Cloudflare employees around lunch to discuss articles about LGBTQIA+ issues in tech. We unanimously agreed to continue holding events like this and form an ERG.

Here are the first two articles we discussed:

• Lesbians' Wage Premium: Girl Power

• Gay Men Used to Earn Less than Straight Men; Now They Earn More

Once we established a regular structure of events, we started introducing Proudflare to our other locations. In March, we held our first SF mixer with LGBTQIA+ ERGs from other tech companies. We decided we wanted to fully announce the group to the whole company during Pride month, so we sent out an email to the entire company introducing Proudflare and gave presentations at our All Hands meeting.

All of Cloudflare welcomed us and embraced us as their first ERG.

Our Austin chapter held its second Lunch & Discussion event, where Cloudflare employees got together to discuss how to write more inclusive job descriptions. They also discussed ideas for a Pride celebration and announced the first Proudflare service day, where the group will take time off to volunteer at a LGBTQIA+ youth organization.

The London chapter held its third Lunch & Discussion event, where the group brainstormed better processes for welcoming new employees to the London office, supporting them with resources, and making Proudflare a more salient part of the office culture. They also began planning their first Pride Celebration, which will take place after London Pride this July.

The Singapore chapter held its first event this month and was overwhelmed with support. A group of twenty-five Cloudflarians gathered to learn how they may make the Singapore office inclusive and supportive of LGBTQIA+ individuals. They discussed articles about LGBTQIA+ issues in Singapore and started planning their first external event in support of Pink Dot's PinkFest.

At our headquarters, where roughly half of our global employee base is located, we felt it important to really make an impact. We wrapped our SOMA offices with rainbow window decals, organized a contingent to march with Bluegrass Pride in the parade, and renamed Cloudflare to "Proudflare".

We also held a Lunch & Discussion event where we shared stories of what Pride means to each of us and hosted our inaugural Pride Celebration, where we welcomed one hundred sixty people into our space to learn about nonprofits we believe in and celebrate with us.

Here are the nonprofits we highlighted:

The Trevor Project: Founded in 1998 by the creators of the Academy Award®-winning short film TREVOR, The Trevor Project is the leading national organization providing crisis intervention and suicide prevention services to lesbian, gay, bisexual, transgender, and questioning (LGBTQ) young people ages 13–24.

We're honored to support the Trevor Project with Cloudflare's Project Galileo. Organizations working on behalf of the arts, human rights, civil society, or democracy, can apply for Project Galileo to get Cloudflare’s highest level of protection for free.

Rainbow Railroad: In response to the confirmed reports of abductions, detentions, enforced disappearances, torture, and deaths targeting over 200 gay and bisexual men in Chechnya, Rainbow Railroad immediately went into action to assist those in danger. Rainbow Railroad has been working closely with the Russian LGBT Network, a non-governmental organization currently leading the campaign to rescue those facing danger in Chechnya.

Project Open House: Openhouse enables San Francisco Bay Area LGBT seniors to overcome the unique challenges they face as they age by providing housing, direct services, and community programs. As a result, they have reduced isolation and empowered LGBT seniors to improve their overall health, well-being, and economic security.

We're a new ERG and we've come a long way in a short amount of time, but we have a lot more planned. Here are some projects we're currently working on:

• Hosting an event in support of Pink Dot in Singapore

• Hosting Pride Celebration events in Austin

• Inserting a presentation about inclusion and ERGs in our new hire orientation

• Supporting ally skills trainings for employees

• Working with recruiting on writing inclusive job descriptions

• Advising human resources on which benefits packages are most LGBTQIA+ friendly

• Establishing a framework for LGBTQIA+ diversity data collection and reporting with our people team

• Publishing all Proudflare-related resources in a Wiki for all Cloudflare employees to access easily

I suggest starting an employee resource group at your company. Whether it be focused on LGBTQIA+, women, people of color, parents, or other underserved populations in tech, conversations about inclusion and community-building make for a better work atmosphere. Here are some beginning resources I used.

Let's make our industry a better, more inclusive place for all.

Also, follow us on social media and join us at our next events.

• Proudflare on Facebook

• Proudflare on Twitter

• Proudflare on Instagram

<3

Proudflare

Photo by Patrick Tomasso / Unsplash

Are you based in Boston, London, or New York? There's a lot going on this month from the London Internet Summit to Developer Week New York and additional meetups in Boston and New York. Drop by our events and connect with the Cloudflare community.

Tuesday, June 12: 6:00 pm - 8:00 pm

Location: Drift - 222 Berkley St, 6th Floor Boston, MA 02116

Join us at Drift HQ for a panel discussion on user experience, developer experience, and integration, featuring Elias Torres from Drift and Connor Peshek and Ollie Hsieh from Cloudflare.

The panelists will speak about their experiences developing user-facing applications, best practices they learned in the process, the integration of the Drift app and the Cloudflare Apps platform, and future platform features.

View Event Details & Register Here »

Thursday, June 14: 9:00 am - 6:00 pm

Location: The Tobacco Dock - Wapping Ln, St Katharine's & Wapping, London E1W 2SF

The Internet Summit is focused on how the Internet will evolve over the next five years. The day-long event will feature a series of fireside chats, intimate panel discussions, and lively conversations from some of the brightest thought leaders, executives, entrepreneurs, researchers, and operators.

We don’t spend much time talking about Cloudflare at the Internet Summit but instead facilitate discussions with the people who inspire or challenge us.

Register & See Videos from Last Year Here »

Tuesday, June 19: 5:45 pm - 7:45 pm

Location: Ramona - 113 Franklin Street, Brooklyn, NY 11222

Developer Experience & User Experience: Tried & True Methods for Improving Both

Join us for a panel discussion on user experience, developer experience, and methods of improving both, featuring Jade Wang, Jess Rosenberg, Connor Peshek and Ollie Hsieh from Cloudflare, and moderated by Andrew Fitch from Cloudflare.

Our panelists will speak about their experiences developing user-facing applications, developer-facing tools, best practices they learned in the process, and future platform features.

View Event Details & Register Here »

Wednesday, June 20: 10:00 am - 10:50 am

Location: Brooklyn Expo Center - 72 Noble St, Brooklyn, NY 11222

If you happen to be attending Developer Week New York, check out Jade Wang’s conference talk as well.

About 10% of all Internet requests flow through Cloudflare’s network. In addition to providing performance and security for over 7 million websites, Cloudflare exposes our entire infrastructure via a standard programmatic interface.

In this talk, Jade will cover:

• Improving mobile app performance, especially over spotty network connections (mobile SDK)

• Access control at the edge (Cloudflare Access)

• How to write JavaScript that runs on Cloudflare’s edge (Cloudflare Workers)

• Write plugins that other people can install onto their websites (Cloudflare Apps)

• If you could leverage 151+ data centers worldwide, what would you build?

View Event Details & Register Here »

We'll hope to meet you soon.