Real, production API requests at production load will really fill in the nooks and crannies of our API models. I wanted those to be HTTP 400s.īut I had a conundrum: Akita works best when observing production traffic. Also, our API returns a 200 HTTP Status on errors, including an element `stat` indicating failure. I wanted to put our `api_key` parameter into an Authorization header, and remove the `method` parameter since I’d used it in a fake service path. Right away I spotted some things to improve, and more ideas came that afternoon. This gave me the ability to generate Akita traces using curl and the Akita command line interface (CLI) tool out of the box, but only within my local dev environment. Thankfully our PHP request handlers are plug and play so I quickly whipped up a new proof-of-concept handler showing that we could start getting visibility into our API endpoints and their behavior using Akita. Getting Akita to work for my REST-like format This situation has historically made it hard for us to use other API tools as well. Most notably, we never adopted the REST convention of using distinct URL paths for each service endpoint, and we rely heavily on passing parameters through the query string, or form-encoded in POSTs. But there was, as I mentioned, a catch: Akita works only for REST APIs right now, and our API is… RESTish. Akita promised to tell us about our API interactions and potential issues with the API, all by passively watching API traffic. Our difficulty getting a handle on our legacy systems led us to become excited about using Akita for easy observability. And when new features need to interact with older features, this can get complex fast! On top of all that, we need to find ways to help our small but mighty team focus their limited time and attention while navigating the old and the new, without the luxury of handing this problem over to an internal tools team. A great deal of care has to be taken to avoid disruptions. Nearly every Flickr API request executes legacy code in some way-code that is less tested, less documented, and sometimes dangerous to mess with. Today, we serve up around a billion photos daily from millions of photographers. This puts us in a much better position to build new features than before-but first, we need to streamline how we get things done, which is not nearly as simple as it sounds. Since moving Flickr into the cloud two years ago we’ve had more time to focus on modernizing our services and improving our developer experience. Moving fast with legacy systemsįirst, let me give some context on high-level responsibilities of backend engineering at Flickr. This blog post focuses on how I used Akita to introduce observability to our code base. Our API at Flickr, nearly twenty years old, coincides with the rise of REST. ![]() Akita’s goal is to make it possible for organizations like ours, with our hundreds of thousands of lines of legacy code, to understand system behavior in order to move quickly.īut there’s a catch: Akita’s first product, currently in beta, works only for representational state transfer (REST) APIs. Akita’s first product passively watches API traffic using packet capture (PCAP) to provide automated API monitoring, automatically infer the structure of API endpoints, and automatically detect potential issues and breaking changes. The difficulty of wrangling a legacy code base is what led us to be interested in Akita, an observability company going after the dream of “one-click” observability. You can imagine the amount of work it takes to maintain the stability of our large, complex, public-facing API-which impacts not just customers who use our API, but our own web, mobile, and desktop clients. Flickr has built a product loved by millions of photographers for nearly two decades and we have some real history in our code base. Unfortunately, most of the conversations don’t talk about the question that is most top-of-mind for me: what does the next generation of tools look like for legacy systems ?Īs a Senior Engineering Manager for Flickr’s backend team, here’s one of the major issues my team faces: we have a ton of code that engineers need to understand in order to safely and quickly ship changes. ![]() ![]() The future of cloud-native is Lambda, claim others. Just use GraphQL and life will be easier, many will tell you. When people think about tech and innovation, they often talk about the “next generation.”
0 Comments
Leave a Reply. |