Month: August 2019

UDispatch #4: Stand-In Plugins

This entry is part 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 …

UDispatch #4: Stand-In Plugins See Full Post

UDispatch #3: Custom Traffic Display

This entry is part 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 …

UDispatch #3: Custom Traffic Display See Full Post

Upstream Uptime #4: Content-Level Versioning and Diagnostics

This entry is part 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 …

Upstream Uptime #4: Content-Level Versioning and Diagnostics See Full Post

UDispatch #1: Start With a Bulk Reverse Proxy

This entry is part 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 …

UDispatch #1: Start With a Bulk Reverse Proxy See Full Post

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

This entry is part 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 …

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

Upstream Uptime #2: The Problem In Practice

This entry is part 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 …

Upstream Uptime #2: The Problem In Practice See Full Post

Upstream Uptime #1: Grasping the Problem

This entry is part of 4 in the series Upstream Uptime

Increasingly, we build apps by composition with other apps. Granting that this approach is viable, still it comes with a cluster of related problems, and to really win with this style, we’ll have to address them. An "upstream" is an independent program that my application’s correct behavior depends on at …

Upstream Uptime #1: Grasping the Problem See Full Post

Scroll to Top