Steve Vinoski's Blog

As an editorial board member for Internet Computing magazine one of my duties is to occasionally write the “From the Editors” column, so for the March/April 2014 issue I contributed the article “Rediscovering Distributed Systems” (PDF). The idea behind the article is that many production systems today are distributed systems, and so more developers are taking a look back at all the distributed systems research from the past few decades so they can try to avoid reinventing the wheel. The brief article goes through a few important distributed systems papers, and also includes references to other sites and resources for learning more about distributed systems.

At QCon London March 7-9 I’ll be hosting a track on Highly Available Systems, which I’ll describe in more detail below.

But first, be aware that if you register for the conference using promotion code VINO100, you’ll save yourself £100 off the registration fee plus I’ll donate £100 to the World Food Programme.

This track is compelling. As track host I focused on inviting speakers with significant experience in building and deploying real working systems that exhibit high availability, with the goal of maximizing the transfer of ideas, approaches, tools, and techniques from the speakers to the attendees.

• The track kicks off with Joe Armstrong, the father of Erlang, talking about building highly-available systems with Erlang.
• Next up, Mark McGranaghan of Heroku will present approaches they use at Heroku to ensure high availability.
• After lunch, John Allspaw of Etsy will talk about fault tolerance, anomaly detection, and anticipation patterns. John is well known for his excellent books on capacity planning and web operations. John is also giving the Friday morning keynote, “Resilient Response In Complex Systems”.
• Following John will be Jodi Moran, CTO at Plumbee, who will tell us about what it takes to build systems capable of going from zero to ten million users in 4 weeks.
• We’ll wrap up the track with Martin Thompson, a specialist in high-speed, highly-available and low-latency systems who helped build the LMAX Disruptor, who will talk about event-sourced architectures and what we’ve forgotten about high availability.

It’s gonna be great, no doubt, and I’m really looking forward to it. Hope to see you there!

I’ll also be giving a talk at the conference about distributed systems and Riak Core.

You may have already seen this on InfoQ or on Stefan’s blog, but the video of my 2008 QCon London presentation “REST, Reuse, and Serendipity” is now available.

Here it is, just a little over a year after I gave that presentation, and REST continues to deliver extremely well for my work. For example, I just finished a meeting a couple hours ago where some client code needs to interact with a particular part of my system via HTTP but wants XML instead of the JSON currently provided. Simple — it’s just a different representation of the same resources, and of course it wasn’t hard to guess months ago that such a need would eventually come down the pike, so fitting it into the system will be trivial. Can you imagine the hoops one would have to jump through with typical RPC-oriented systems for this case, where the marshaling format is typically tied to the protocol and you can’t change either one? You’d have to write a new service interface with new verbs and new messages and get the client side to use it, or write client-side wrappers around whatever you already have and ask the client programmers to somehow incorporate those wrappers into their code. Either way, there’s simply no chance of reusing existing agreements; instead, both sides require non-trivial specialization.

One problem I noticed, though, was that the client developers asked for a “REST-like interface” and also for a document listing all resource URIs, and for each one, the HTTP verbs that apply to it, the representations available from it, and what status codes to expect from invoking operations on it. Those two requests are sort of mutually exclusive, depending on what “REST-like” means; for a proper RESTful system, you don’t need a document like that, at least not the type of document they’re asking for.

My Nov./Dec. Internet Computing column is now available. It’s entitled “RESTful Web Services Development Checklist“ and as its name implies, it covers some of the primary areas developers need to focus on to write good RESTful web services. These areas are:

• Resources and their URIs
• Applications and Hypermedia
• Representations and Media Types
• Methods
• Conditional GET

Regarding the “Applications and Hypermedia” area, I feel Roy Fielding’s pain that many efforts labeled as being RESTful seem to completely ignore the hypermedia constraint. I believe many developers tend to miss this constraint because they’re so used to using libraries and frameworks that offer lots of entry points, and having knowledge of those entry points in the client normally isn’t that bad since the client and library/framework are tightly coupled into the same address space anyway. In a distributed system, though, this definitely does not hold true; when the client knows a bunch of entry points into the service, it ties the client to that service and inhibits their independent evolution.

Anyway, please read the column and let me know what you think, and thanks again to Stefan Tilkov for his helpful review of the draft.

Coincidentally I also feel Roy’s pain when it comes to writing about REST. He states:

I don’t try to tell them exactly what to do because, quite frankly, I don’t have anywhere near enough knowledge of their specific context to make such a decision.
…
So, when you find it hard to understand what I have written, please don’t think of it as talking above your head or just too philosophical to be worth your time. I am writing this way because I think the subject deserves a particular form of precision. Instead, take the time to look up the terms. Think of it as an opportunity to learn something new, not because I said so, but because it will do you some personal good to better understand the depth of our field.

Exactly.

Obviously, Roy is the ultimate REST authority, given that he defined it, so I’m not at all claiming to be anywhere near as authoritative about it as he is, yet I’ve also experienced what he says above. For example, consider this informal review of my columns I received a few months ago in a comment on someone else’s blog:

The articles of yours that I’ve read are…amorphous to me. They speak in generalities. I haven’t read an article where you sit down and write the same service using both REST and RPC and compare the two. When you speak in generalities, we can’t objectively evaluate any of the specific trade-offs between approaches… Arguments that happen at too abstract a level can’t go anywhere, because our positions aren’t specific enough for anyone to evaluate anybody else’s claims.

In other words, “since your columns don’t do my thinking and experimentation for me, they’re useless to me.” Hmm. Maybe I’m just old school, but I’d much rather understand mathematics than require someone to hold my hand while I blindly punch buttons on a calculator. In other words, as the old proverb goes, I’d much rather try to teach you to fish so you can feed yourself. As I state in this new column:

Whether developers of RESTful HTTP-based services write their code in IDEs or with simple text editors, and regardless of which programming languages they use, they must understand REST and HTTP fundamentals to succeed.

Eric Newcomer gives us his take on my recent articles (1, 2, 3, 4) and blog postings (1, 2, 3, 4) about RPC, REST, and programming languages:

Anyway, after carefully reading the article and blog entries, I believe Steve is not against RPC per se. He wants people to think before just automatically using it because it’s convenient.

Exactly!

Also spot on are the following postings:

• Bill de hÓra: Patterns of Web Architecture
• Three postings from Stu Charlton:
  • Convenience, Correctness, and Network Interactions
  • Can technology progress?
  • On changing industry mindsets

The beauty common to all these postings is the breadth, depth, and variety of thinking and reasoning they present. There’s a lot to read, but if you’re interested in critical thinking about the design and construction of distributed systems I encourage you to read them all the way through, including the comments, and to follow the links they offer as well.