My path to Deepfence starts way back in 2001 when I moved to Raleigh, North Carolina. I left a gig I had taken in Atlanta after college to move back to NC to be closer to family and friends. I had saved up enough money to last for maybe three months without a job, but finding a job was priority number one. And I only had eyes for one company — Red Hat.
I first learned of Red Hat during my studies at UNC Kenan-Flagler Business School. The way the faculty taught then is still displayed on the website today: “Make an impact for a better world.” Red Hat had come up in one of my business classes for three reasons: the company was a local startup (rare at the time), it was receiving awards for being the best place to work because of its company culture (also rare), and it was backing an open source project called Linux (wtf?!). At the time, it was my experience that most people did not know what open source was nor did they know what Linux was (myself included), but the ideas of working in a kickass culture and doing things differently had me hooked.
In late August 2001, I applied to a customer service job at Red Hat and had an interview scheduled for mid September. On or about September 11, for obvious reasons if you know the history of that date, I got a call from the recruiter saying that all interviews are paused indefinitely, but that they would call me if and when the job I applied for opened up again. I ended up being called in to interview a few more times and in October 2002 I officially joined as a customer service rep (using Red Hat Linux 7.3 on the desktop if you can believe it, before the distro split into RHEL and Fedora). For the next 12 years, I had a front row seat in helping build and shape the company that was then and still remains the world’s open source leader.
I worked on so many cool projects (too many to describe), but at the heart of everything was open source — we built, championed, and marketed open source products, while also building an open source culture that is built on the open source way. Open source runned so deep that we even open sourced Red Hat’s strategic planning process because open sourcing all the things, software and not software, was how we operated. (If you read the linked article, you’ll see I made it into the credits!) Turns out, over time open source has become pretty standard, and almost my entire career has been in open source. (And I’m very proud of this, even more recently I signed up as a student at the Berkeley Coding Bootcamp and I’ve been building and publishing some code and apps on GitHub, which I think gives me even more open source cred!)
I left Red Hat after an exhilarating few years of helping build the Red Hat OpenShift business unit, working for inspiring leaders and alongside very passionate and talented evangelists. It was clear then and still is today: cloud is the future. And by extension, cloud native is the future. I saw it on the OpenShift team, and I saw it in my next gig at NGINX where I had a front row seat in seeing just how important cloud and cloud native technologies are to organizations of all kinds across all industries.
Two big reasons why enterprises choose NGINX (and there are many more) are for its unmatched performance and for software based load balancing. Performance is essential for cloud based businesses where effortlessly handling massive traffic spikes is part of doing business and where there is no tolerance for latency. And software is required over hardware because, as we would say, “you can’t take your hardware load balancer with you to the cloud.”
As a marketer, I had the pleasure of working with customers including Snowflake, Groupon, Cloudflare, BigCommerce, IgnitionOne, Wix, and MuleSoft to share their success stories with NGINX. An overall theme emerged: modern businesses need modern cloud native solutions that make it easier for them to build and run their applications at scale, not limit them or slow them down.
After NGINX, I eventually made my way over to Yugabyte. Yugabyte is building the open source cloud native distributed SQL database for mission-critical applications, called YugabyteDB. In the same way you can’t take your hardware load balancer to the cloud, you can’t take your legacy SQL databases to the cloud either. Legacy databases were built before the cloud was a thing. Karthik Ranganathan, Co-Founder and CTO at Yugabyte said in an article, “SQL has been the de facto language for relational databases (aka RDBMS) for decades and decades. However, the original SQL databases Oracle, PostgreSQL and MySQL are single-node SQL solutions and are unable to distribute data and queries across multiple instances automatically to provide high availability and scale.”
But, modern businesses do need to distribute data and queries automatically within or across zones, regions, clouds, and data centers, and they do need high availability and scale. Thus the case was made for the creation of YugabyteDB. You can learn more about why the world needs the YugabyteDB open source, cloud native distributed SQL database here in this blog post.
As a marketer at Yugabyte, again I had the pleasure of working with customers including Xignite, Admiral, Voiceland, Justuno, and Manetu to share their success stories on why YugabyteDB is their database of choice. Again an overall theme emerged: Whether you’re already in the cloud or moving to the cloud like this Fortune 500 customer, you need modern cloud native solutions that make it easier for you to meet all your business and technical goals, without limitations that slow you down. And in some scenarios, including Xignite and Manetu, YugabyteDB has even made possible new use cases that were not previously possible with other databases. Modern cloud native tools unlock true innovation — so cool!
For part of my career, I worked at Okta, a company that delivers one trusted platform to secure every identity. My role was helping the very talented team that was building out the Okta Integration Network. Okta itself is a security-focused company, and I had the benefit of working alongside partnership and integration builders on many security-related integrations, including: network security integrations, security analytics integrations, cloud access security broker (CASB) integrations, the identity governance and administration integration, privileged access management (PAM), endpoint security, bot detection, and email security. These partners represent the best of the best when it comes to security, and there are so many components in a corporate environment that need protecting, that it takes many different types of security products and vendors working together to secure all the things.
While at Okta, I became a big believer in Zero Trust and the notion of shifting security left (a concept I first heard from Ivan which he later described in this blog post). Right around the time that I joined, Okta had announced the acquisition of ScaleFT. During my tenure I would have the pleasure of working with some members of the former ScaleFT team to put together integration related content around the Okta Advanced Server Access (ASA) product. More specifically, we published integration materials on using Okta + HashiCorp together to simplify and secure DevOps workflows, as well as using Okta ASA and AWS together to enable a Zero Trust security approach to secure cloud resources. This is truly fascinating stuff. Listening to Ivan and team describe how and why dynamic, single-use ephemeral client certificates are more secure than legacy methods was mind blowing. Needless to say, working at Okta helped me gain some understanding of and a deep respect for the security ecosystem more broadly.
I joined Deepfence for three main reasons. First, the technologies that the Deepfence team are working on combine open source, cloud native, and security all in one. What luck! I get to use my experiences in those three areas all wrapped up in my new role as Head of Marketing. I feel like I will be able to make impactful contributions to the team, our goals, and broader Deepfence community, as well as learn from others who are bringing their own unique skills and experiences to the team. Win win! You can visit the Deepfence website for more information on our open source and commercial offerings, and you can check out the open source tools on GitHub.
Next, a major reason for joining Deepfence is the people. Not all of the faces are yet on the website (I will work on fixing that :) ), but look at the strength of this world class team of passionate, smart af, interesting, and talented people. Sandeep has incredible motivation, which is very inspiring. Shyam shares my belief in working for a values based organization, and shared with me that Deepfence values transparency, approachability, and accountability. Those are values I also hold dear, and I look forward to living those values. Jess gets jazzed up at helping people build successful careers and do their best work. How awesome is that?! During the interview process I met a very talented group of Deepfence engineers, and it was clear that with only one Bachelor’s degree and only one Master’s degree (and zero PhD’s), I was bringing down the team’s average :P. And most recently, Owen, whom I worked with at NGINX, has also joined the Deepfence team. Owen and I worked on some cool projects at NGINX in the early days before I left, and I am beyond excited to do more cool stuff here at Deepfence alongside Owen and all.
Last, but not least, I joined Deepfence because of the tremendous opportunity ahead. Nearly every organization has an open source strategy, a cloud native strategy, and a security strategy. Bringing them together is not easy. Many enterprises are wrestling with questions like:
At Deepfence we are and will continue to build solutions that help development teams, operations teams, and security teams answer those questions and address precisely those issues. I’m excited to join the Deepfence team; it’s going to be an amazing journey ahead!
If you’d like to follow along, join us on Twitter, LinkedIn, and/or GitHub.
.png)