As I read about the success Houston, TX has had in addressing homelessness, their approach instantly reminded me of a container orchestration engine, and so I’ve been thinking about what other patterns from micro-service architectures might be applicable to improve the performance of multiple small non-profits working on overlapping and related issues.
First, lets demystify some tech jargon.
What’s a Micro-service?
Micro-services are essentially really small bits of software that do one thing really well. The thing they do generally isn’t enough to satisfy a user’s need so several to several thousand are pulled together to create a complete software application that addresses users’ needs.
What’s a container?
A container is a portable computing environment that contains everything the software needs to run. Much like a shipping container, you can send it anywhere and it’ll still work.
What’s a container orchestration engine?
With all of these little bits of software out there in their containers, you can’t just have them running around all willy-nilly. Just like a conductor orchestrates all of the musicians to play a symphony, a container orchestration engine makes sure all of the micro-services are working together the way they were designed.
The Continuum of Care
Recipients of McKinney-Vento grants are required to operate a continuum of care to coordinate the assistance. Houston’s Coalition for the Homeless is the lead organization and essentially serves as the container orchestration engine for all of the “micro-services” that are needed to address an unhoused person’s needs. Each client is different so not all services will be appropriate, and each service has it’s own constraints and capacity so not all services will always be available. So what other patterns might be applicable?
Observability
Once you break apart your software into tiny pieces, being able to see how those pieces are working together (or when they’re not) becomes incredibly important. Continuums of Care already have this covered as they are also required to log all of their data into a Homeless Management Information System (HMIS). Being able to see this data in near real time is incredibly valuable to coordinate between the various services.
Service Mesh
I think an area for exploration would be the service mesh concept. While the orchestration engine keeps the micro-services organized and is the central authority, a service mesh essentially makes it easier and simpler for individual micro-services to talk to each other. An important aspect here is that the service mesh is deployed independently of the micro-services themselves so the micro-service maintainers don’t have to worry about implementing those protocols. Similarly in the non-profit service provider space, this could be one of the value propositions the continuum of care offers to get additional non-profits to join. For those non-profits that haven’t already joined, and aren’t compelled by Federal grant rules to join, simply addressing their day to day operational pain points by providing a simple and standard communications protocol might be a powerful motivator.
Impulse Consulting 