Microservices, the hot thing that has been around for decades?

Microservices are often described as a way to organize your system in order to increase modularity, scalability, integration and distribution. It can easily come of as something pretty modern that companies recently started talking about, but I would say that it’s been around for quite a while.

Peter Rodgers is credited to have coined the term “Micro-Web-Services” back in 2005 during a presentation at the Web Services Edge conference.

Microservices can be seen of as a way to structure your architecture as a collection of services that are

  • Highly maintainable and testable
  • Loosely coupled
  • Independently deployable
  • Organized around business capabilities
  • Owned by a small team

All of this enables rapid, frequent and reliable delivery of large, complex applications. It also enables the organization to evolve its technology stack in a structured manner.

The YouTube channel Continuous Delivery has a pretty good summarization in one of their videos where they explain the characteristics of a microservice architecture.

  • Small
    – “Fits inside of James Lewis’ Head” / Martin Fowler
    – Could you rewrite it in a week or two?
  • Focused on one task
    – and doing it well
    – Separation of Concerns in the problem domain
    – Accomplishes one task when viewed from outside
  • Aligned within a bounded context
    – “… is a defined part of software where particular terms, definitions and rules apply in a consistent way”, Eric Evans (Domain driven design)
    – Prefer services aligned with “Seams” in the problem domain
    – Arbitrary division, not really microservices
    – Natural “fire breaks” in the problem domain
    – Context A -> Context B : Translate A output to B input
    – Ports and adapters
  • Autonomous
    – We can change implementation without coordinating with others
    – Biggest value of microservices
    – Service based design != microservices
  • Independently Deployable
    – If your service is not independently deployable it’s not a microservice
    – If you always test your service with others before release, it is not independently deployable
    – Build, Test & Deploy services independently from other services
    – THIS is the REAL value with microservices, also this is the real cost
    – Microservices are an Organization De-Coupling Strategy
  • Loosely-Coupled
    – Make external and internal representation different
    – The interface to a microservice is a public API
    – It should be changed only with great care
    – When consuming an API, use minimum data that you can to reduce coupling

But when you look at the ideas and philosophies or at an architectural drawing of a micro service architecture, despite the somewhat new popularity of it, there is a lingering feeling that we have witnessed this before.

The UNIX design philosophy

In their award-winning UNIX paper of 1974, Ritchie and Thompson quote the following design considerations

  • Make it easy to write, test, and run programs.
  • Interactive use instead of batch processing.
  • Economy and elegance of design due to size constraints (“salvation through suffering”).
  • Self-supporting system: all UNIX software is maintained under UNIX.

This ties into the UNIX design philosophy by Doug McIlroy in the Bell System Technical Journal from 1978.

  1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
  2. Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
  3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
  4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.

The connection and similarities feels like a natural progression. You see, Peter Rodgers’ work that led to the “Micro-Web Services” originated in 1999 with the Dexter research project at Hewlett Packard Labs, whose aim was to make large-scale, complex software system easier to change. Hewlett Packard had been early adopters of UNIX and its easy to see how the philosophies of the design of UNIX influenced the work of Hewlett Packard.

The ideas of the UNIX design philosophy were later summarized by Peter H. Salus in A Quarter-Century of UNIX (1994)

  • Write programs that do one thing and do it well.
  • Write programs to work together.
  • Write programs to handle text streams, because that is a universal interface.

Unix built using a micro services philosophy?

Whenever I have heard the mention of a micro service architecture and heard people explain their designs I have felt that the fundamentals of what we today call micro services UNIX and it’s derivates handled decades ago. One can see how the fundamental philosophy of micro services map well into the design philosophy of UNIX.

Micro ServicesUnix Design Philosophy
Small
Focused on one task
Independently deployable
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”
Loosely coupledExpect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input
Highly maintainable and testableDesign and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them
Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them

Just as micro services are built to be made up of several small loosely coupled parts, focused on one task where the output of one part can be the input of another UNIX programs are build to focus on one task or one group of tasks. More elaborate behavior is achieved by stringing multiple commands together where the output of one command becomes the input of another.

You want to list all the pdf-files in the sub-directories of a given directory there is a program for that.

find . -type f -name "*.pdf"

Do you want to know how many pdf-files there were? Instead of adding that behavior to the find command you simply take the output of the find command which will be a list of files and pipe it into the wc command. wc can count things in the input such as bytes, characters, words and lines. So to get a count of the number of pdf-files found we simply ask wc to give the number of lines in its input.

find . -type f -name "*,pdf" | wc -l

So was UNIX built with a micro services philosophy? It sure fit many of the same principal ideas especially for core components. But a more fitting way of looking at it is probably that the fundamental ideas that today are part of micro services existed long before that became a hot topic and if anything a lineage could be traced indicating that the seeds of the modern philosophy of micro services can be found in the very same ideas that once shaped the design philosophy of UNIX.

Comments

Share on activity feed

Powered by WP LinkPress

Comments

Share on activity feed

Powered by WP LinkPress