Snowsuit Zine // issue 07

Table of Contents

Operational Intelligence: Enter The Microlith

This month has been an active one in debating the merits of microservices vs monoliths. The debate has mostly revolved around three perspectives:

  1. Start with a monolith, move to microservices as needed.
  2. Start with a monolith, stay as a monolith.
  3. Start with microservices.

Martin Fowler has written a few times about the subject, including MonolithFirst and the MicroservicePremium. On Fowler's site, Stefan Tilkov has defended starting with microservices. Etsy is well known for defending start-monolith-and-stay-monolith approach, with Facebook cited as an example of a successful, large scale, monolith.

In general, all participants seem to agree on one thing: code being modular is important disirregardless of if a system is a monolith or composed of microservices. The Monolith First faction believes that the overhead of microservices gets in the way of delivering value. A good idea could be DOA because one has spent too much time orchestrating microservices. The Microservices First crowd believes that it's too hard for most developers to not create a big mess without the physical barriers of machines stopping them.

The problem with these perspectives is not that they might be wrong, but that they are too low resolution. Instead of examining what about these different methodologies worked, and why, they see that some percentage of their observations fit into their definition of success and take the whole thing. For example, in Stefan's article that suggests Microservices First, he says:

I strongly believe – and experience from a number of our recent projects confirms this – that when you start out, you should think about the subsystems you build, and build them as independently of each other as possible.

Stefan's observation is that building independent components is important. It actually says nothing about microservices. It's about building loosely-coupled components. Microservices, and everything that comes with them, happen to be how he believes people will be most successful accomplishing that.

The strength of microservices is the forced modularity, one can only call exposed APIs when the code is running in another process on another machine. The weaknesses are that it requires a significant infrastructure investment in orchestration, deployment, testing, repositories, etc.

Rather than having to pick one or the other, another option is the Microlith. With a Microlith, all of the code is in one executable, possibly one repository. However, the services themselves are not aware of this so they cannot depend on being tightly-coupled to other services. This means that services will still communicate with each other through, perhaps, a socket even when in the same process but this is a small cost for most systems.

One variation of how to achieve this is with three components:

  1. A service that exposes a start function. The start function will take a configuration as input.
  2. A configuration file, this specifies the configuration for every service the user might run with the executable.
  3. A framework that allows services to register their start function with it, parses the configuration file, and starts services that the user specifies.

All good software comes down to the taste of those developing it, but the Microlith allows one to more easily reap the benefits of microservices but without the infrastructure cost.

By having all services compiled into a single executable with a single config file:

  • Orchestration is equally difficult to orchestrating a monolith.
  • Deployment is publishing one executable and a config file.
  • Testing is simpler, starting a system is done by forging the proper config file and running the appropriate list of services. One can test every variation from all services running in separate processes to all running in one process just with one executable.
  • As the system grows, splitting the system into microservices is easier, the code is already done one just has to stop running all services in one place.

The final point is the most important, as the goal is to make the initial development simpler, like a monolith, but be able to easily transition into services when the system has outgrown running as a monolith. The Microlith becomes the fourth option in the list of ways to approach designing a system: start with a microlith, maybe end with a microlith.

This framework will not suit all use cases, but its strength is that it extracts what is good from each extreme into a unified framework. By leveraging the build system, how to ensure loose-coupling between services is clear by simply not having a service in the list of dependencies for another service. Keeping the code modular can become a test rather than a matter of taste. The Microlith provides a clear mental model for how to maintain modularity with a minimal infrastructure investment.


Network Theory

What is a Network?

Network theory is the study of complex interacting systems that can be represented as graphs and meta-information. It can be used to study electrical circuits, the flow of resources through ecosystems, the design of Internet services, and generally any kind of a system that exists over time.

In the mind of a hacker the term "network" brings up thoughts of data traveling between computers. More formally, it is a set of nodes and relations that attempt to explain some process over time. A social network is one example of network. Corporate control networks are another. Music scenes. Just about any grouping of people can be thought of as a network.

From a macro view, the value of a network is considered in terms of Network Effects, Atomic Units, Exchanges, Friction, and Stickiness.

At the center of the network, we have the network's Atomic Unit (AU). The network exists primarily to facilitate different types of exchanges around the AU. Instagram's AU is the photo and different types of functions for users to perform around the photo, like leaving a comment, possibly reporting the photo as inappropriate, etc.

A Network Effect is a way of describing how these interactions change the value of the AU to other nodes. An example both simple and easy to observe is the market for used items on Craig's List. People go there to buy stuff because there are people selling things there. And, people sell things there because there are people buying things there. In short, the value of the network grows as more people use it.

Friction is a way of describing the difficulty in joining a network. Prestigious networks tend to have a lot of friction by way of holding participants to a high standard, using exclusivity as an advantage. Social networks instead prioritize low friction to facilitate bringing as many people in as possible, which helps them serve ads.

Stickiness is also a form of friction, but it is concerned with how easily users can leave the network. If the value of the network grows as users join it, there is value in keeping users on the netwo

Networks Effects Businesses

The Internet changed things by having no theoretical limit to how many users a single network could support. About 900 million people log into Facebook every day, for example. Amazon has 240 million active customers. These numbers are only possible because we live in 2015 and have been in the Information Age for 45 years, if we use both the opening of Intel and POSIX Epoch as a starting point.

Jean Tirole won a nobel prize for a 2002 essay that described Internet companies as two-sided platforms with users on one side and developers or advertisers on the other. In doing so, he explained, new dynamics arise which place more power in the behaviors of users than that of the business. Users can go to any particular place as easily as the next and thus businesses must do more to convince users to stay.

From the perspective of a user, choice is virtually unlimited. But, from the perspective of a service builder, so is the potential userbase. PC's took 15 years to sell a billion. Android did it in 5. All together, there are about 2.5B people on the Internet right, so that is theoretically a service's potential user base, depending of course on what the service does.


Consider Facebook. The atomic unit is the post. The exchange is that users communicate with each other about that post using their facebook user identity and comments, messages, or likes. Anyone can sign up for an account. It's likely one's friends are already there, so connecting with them is a matter of finding a few friends by name and then perusing the list Facebook auto-generates for you. The sign-up process is optimized to be as simple as possible and once the user is in, Facebook trust users to entertain each other enough such that no one leaves.

Facebook is a two-sided platform. On the other side, they provide tools for advertisers. The tools help advertisers describe the types of users they want to reach and setup a campaign for tracking its performance. Advertising is where Facebook makes its money and advertisers want to work with Facebook because their userbase is among the biggest in the world.


Amazon's business can be thought of as a commodity business. The point is mostly to sell a product and get it to the user quickly. Amazon distinguishes itself from other retails by its massive inventory, fast shipping, and ease of use. For example, they own a patent for purchasing an item and having it shipped with the press of a single button. They compete aggressively on price, as demonstrated by Bezos' mantra "your margin is my opportunity".

From the user's perspective, everything they need to buy is there. The products, reviews from other users, fast shipping, an easy-to-access button that only needs to be pressed once to have a product charged to one's account and sent to their home. Customers are happy and have virtually no reason to shop somewhere else.

From the seller's perspective, they get to sell their products to a massive customer base. From a bookseller's perspective, Amazon also offers the ability to make a technological leap to, with the Kindle.


Network theory is a framework that is useful for explaining the effectiveness of service designs that seek to operate at the scale of the Internet. If network effects cannot be generated, the business might be a commodity business and end up in a price race to the bottom. If network effects can be found and cultivated, a proprietary component begins to exist and services may have a chance of building a defensible model for business on the Internet.

Monthly Consumption


  • Seveneves by Neal Stephenson (link)


  • Dotted Version Vectors: Efficient Causality Tracking for Distributed Key-Value Stores - Praguica et al (link)