Brian Shirai, Rubinius, Inc. April 2018, Version 0.8
Just over 100 years ago, on December 1st, 1913, the first moving assembly line was installed by Henry Ford. The assembly line reduced by 80% the time to produce an automobile in Ford's plant.
The assembly line is one of the most recognizable and outstanding successes of industrialization and mass production.
With the development of digital technology last century, businesses adopted manufacturing models and processes to build digital products. Unfortunately, despite the example provided by manufacturing, there are no outstanding successes in digital products that rival what we have achieved in manufacturing.
Much of the blame for our inability to industrialize digital products can be placed on the adoption of manufacturing processes. Information is fundamentally different than matter, and requires a different mechanism than the assembly line.
Microservices are a context-independent and scale-independent mechanism and structure for digital products that maximizes applying new information while minimizing its cost.
The properties of information dictate both the structure of microservices and the processes used to build digital products, just as the properties of matter dictate use of the assembly line and processes for controlling manufacturing.
The primary process of any business is learning, which is applying information to a problem, and this makes microservices an optimal structure for business.
We begin in Part 1 with the problem of applying new information to an existing system in a competitive market, and summarize existing procedural and structural flaws that complicate building digital products. Then we define the structure and function of microservices in Part 2. In Part 3 we introduce features of the Rubinius platform that reflect the structure of microservices and aid building them. Finally in Part 4, we illustrate benefits of microservices relative to the problems of building digital products.
Careful use of definitions is essential to precise thinking. Beyond labeling, words provide differentiation. To complicate matters, words acquire their meanings over time. This is critically important in digital products because, as John Day says, "We build what we measure."1
There are various definitions of "microservices". While the one presented here may not agree precisely, the intention is that it agree broadly with the spirit of those existing definitions, while perhaps eliminating some aspects that don't appear fundamental and emphasizing others considered essential. Where this definition may vary, we justify that by way of its utility in defining activities that promote the goal of efficiently building digital products. Microservices are distributed applications, but not all distributed applications are microservices.
Our purpose is not a natural history of digital architecture. Instead, we desire to understand how information can be applied in a competitive market to successfully build digital products. We seek to understand cause-and-effect and leverage that to gain competitive advantage over our peers. Merely imitating behavior will never provide the leverage we need.
Aspiring to a goal is not the same as attaining the goal. A moment's reflection hopefully convinces us that we should be dissatisfied with anything less than a theory of applying information to build digital products in a competitive market. Whether we are making progress in that endeavor requires the scientific method. We form an explanation.2 We make predictions and test them. We extinguish incorrect beliefs3 and refine the explanation. Most of what we learn, we could not predict.4
This paper is also available in PDF, ePub, and Mobi formats at the GitBook website.
Footnotes
-
Patterns in Network Architecture, John Day, Prentice Hall, 2008 ↩