3 ms·
We have guidelines from long ago.. (edit: Linky here http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html http://homepage.cs.uri.edu/~thenry/resou
by kefka 10y ago
We have guidelines from long ago.. (edit: Linky here http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s0... )
Rule of Modularity: Write simple parts connected by clean interfaces.
What's simpler than a container that has clean API in and out?
Rule of Clarity: Clarity is better than cleverness.
Container Foo does foo action. Not Bar's action.
Rule of Composition: Design programs to be connected to other programs.
If everything's an API call, calling to it is trivial.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
The interfaces can be their own container. Now updating the Interface can't bring down the whole system. And the people in charge of the interface needen't have permission to change other containers (unless on that team).
Rule of Simplicity: Design for simplicity; add complexity only where you must.
I know that a container does its job and does it well. Any complexity is contained, and cannot pollute other systems.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Or... The combined system that you run is the big program. Because a big problem is almost always lots of small problems that look big.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
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't matter what server the data is climbing through; you can see it. I personally like Apache NiFi, for the provenance. There's nothing like it I've found.
Rule of Robustness: Robustness is the child of transparency and simplicity.
A container makes it evident if it is the result of bad programming. You'll see good data go in, and bad come out.
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
Because you never know what the next dev will think about your code. That clever method fails if the method is deleted...
Rule of Least Surprise: In interface design, always do the least surprising thing.
That's arguable, if you're trying to scam users with dark patterns.
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.
Absolutely. I've dealt with way too many things that fail silently, or fail with "OK", or are chatterbots on good data.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
This plays right in to containerization. Compute/storage is cheap.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Yeah, LISP and FP still hasn't taken off.
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.
Hence containers. It's a ball of privilege separation, data segregation, clean interfaces, and easily maintainable.
- lmm 10y ago> What's simpler than a container that has clean API in and out? The problem is that network APIs still suck. The boundary between components is the place where strong typing is most vital, but microservices are still largely based around stringly-typed JSON. > If everything's an API call, calling to it is trivial. Calling a library API is a lot easier than calling a web API > The interfaces can be their own container. No they can't. That doesn't make any sense. What do you even mean? > I know that a container does its job and does it well. Maybe. I'm never clear on what exactly the job of the "container" is supposed to be - it seems to involve process isolation (I'd think ordinary processes should do that?), and maybe doing funky network namespacing and PID namespacing and a few other things like that, only then other people are saying you shouldn't do that? > A container makes it evident if it is the result of bad programming. You'll see good data go in, and bad come out. Only if you can tell good data from bad data. Which is much easier to do within the language, where you have a type system to help you. > This plays right in to containerization. Compute/storage is cheap. Compute/storage is cheap, so you probably won't ever have to make your system distributed. The biggest problem with microservices is that they slow development by making it much harder to run the whole system. Anything that makes your development feedback loop slow is a big problem. > Yeah, LISP and FP still hasn't taken off. FP is taking off. It's a lot bigger than it was 5 or 10 years ago. > Hence containers. It's a ball of privilege separation, data segregation, clean interfaces, and easily maintainable. On the contrary, containers are being pushed as the one true solution to everything, and seem to aggregate a bunch of unrelated concerns.
- clintonb 10y ago> The problem is that network APIs still suck. The boundary between components is the place where strong typing is most vital, but microservices are still largely based around stringly-typed JSON. You don't have to use a RESTful API and JSON. If you feel that configuration is lacking you can use a binary format and a non-RESTful API.
- lmm 10y ago> You don't have to use a RESTful API and JSON. If you feel that configuration is lacking you can use a binary format and a non-RESTful API. Sure, and that improves things a lot. I do use Thrift (via Scrooge) sometimes. I get the sense that isn't what the microservice advocates are talking about though. But even then, why introduce a network boundary when you don't need to? All it does is make your system slower, add overhead converting back and forth from DTOs, and give more opportunity for calls to fail.