UDispatch #4: Stand-In Plugins

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 it. Now, the mind can't help to go to the word "simulator", I even used it myself up above. But I'm going to use "stand-in"…

Continue Reading

UDispatch #3: Custom Traffic Display

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 function here, and today we talk about third one: custom traffic plugins. In the early days of implementing upstream-centric architectures, two strong tendencies stand out:…

Continue Reading

Thick Culture Begins With Temporality

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 you're like most geeks, your current team is working on a project with lifetime measured in years, has been in production for a while, and…

Continue Reading

Upstream Uptime #4: Content-Level Versioning and Diagnostics

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 it's an upstream, feels like and can be treated like just another part of the language syntax. Whether our code works, or doesn't, and how…

Continue Reading

UDispatch #2: The Second Layer

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 feel like mapping it out further.) Once we have that first layer running, we've got on our local box 1) our downstream app development environment,…

Continue Reading

UDispatch #1: Start With a Bulk Reverse Proxy

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 answer with HTTP. These services are typically arranged in sets. That is, to use Service 1A, one must also be using service 2A and 3A.…

Continue Reading

When To Start Doing TDD

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 we're halfway through an app w/o an architecture that TDD's well, should we start TDD now or wait for the next greenfield chance to do…

Continue Reading

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

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 woes come from one simple fact: "The upstream I'm coding against lives somewhere else." Network outages, rebuild blockages, vpn passwords, version stability, and dataset- app-sharing…

Continue Reading

Upstream Uptime #2: The Problem In Practice

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 not to theory but to practice. One sentence: Old-school practice works in old-school apps because it holds a large part of the app fixed in…

Continue Reading

Upstream Uptime #1: Grasping the Problem

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) across a transport mechanism, 2) in a separate process and/or machine. We've of course had upstreams in our lives forever: virtually all apps that use…

Continue Reading
Close Menu
×
×

Cart