Go to the profile of IT MARKETPLACE
IT MARKETPLACE
The marketplace for Go / Docker / Meiosis.js developers

What is Computing?

Dev/Ops Architecture

TL;DR. Computing is not just about software or hardware.

The next frontier in software is not to reduce its complexity but to make it less complicated

Models of Computing

  • IPO (input-process-output)
  • IPPO (input-preprocess-process-output)

IPO

  • function call
  • RPC (remote procedure call)
  • output is optional
  • push (service → client)
  • pull (client → service)
  • API (language-specific)

IPPO

  • proxy (HAProxy, nginx)
  • interface (SQL, GraphQL)
  • indirection
  • routing (twemproxy)
  • pre-process
  • data cleansing
  • data validation
  • pre-flight check
  • protocol (language-agnostic, specification for common behavior)
  • log proxy
Kafka is one implementation of log proxy

Computing Architecture

  • client/service
  • peer to peer

Computing Forces

  • push (service → client)
  • pull (client → service)

Three-Tier Architecture

  • presentation tier (desktop/mobile)
  • business logic tier (web services, microservices)
  • database (storage)

Dev/Ops Architecture

https://medium.com/p/web-services-vs-microservices-7d2230480329

  • presentation tier (desktop, mobile, SAM Pattern)
  • Web services (user-facing Web server apps)
  • microservices (business logic, RPC, message routing, message queue, 12-Factor App)
  • database (SQL, NoSQL, file, block, object storage)
  • analytics (OLAP, ML, AI, stream processing, etc)
  • ops (monitoring, logging, metrics, instrumentation, etc)

Abstraction

  • “Abstraction is the luxury of experts” — Heath Brothers
  • No to leaky abstraction
  • “Abstracting away the differences” is a leaky abstraction (e.g. libcloud, ORM, etc)
  • Why proxy pattern is a better abstraction

Programming

Real-Life Example of Microservices in Action

https://monzo.com/blog/2016/09/19/building-a-modern-bank-backend/

UNIX Philosophy

  1. Rule of Modularity: Write simple parts connected by clean interfaces.
  2. Rule of Clarity: Clarity is better than cleverness.
  3. Rule of Composition: Design programs to be connected to other programs.
  4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
  5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
  6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
  7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
  8. Rule of Robustness: Robustness is the child of transparency and simplicity.
  9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
  10. Rule of Least Surprise: In interface design, always do the least surprising thing.
  11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
  12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
  13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
  14. Rule of Generation: Avoid frameworks. Build frameworks to build frameworks (aka meta-frameworks).
  15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
  16. Rule of Diversity: Distrust all claims for “one true way”.
  17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.