I recently suggested breaking down your monolithic schedule into microservices. The idea is to make your life more modular, so if one plan falls apart, the rest will not crash like a domino effect.

But honestly, every new architecture always brings new problems. This is a law of nature. And in the case of microservices, the biggest problem is overhead management aka the hassle of managing all those tiny components.

My friend who recently refactored his schedule using this approach, is now experiencing what in cloud computing is called dependency hell and orchestration failure.

Here is the story. He broke his life down into dozens of tiny services. There is a reading-book-service, gym-service, hangout-service, doing-assignment-service, up to calling-mom-service. The theory was good, he added a 15-minute buffer between each service. But he forgot that the human brain is not Kubernetes which can manage 50 containers at once without delay.

The human brain is single-threaded. It can only run one heavy process at a time.

When he tried to run 10 different services in one day, his brain ran out of RAM doing context switching (shifting focus). He had just finished calculus which requires the left brain, then 15 minutes later he immediately forced running the gym-service which requires adrenaline. Before catching his breath from the gym, he already had to run the hangout-service which requires high-level social skills.

What was the result? All his services ran, but the performance was terrible on all of them (high latency). He did calculus without focus, he lifted light weights at the gym because he was in a rush, and during the hangout he just spaced out because he was exhausted.

This is a classic mistake of a developer who just learned microservices: breaking it down too small (over-engineering). If you break your services down to a microscopic level, your energy will be depleted just managing the communication between those services, not actually running the services themselves.

So what is the solution so your mental kubernetes does not crash?

First, use the concept of Domain-Driven Design (DDD). Combine small services that have a similar context into a slightly larger module. Instead of separating the reading-book-service and the doing-assignment-service, just combine them into a Deep-Work-Service run in one large time block, like 3 hours non-stop. In those 3 hours, you cannot be interrupted.

Second, limit the number of services you deploy every day. Do not be greedy. You cannot be a diligent student, an athlete, a good partner, and a cool hangout friend simultaneously within a 24-hour period. Choose 3 main services per day. Leave the rest idle or put them in the backlog for the next day.

Third, learn about graceful degradation. If your energy today is only at 20 percent because you got caught in the rain on your way home, you must be ready to shut down some non-critical services. Disable the gym-service and the hangout-service. Allocate your remaining battery solely for the dinner-service and sleep-service.

Do not feel like a failure if you have to drop some schedules. Even Google servers dare to kill excessively long requests to save the overall system. Are you going to be out-logicked by a search engine?

Khay