Microservices? Please Don't
We have guidelines from long ago.. (edit: Linky here <a href="http:&#x2F;&#x2F;homepage.cs.uri.edu&#x2F;~thenry&#x2F;resources&#x2F;unix_art&#x2F;ch01s06.html" rel="nofollow">http:&#x2F;&#x2F;homepage.cs.uri.edu&#x2F;~thenry&#x2F;resources&#x2F;unix_art&#x2F;ch01s0...</a> )<p><pre><code>    Rule of Modularity: Write simple parts connected by clean interfaces.
</code></pre>
What&#x27;s simpler than a container that has clean API in and out?<p><pre><code>    Rule of Clarity: Clarity is better than cleverness.
</code></pre>
Container Foo does foo action. Not Bar&#x27;s action.<p><pre><code>    Rule of Composition: Design programs to be connected to other programs.
</code></pre>
If everything&#x27;s an API call, calling to it is trivial.<p><pre><code>    Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
</code></pre>
The interfaces can be their own container. Now updating the Interface can&#x27;t bring down the whole system. And the people in charge of the interface needen&#x27;t have permission to change other containers (unless on that team).<p><pre><code>    Rule of Simplicity: Design for simplicity; add complexity only where you must.
</code></pre>
I know that a container does its job and does it well. Any complexity is contained, and cannot pollute other systems.<p><pre><code>    Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
</code></pre>
Or... The combined system that you run <i>is</i> the big program. Because a big problem is almost always lots of small problems that look big.<p><pre><code>    Rule of Transparency: Design for visibility to make inspection and debugging easier.
</code></pre>
Hence the APIs. The only thing I can think of adding, is a debug tag that allows logging to a logging server if DEBUG = On. Then, it doesn&#x27;t matter what server the data is climbing through; you can see it. I personally like Apache NiFi, for the provenance. There&#x27;s nothing like it I&#x27;ve found.<p><pre><code>    Rule of Robustness: Robustness is the child of transparency and simplicity.
</code></pre>
A container makes it evident if it is the result of bad programming. You&#x27;ll see good data go in, and bad come out.<p><pre><code>    Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
</code></pre>
Because you never know what the next dev will think about your code. That clever method fails if the method is deleted...<p><pre><code>    Rule of Least Surprise: In interface design, always do the least surprising thing.
</code></pre>
That&#x27;s arguable, if you&#x27;re trying to scam users with dark patterns.<p><pre><code>    Rule of Silence: When a program has nothing surprising to say, it should say nothing.

    Rule of Repair: When you must fail, fail noisily and as soon as possible.
</code></pre>
Absolutely. I&#x27;ve dealt with way too many things that fail silently, or fail with &quot;OK&quot;, or are chatterbots on good data.<p><pre><code>    Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
</code></pre>
This plays right in to containerization. Compute&#x2F;storage is cheap.<p><pre><code>    Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
</code></pre>
Yeah, LISP and FP still hasn&#x27;t taken off.<p><pre><code>    Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

    Rule of Diversity: Distrust all claims for “one true way”.

    Rule of Extensibility: Design for the future, because it will be here sooner than you think.
</code></pre>
Hence containers. It&#x27;s a ball of privilege separation, data segregation, clean interfaces, and easily maintainable.