At Signal Sciences, we’re used to iterating and changing our product based on constant feedback from our customers. So when they told us they didn’t have a way to install our software on their servers, we jumped into action. We launched a product that would solve all of these problems by letting our customers deploy Signal Sciences from the cloud––and we did it all in only 2 weeks.

We call this offering Cloud WAF, and it was quite the journey to launch. We’ll go into all of the gritty details of how we got to the finish line, but first we’ll cover how Cloud WAF fits into our architecture.

How Cloud WAF fits into our cloud native tech stack

All of Signal Sciences’ infrastructure runs in the AWS public cloud with the exception of several downloadable components (called agents and modules) that customers can deploy on their own infrastructure. We’ve been working toward zero self-hosted services for everything from our build pipeline to our backend datastores. This is great because it allows us to focus our resources on what makes us unique––application security and customer experiences––instead of commodity infrastructure and plumbing.

Our approach also allowed us to have a user perspective instead of a service provider perspective about cloud infrastructure. Staying at the forefront of DevOps trends like Envoy, Istio, short-lived containers, service mesh, and serverless within our own infrastructure allows us to have the same perspective as our customers. As we build our own tools internally, we’re able to expose many of them externally for customer use.

When we started the process of hosting and managing agents in the cloud for our customers, performance, latency, and uptime became more critical than ever. Fortunately, we’ve built our agents to be self-monitoring from day one. We already provide detailed dashboards to our customers around both our agent’s performance as well as the server or container they’re running on. We also let customers set performance-related thresholds to trigger agent alerts.

Our agents’ existing self-monitoring capabilities gave us the visibility we needed in order to test Cloud WAF with confidence.

The possibilities of Cloud WAF had us so excited that we were the first people to use it. Since March, all of our customer dashboards and APIs have been protected using our Cloud WAF offering. Protecting our own product with Cloud WAF was the best way for us to build confidence in its potential for our customers.

How we built Cloud WAF so fast

To build Cloud WAF in under 2 weeks, we self-organized into a cross functional agile team to get a Proof of Concept (PoC) up and running. This agile team consisted of a product manager, software engineers, technical operations engineers, product marketing, our compliance team lead, and sales engineers. Our team organized around a Kanban process using twice a day standups to ensure that we could make as many rapid course corrections as possible.

Since our culture is all about a highly iterative approach to building product, we ruthlessly prioritized to quickly deliver a working MVP. Having a cross-functional team assembled meant we’d have a wide range of perspectives represented to help make smart decisions fast. Plus, we had a lot of fun doing it.

Our Ops team is committed to managing infrastructure as code, so they make heavy use of Terraform for deployment, as well as Fargate for auto-scaling. Our existing Terraform configurations allowed us to build a template for what our Cloud WAF deployment would look like so we could ensure that our deployment and provisioning processes will be repeatable and scalable as our customer base grows.

One of the new challenges we encountered while building Cloud WAF was SSL cert management. In a model where we are hosting the agent for customers and sitting in front of their HTTP traffic, we have to:

• Receive encrypted requests
• Decrypt them
• Pass them to our agent for inspection
• Then re-encrypt the traffic before passing it on to origin

Being security-forward in all our system design, we had to be thoughtful around how to manage private and public certs. Even on an iterative, highly agile project, it’s important to identify high-risk/reward areas that need a lot of thought and attention up front. Sometimes you can ship fast and learn; other things you need to get right the first time.

We launched! Then what?

After we launched Cloud WAF we’ve seen significant demand in the market. The product management team tracked this through metrics including:

• Top of funnel metrics like MQLs, SQLs, from Hubspot and Salesforce
• Product adoption and engagement metrics from our own internal instrumentation and Google Analytics
• Technical performance metrics through real-time logging and dashboarding tools like Elasticsearch, Logstash, Kibana, and Datadog

In addition to analyzing key metrics, we also listen to our customers who have adopted our Cloud WAF. Understanding how our customers are leveraging Cloud WAF will help us evolve our agent in different ways, to optimize performance as we scale.