Experimenting with Lettering

Like most people I know, I try to learn new things on a regular basis. Recently, I've been studying design principles and digital illustration. I've been passionate about great usability for a long time, but I've never taken the time to study the visual side of design until the past few months.

Over the past week, I've rewatched Jessica Hische's Passion Projects talk on side projects and "procrastiworking" and it finally dawned on me: I should finally carve out some time to actually make something with all of the design I've been absorbing. Also, since I was already watching Jessica's work over the week, focusing on lettering seemed fun.

I decided to put a line-based lettering twist on the Fastly brand. I wasn't using the Fastly design assets as reference, but I wanted to make something that refected us as a company, even if it was in a way that only internal Fastly folks would understand.

To give some backstory, many of our core internal systems are named with the phrase FST in the convention. Some of these are FST-stats, FST-loader, ZD-FST; we're a creative bunch when it comes to system names. So, it seemed fitting to focus on this phrase: FST. It's something meaningful to us, and it's not too overwhelming for a quick project. I only have Pixelmator on my machine too, so the actual work took significantly longer than if I were using something like InDesign, or another first class publishing too.

It's pretty rough, and I had to hand-build the vectors on the "S" and it shows, but here it is:

Test New Encodings With Fastly

Note: This is another cross post from the Fastly blog. It really showcases the flexibility that Varnish, and Fastly as a result, provides as a caching platform. DocWilco was a significant help in making sure that the VCL and overall logical processes here were sound. It wouldn't have shipped without him.

At Fastly, we believe that the freedom to experiment is what makes the web great. We're excited by the cutting edge breakthroughs in file encodings that are happening almost every day, making the web better and faster.

For example, Google has been developing the WebP format and Mozilla recently released version 2.0 of their MozJPEG encoding. Both have the potential to speed up global web performance, but each new encoding format can have tradeoffs in your application (if you're testing either of these, make sure you keep this in mind).

Fastly Lets You Experiment With New Encodings

Your CDN shouldn't hold you back from testing new file encodings and compression techniques. Our mission is to push web performance to new heights, so enabling experimentation is crucial. With Fastly, you can take a walk on the bleeding edge just like web giants such as Facebook.

If your users' browsers support these formats, and if you have these image formats on your origin server, Fastly can serve the new encodings on the fly with some VCL. Note that for every .jpeg, .jpg, and .png, you need to have the corresponding .webp. For instance, if you have a /foo/bar.jpeg on your server, you also need to have a /foo/bar.webp.

sub vcl_recv {
  # Normalize Accept, we're only interested in webp right now.
  # And only normalize for URLs we care about.
  if (req.http.Accept && req.http.url ~ "(\.jpe?g|\.png)($|\?)") {
    # So we don't have to keep using the above regex multiple times.
    set req.http.X-Is-An-Image-URL = "yay";

    # first let's see if it's unacceptable
    if (req.http.Accept ~ "image/webp[^,];q=0(\.0?0?0?)?[^0-9]($|[,;])")
      unset req.http.Accept;
    }

    # It is acceptable, so if present set to only that
    if (req.http.Accept ~ "image/webp") {
      set req.http.Accept = "image/webp";
    } else {
      # not present, and we don't care about the rest
      unset req.http.Accept;
    }
  }
#FASTLY recv
}

sub vcl_miss {
  # If you have /foo/bar.jpeg, you should also have a /foo/bar.webp

  if (req.http.Accept ~ "image/webp" && req.http.X-Is-An-Image-URL) {
    set req.http.url = regsuball(req.http.url, "(\.jpe?g|\.png)($|\?)", ".webp\2");
  }
#FASTLY miss
}

sub vcl_fetch {
  if (req.http.X-Is-An-Image-URL) {
    if (!beresp.http.Vary ~ "(^|\s|,)Accept($|\s|,)") {
      if (beresp.http.Vary) {
        set beresp.http.Vary = beresp.http.Vary ", Accept";
      } else {
         set beresp.http.Vary = "Accept";
      }
    }
  }
#FASTLY fetch
}

This example assumes that you have your .webp files in the same directory as your .jpeg and .png files, but you can rewrite your URLs as needed to fit your deployment process.

How Does This Work?

First of all, since Vary is being used, you need to normalize the Accept header so that the header contains only two options. Without that, you risk lowering your hit rate and increasing traffic to origin. For any image URLs, you want Accept to either be empty or to contain image/webp. That way, you're guaranteed to only have one copy of the .jpeg/.png file, and one copy of the .webp file to serve all requests for that image.

After normalization in vcl_recv, the next step is changing the URL that you send to the backend. This happens in vcl_miss, so that hash isn't changed, and a purge of the image URL will purge both the .jpeg/.png and the .webp variants. Basically, if the client accepts .webp, the .jpeg/.jpg/.png at the end is swapped with with .webp.

Finally, Accept is added to the Vary header in vcl_fetch, so that the .webp and the original can coexist under the same URL, and the correct one will be served depending on the value of Accept.

What's great is that this can be used for any file encoding, not just .webp. With a few tweaks, you can support other encodings in the same way.

Have fun testing these new encodings! If you have any questions, don't hesitate to contact us by emailing support@fastly.com.

Level Up Your Log: Pro Tips for Fastly Streaming Logs

Note: This is a cross post from Fastly's blog, which was ultimately picked up by O'Reilly's Web Ops and Perfomance newsletter

Streaming logs is one of our most popular features. It's fast and flexible, giving operations teams more data from the edge than ever before and in real time.

Create Redundancy With Multiple Feeds

Setting up multiple log feeds for redundancy is so easy that it's often overlooked. Fastly doesn't limit the number of log feeds that you can create, and a parallel feed can be created in a matter of seconds.

This enables a new degree of flexibility in logging. Logging from your CDN is now something that can be approached with the same level of planning as any other tool in your stack. Based on what we've seen, the configuration is the easiest way to get started with a comprehensive strategy that accounts for redundancy and fast decision-making:

1. Create a log stream pointing to your existing monitoring tools. This may be a syslog server you maintain or a service in a supported logging platform such as Splunk, Papertrail, Logentries, and Loggly.
2. Create a parallel log feed pointing at an Amazon S3 bucket. Our standard S3 configuration defaults to sending logs in batches every hour, but this time interval can be adjusted. This should serve as a backup, or "cold storage," of your data. On a side note, Amazon recently reduced their S3 prices.
3. Add a "quick view" service if you need a separate solution from your standard tools. Third party services like Splunk or Papertrail are great for this. They provide a way for your entire team to quickly access your logs from any location, and this option won't disrupt your main monitoring tools or your backup logs.

Log Only What You Need

We don't really need any more firehoses in our lives. Data from the edge is now a solved problem thanks to the above configurations, so the biggest issue is figuring out how to actually extract meaningful information from that data.

If you're already using Fastly, you're probably familiar with our conditionals in configurations: "if statements" based on HTTP header URL content that allow you to fine-tune your CDN configurations so that they only affect certain segments of your traffic.

Streaming log configs can also take these conditionals, which allow you to create incredibly specific log streams, giving you the exact data that you need.

With these logging configurations, you can configure your service to stream only the log data that matches the conditional. There's no need to sift through a pile of irrelevant data in your logging tools if you can stop noise from getting into the system.

Some awesome use cases we've already seen include:

• Setting up a user data feed for your marketing group to log only 200s, where the referer, user agent, and granular GeoIP information are included.

  • Format string: %h %l %u %t %r %>s req.http.referer req.http.User-Agent geoip.city
  • Conditional: resp.status == 200

• A feed just for 5XX errors with additional data used for diagnosing the request, such as the Fastly POP in use, client IP address, regional GeoIP information, and whether the request was over SSL.

  • Format string: %h %l %u %t %r %>s server.datacenter req.http.Fastly-Client-IP geoip.region req.http.Fastly-SSL
  • Conditional: resp.status > 499

• A 404 feed that logs referrer information to see if there are chronic broken links on your page or pointing to your site.

  • Format string: %h %l %u %t %r %>s req.http.referer
  • Conditional: resp.status == 404

• Temporary log feeds used for tracking down elusive edge case bugs. If you know a certain URL path is occasionally erroring, you can set up a feed to log only if the request URL matches an expression and if the request status is equal to 503. You can then add diagnostic-specific information to the logs that would help you track down the root cause.

  • Format string: %h %l %u %t %r %>s resp.http.My-Debug-Header geoip.country_name
  • Conditional: resp.status > 499 && req.url ~ /path/to/debug

Logging Through the Fastly API

You can even spin up logs services with our API. The following cURL command will stage a service to log all responses to a syslog server, and include the referrer header:

=======

Obviously, that cURL command is a nightmare, so we recommend using an API client instead to save your sanity and soul.

If you already have a rapid, tool-driven operations workflow, you can build in automated creation and deletion of logs to quickly gather data as the need arises.

Make Your Data Work For You

Customers were excited when we first released our streaming logs feature, and then we took it even further when we later included support for additional logging-as-a-service platforms usage. We're just getting started, and customers are only just scratching the surface of what can be done. We're redefining what it means to have a CDN in your stack, and that extends to your logging as well.

It's time to put that edge data to work for you rather than spending your time sifting through yet another haystack looking for a needle. You can start setting up these configurations immediately in your app account.

If you don’t have an account yet, you can start testing with a developer account by signing up.

Grok the Customer

If you're in sales or marketing for a startup, you won't be successful until you understand your customer completely at a fundamental level. If you're a geek, you know this level understanding as "groking."

But, if you're not familiar with the term Grok, Wikipedia has the perfect definition for you:

Grok means to understand so thoroughly that the observer becomes a part of the observed—to merge, blend, intermarry, lose identity in group experience. It means almost everything that we mean by religion, philosophy, and science—and it means as little to us (because of our Earthling assumptions) as color means to a blind man. - Robert A. Heinlein, 1961, Stranger in a Strange Land

Ok, that definition is a little overly sci-fi, but you get the point. It's a total and complete relationship understanding with something. To the point where you can have full empathy and connection without concious action.

When you represent a startup, everything is against you. You don't have brand recognition, you don't have amazing references, and you most certainly don't have the resources that large companies can provide their teams. The only advantage you can give yourself is to better understand your customers.

This is why startup founders are often the best salespeople for their company; they understand the customer, the market, and the product better than anyone else. There's a reason why they founded the company. They grok their customers because they likely were the archetypical customer at one point. It's easy for them.

But what if you're not a founder? How can you get to this level of understanding? It's not easy.

If you're going to grok your customer -- really understand them at a fundamental level -- you're going to have to completely immerse yourself in their culture. Read what they read. Do what they do. Attend their conferences, buy their books, build what they build.

After a while, you won't have customers anymore. You'll have peers and friends who use what you make. That's what makes the difference.

It's not easy. Not many people are willing or able to go to that length. But, if you're with a tiny upstart product, it's the only advantage you have. But, if you truly care about your product and your customers, it won't be hard. You're probably on your way there already.

Shoutout to Ops

There are people in your company that you probably don't know about. That is: you might be acquainted with them, but you may not be familiar with their role. They're your operations team. They keep your site up and running. They make it so that you can deploy without downtime. They fight DDOS attacks and they make sure your machines are in tip top shape.

It’s a known truth: managing an infrastructure is hard. It's a labor of love, and the larger a site gets, the more complex the operations challenges become. There are more pager escalations in the middle of the night, more edge cases to handle, and more risk to manage when deploying. Increasing complexity is a truism when making the internet, but it shouldn't suck any more than it needs to.

When a site becomes successful it usually requires more technology and more processes to scale. But a site's success shouldn't mandate introducing anything that keeps your ops team from doing their job. Friction is lame, but paying for it is even worse. It’s something we obsess over when we work on Fastly. We're building a product for ops, and we want to build the greatest operations tool possible. We don't want our friends and colleagues to do more work because of us. We've seen how painful scaling can get, and we want to do everything we can to make the process easy. The decisions we’ve made about our product are to make engineering easier, not harder.

So, the next time you're hanging out with your coworkers, take some time to raise a toast, pour one out, or verb your favorite noun to your ops team. They're on call right now, so try not to break the build.