Previously, we discussed a shift in architecture that borrowed off cell reproduction, and I’m going to save the technical implementation for the next article. I’m getting quite the to-do list as I dig deeper. If you have a preference on what I tackle in the next article, let me know at firstname.lastname@example.org. Right now, I want to examine the ramification of my recommendation. Thus, for the purpose of this article, please take as a given that a container would be able to spawn a replacement for itself. I’ll explain how next time. Also, assume that a container can shut itself down. This would not be hard as most computers can turn themselves off. Suicide is easy. I’m sure there’s a metaphor for life somewhere in there. So, let’s continue the Organic modeling. How would we leverage a container’s ability to reproduce and die of old age to our advantage? Well, first off, we no longer care about a container’s health. Crazy at it may seem. So let’s walk through it.
Effectively, maintaining an open TCP/IP connection is a good health metric. JMS and AMQP both use it as their health metric for the aliveness of clients. If a container responds to a connection request, then we can pretty much assume it’s alive. That’s all we really need. Why? Because we’re going to follow common failure response scenarios and resend our request, if we don’t get a result within the expected time. This is easier in Event driven Base Principal based workflows. Remind me to get back to that with an example of how we can accept a more RESTful response like the common 200 OK with no body.
We identify failures in execution of our request by a missing response on another channel, and then resubmit our request. Thus, we don’t have to do a special health check. As long as we can see results from it, we know it’s alive. We don’t even have to understand what it’s doing. We just have to check that work is going in and out. This is a simple network monitor. Trivial to include. As long as we can connect to the container, and so long as there’s traffic going in and out, we can assume it’s functional. Ok. We don’t need any special process or system to send out and monitor health metrics. We just use the network traffic.
With that established, we can just get by with observing network traffic, and we have containers that can deploy replicas of themselves. Cool. However, I hear my concept of the hypothetical “you” I’m using as my interlocutor asking. I swear, the philosophy majors are laughing. How does this help? Well, there’s all that overhead and maintenance gone. We can rip out major portions of the Health Monitor in Cloud Foundry and lobotomize much of the intelligence in Kubernetes. We don’t want to rip it all out. It is our immune system, now that the containers work more like cells. Namely, that they reproduce and die. We don’t have to care about the specifics of a container’s health. We start to truly treat them like cattle and just kill them when they get too old. The Health Monitoring system, and the entirety of the logic in Kubernetes boils down to, “Are you too old?” If a container is older than the desired TTL for an instance, it gets shutdown. Otherwise, containers sit around doing their work, and on a regular interval, they spawn a replica and then shut themselves down.
We replace the overhead of monitoring the health of all of our containers with a simple constant churn of container starting, doing work for period, spawning a replica, refusing any more work as they complete any remaining requests, and then shutdown gracefully. This might sound like a daunting prospect. Replacing a minuscule amount of heartbeat traffic with an entire deployment every so often. Please bear with me. This is for a day when our architectures reach a point that we’re choking on that heartbeat traffic. Additionally, I think there are other advantages in this trade off. We no longer have to check for security violations. Yes, we still have firewalls and such, but we don’t have to check for infiltrations. If someone breaks into an instance, that instance will just be killed out from under the intruders anyway. We no longer need to orchestrate a rolling deployment for an update. We simply change what container will be spawned as the replacement and let the natural death of that generation take its “natural” course. This also has implications in how we scale applications. Now, we can make containers respond to heavy loads by scaling themselves and spawning a replica sooner then we configure, or when they notice idle time, or utilization fails below a certain threshold, then they can just forgo a replication in favor of dying. Naturally scaling itself down. This Organic Architecture simplifies much of our usual concerns, and it gives the option of taking advantage of benefits we haven’t had available previously. But that will be the topic of another article.