2019

UDispatch #4: Stand-In Plugins

This entry is part [part not set] of 5 in the series UDispatch

The next amazing layer, now that we’ll have plugin architectures worked out, is to use plugins as stand-ins — very lightweight simulators — of the upstream behavior. A "stand-in" is a plugin that pretends to be an upstream service expressly for the purpose of developing a particualr downstream or set of downstreams that operate against

UDispatch #4: Stand-In Plugins Read More »

UDispatch #3: Custom Traffic Display

This entry is part [part not set] of 5 in the series UDispatch

Generic traffic display is part of the second layer of UDispatch’s intended functionality. And that’s okay. But custom traffic display is even better. The first layer gives us the handy bulk reverse proxy, and the second one gives us generic traffic display. And both of these help a little. But there’s two more layers of

UDispatch #3: Custom Traffic Display Read More »

Upstream Uptime #4: Content-Level Versioning and Diagnostics

This entry is part [part not set] of 4 in the series Upstream Uptime

Half of the point of upstream-centric architectures is simultaneous change, and that means the content needs versioning & diagnostics, not just our transport. The biggest single difference between a modern upstream-centric architecture and our database apps: the database app doesn’t change without our control. We choose how/when we upgrade. In effect, the database, even though

Upstream Uptime #4: Content-Level Versioning and Diagnostics Read More »

UDispatch #1: Start With a Bulk Reverse Proxy

This entry is part [part not set] of 5 in the series UDispatch

UDispatch has multiple layers of functionality in it. The first thing it is: a reverse proxy on the dev box that knows your upstreams and knows they’re sets. When you’re coding in a downstream, you typically have multiple upstreams you’re developing against. Service#1, Service#2, and so on. Your code sends HTTP to those services, they

UDispatch #1: Start With a Bulk Reverse Proxy Read More »

Upstream Uptime #3: Making Local-Runnable Services The Norm

This entry is part [part not set] of 4 in the series Upstream Uptime

I recently wrote about upstream-centric architectures and how we have to alter our making when we adopt them. A key alteration: change the definition of "deploy" to include "local-runnable". In that long list of problems I encountered in a real upstream-centric app I worked with a few years ago, a great many of the first-round

Upstream Uptime #3: Making Local-Runnable Services The Norm Read More »

Upstream Uptime #2: The Problem In Practice

This entry is part [part not set] of 4 in the series Upstream Uptime

We started talking about the new upstream-centric style or architecture the other day. I wanted that to be a first swing at describing the problem, but I didn’t really get there. Let’s do that now. The problems I see in many orgs attempting this approach, service-orientation or microservices, etc., are most visible when we come

Upstream Uptime #2: The Problem In Practice Read More »

Scroll to Top