The Downside of Democracy: Mo’ Administrators, Mo’ Problems

Autocratic governments tend to be corrupt, repressive, and egocentric. Monarchs and dictators control citizens’ behaviors and speech, and generally limit their freedoms. So this might sound controversial, but humor us for a second — one-party rule does have some advantages. Sure, that’s mostly for the person or people in charge. But for the general public, at least there’s the simplicity of having a single voice calling the shots and the stability that comes from mandatory compliance. They don’t have to make a lot of tough decisions because they don’t have a choice; there’s only one acceptable way to do things. It may be the wrong way, but it’s usually faster.

It’s kind of like how a network with one administrator might operate — restrictive, yet efficient. That is, if there were such a thing. In reality, even the most basic computing networks these days have multiple administrators. In a way, they function more like representative democracies. There are numerous officials governing different cities and states, each with its own unique customs and priorities. They may all be guided by a shared doctrine, but they still make and enforce individual rules and protocols that aren’t coordinated across regions. So, what does any of this have to do with the Fallacies of Distributed Computing, and their relevance to web applications?

Think of applications, in this analogy, as agents of interstate commerce. They need to transport materials or access resources in several disparate areas, which means complying with a variety of policies and procedures that often don’t match up. Last week we saw how relying on static topology can be dangerous. This week’s post examines why the same is true of accepting the fallacy of one administrator. Knowing the right way to your destination is just the first step, but you also need to understand the local traffic laws.

As distributed systems have grown increasingly complex, the need for more administrators has risen proportionately. Organizations employ teams of them to manage private networks and each one is often an expert in a different part of the system. In a web environment, you’re talking about innumerable, essentially autonomous administrators, all with the freedom to set policies for their individual zones. Because these practices aren’t standardized across the whole system, web application builders must be compliant with various sets of administrative guidelines to ensure they can access the resources they need and transport their digital cargo.

Overlooking all this red tape, and ignoring the impact of multiple administrators, gives developers decidedly less control over their app’s performance and reliability. It leaves them vulnerable to decisions and mistakes outside their jurisdiction, and puts them at the mercy of external administrators’ rules and protocols, which can translate to security issues and unexpected downtime. It also means more time spent reacting to problems after they’ve already done harm, rather than resolving them proactively.

Now, you might be thinking: Everyone knows there’s not just a single administrator for applications in a web environment. However, not everyone agrees that this actually matters for application builders. In his article The Web vs. The Fallacies, technology authority and author Tim Bray grants that “there are millions of administrators” in the cloud, but contends that web architecture makes this fact irrelevant to developers.

The benefits of decentralized addressing and routing via URIs, he argues, keep administrators’ decisions (and mistakes) from having a peripheral impact, so “the damage is limited to that person’s URI space.” He goes on to say that web architecture provides a framework for standardization because URIs give the motley horde of administrators a fixed set of parameters for routing. Therefore, there’s less variation for developers to consider – and what complexity prevails doesn’t necessarily impede an app’s fundamental operations.

There’s no denying that web standards do address some of the disorder brought on by having so many administrators, but they don’t at all ensure seamless interoperability. And while perfection may not be possible to guarantee, there are measures developers can take to minimize problems caused by administrative disparities.

Despite decentralized addressing and uniform routing procedures, applications can still encounter variables beyond the developer’s control. For instance, administrator policies and preferences aren’t coordinated, which we noted before. As mentioned last week on the subject of changing topology, sometimes there are mistakes with URIs. An informative white paper on the Fallacies we’ve cited throughout this series points out that upgrades to different components of the system can also complicate interoperability. Each of these issues can be a huge liability for an application, which is why we think it’s risky to rely solely on web technologies for synchronicity.

So what’s a developer to do? Once again, the best way to avoid these problems is to be proactive. Pay attention to and understand the administrative policies that impact your application so you can align with them. Provide tools to help manage the app and identify issues. Don’t forget to keep backwards compatibility in mind when you make upgrades. The extra time and effort up front is worth it to maintain more control over the behavior of your app. And you’ll be glad you took steps to coordinate with the administrators influencing your environment the moment there’s a discrepancy.

Next week: What good is having a killer app if you can’t afford hosting?

leigh@newrelic.com'

Marketing Manager, Content View posts by .

Interested in writing for New Relic Blog? Send us a pitch!