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 »
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 »
Thick culture begins with developing a sense of temporality: past, present, and future. I believe that if we persist without this sense, the geek trades will never be other than the dystopia we experience today. (This conversation is a hard one. Expect a rambler of a muse, here.) Start with plain ol’ professional programming. If
Thick Culture Begins With Temporality Read More »
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 »
The first layer is the handy UI-capable bulk reverse-proxy, and the next thing we layer on to it is generic traffic inspection. (I should so not be writing this up right now. I got other fish to fry. But there are some blockers I’m waiting on, and I have a little time, and I just
UDispatch #2: The Second Layer Read More »
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 »
TDD Pro-Tip: TDD-blockers are everywhere for me, even now, after twenty years of practicing it, so I still try new ways to work around them, and I don’t always find them, and I wait for next time. A respondent had a great question, and this is a kind of "sideways" answer. The question: Given that
When To Start Doing TDD Read More »
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 »
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 »
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 runtime. It is typically 1)
Upstream Uptime #1: Grasping the Problem Read More »
