DEV Community: Snow Owl

Geo Routing for GDPR compliance made easy using reverse proxy as a service

Snow Owl — Sat, 11 Mar 2023 21:21:52 +0000

In this tutorial, we'll show you how to quickly and easily route based on geography, and how developers can handle these responsibilities without relying on specialists.

Background: Why geo-routing is necessary for your service today.

GDPR compliance, data sovereignty, and data residency are important for maintaining the privacy of users, but also require data to be routed and stored in their host countries or states. Europe has GDPR, Canada has Pipeta, and California now has CCPA.

This additional layer of complexity can quickly compound with other network requirements, especially with increasing traffic. This makes it more difficult and expensive to stay in compliance, without an adequately simple and robust solution.

Rules structure

Our rules structure will continue as follows:

If the user is coming from the US, route them to the United Airlines site.

If the user is coming from the Philippines, route them to the Philippine Air site.

Else, route the user to the Star Alliance site.

We are routing to common websites in this example, but for your application, you can route to a geo-specific version of your site (for multi-language support), or route user data uploads to a host that is located in the same country as the user for data sovereignty/residency compliance.

Using a reverse proxy

By using an edge-based reverse proxy that logs sufficient request information, you can ensure that traffic originating from a defined region never leaves that region. We will use Snow Owl, which is a SaaS-based reverse proxy.

Below is a schematic of how a reverse proxy sits between the user and the host architecture:

By using headers in the http request the have been logged by the reverse proxy, we can understand very quickly what location the user is coming from, and route them accordingly.

The rules below will apply to a specific domain or set of domains within the same service. Different users in different geographies navigating to the same domain will be routed to different endpoints based on the rules below.

Example rule #1: Route US traffic to United.com (no code & JSON)

Below are two representations of the same logic for routing US traffic to United.com. They are identical and can be used interchangeably.

Example rule 2: Route Philippines traffic to Philippine Air

{
  "condition": [
    {
      "field": "header:cf-ipcountry",
      "operator": "equal",
      "values": [
        "PH"
      ],
      "not": true
    }
  ],
  "action": [
    {
      "field": "hostname",
      "operator": "set",
      "values": [
        "philippineairlines.com"
      ]
    }
  ],
  "stopProcessing": true
}

Example 3: Else, route traffic to Star Alliance

If users come from a location that isn't the US or the Philippines, they will be defaulted to the Star Alliance site. Snow Owl, we offer simple routing rules that only need a field or two to be filled out, in this case, a Proxy URL rule.

Summary and Discussion

With the right system architecture and service, a quick set of simple rules can be set up enabling technical staff from entry level developers to network specialists to monitor and route their traffic. This makes it substantially easier to stay in compliance with data sovereignty/residency regulations, and manage network complexity much more robustly for higher site reliability and much lower costs + time.

For more information, check out:
SnowOwl.co
docs.snowowl.co

For Front End & Full Stack Devs: How to cut time spent on traffic management by up to 90%

Snow Owl — Wed, 15 Feb 2023 03:23:35 +0000

For those of you who have had to deal with microservice architectures, you know how quickly they can get exponentially more complex. Network deploys and configs can end up taking as much as 1/3 of developer time, which is already constrained. This translates directly into lost productivity, and lost money when failures make root cause analysis more difficult, and SLA uptime is lost.

Passing requests through an edge gateway allows for developers to view all http requests and API calls connected to the gateway within seconds or minutes of the request. Because the gateway sits at the edge, response times for 99+% of the internet are minimal.

In this tutorial, we'll show how easy can be to monitor request-level traffic using an edge gateway.

General Architecture

Here is an example of what the end result looks like. You can see that there is an API call that is returning a 400 error, and might need to be evaluated more closely.

Without an edge gateway, it could take hours or days to recognize the error, or worse, have a client call you in the middle of the night letting you know your SLA is being affected.

Updating the DNS records are often the only change to a project's architecture that are needed to set up an edge gateway:

Public-facing Domain -> Edge Gateway -> Web Server

Step 1: Connect the edge gateway to the web server

In the no/low code edge gateway, we'll use an auto-import function which auto-populates rules for monitoring the subdomain.

For simplicity and security's sake, we will use a subdomain (example.snowowl.co), which act in the place of a web server.

Step 2: Connect a public-facing domain to the edge gateway

A public facing domain is the domain that you want the public to navigate to, to to view the webserver's contents. In this example, we will use the domain: public.snwlgdaddy.com .

To connect public.snwlgdaddy.com to the edge gateway, we just need update the DNS records in domain's DNS registar (i.e. GoDaddy, AWS Route53, Google Domains, etc), using the information provided by the gateway.

Step 3: Test traffic and monitor your microservices/API calls

With the gateway connected between your public traffic and your webserver, the last thing that needs to be done is some testing to verify that the architecture is functional.

You can view snapshot summaries of your connected domains to quickly assess if there are spikes in failures, and where those failures might be coming from. Additionally, you can drill down to the individual request level for any http request or API call and view the request/response headers.

Snow Owl (SnowOwl.co) is a no/low code edge gateway that provides request-level monitoring, can install within 15 minutes, and allows for custom routing via a rules engine for a variety of use cases. Feel free to view our documentation at docs.snowowl.co and DM us for beta access.

Feedback on our Beta Landing Page? Request monitoring and routing for web developers

Snow Owl — Mon, 13 Feb 2023 19:21:24 +0000

Hi!

We just released the first version of our landing page and would love your candid feedback and discussion.

Our mission is to make NetOps 90% easier, so that web developers can easily do the work of network specialists and spend more time writing code.

Here's a link to our website: SnowOwl.co.

Thank you!

Snow Owl: request-level network observability and routing for microservices

Snow Owl — Thu, 05 Jan 2023 06:38:57 +0000

Hi everybody! 👋 We're glad to be here.

Snow Owl is a low/no-code network traffic management platform for http/api requests. We'll be sharing developer updates here.

(Psst! DM us if you want early access 👀)

https://snowowl.co

https://docs.snowowl.co