servicification, service-oriented-architecture, mircroservice, oh-my
Choose your term, but many organizations are building complex applications by decomposing them into discrete logical groups. These groups are often uniqe teams, code bases, and processes running in a cluster of machines.
This design is often pursued for commonly agreed upon benefits, such as:
- easier to scale the compelxity of the system by adding new teams
- keep individual velocities high by maintaining lower surface area per team
- maximize code reuse by colocating shared business logic
However there are also tradeoffs:
- increased platform demands due to coordinating large numbers of distinct programs
- balance of Conway's law vs. other design constraints
- combating fragility of the system where problems can cascade across the system
Docker, Docker, Docker
The industry has universally embraced docker as a key component of any platform powering a microservices architecture. There are both technical and analogous descriptions of what docker is. I like to use a technically correct, but highly simplified description.
Docker is a generic interface for running packaged software.
You package software using the docker build command line,
and the docker daemon produces a binary blob capable of being run on any other docker host.
Forget layers, forget lightweight virtualization and other technical details for the moment.
You can build a blob on your laptop and expect it to run reliably on a cluster you don't even own or maintain.
A docker image is the modern ELF file.
I believe that problem has been solved reasonably well. We will optimize this method with time. For example, docker builds can take unreasonably long times, and naive building of images can end up copying duplicate data across the network many times. Despite this, I belive the idea of "build a universal blob here, deploy natively anywhere" is here to stay.
Docker is only part of the solution to microservices however. We have answered how to run individual software components, but not how they work together. There are also many open questions around how to handle state between requests to the system.
I believe the following are still open questions.
- How to handle state between requests
- How to route requests through the system
There are many attempts at solving both, but we as a community are still experimenting.
I would like to present my experiment at addressing routing requests through the system.
I place a lot of value on iteration velocity, and designing high-value products with software. In fact, I place the most value on software utility. The most well designed, elegant, and optimized software is meaningless if it doesn't solve a problem.
Therefore we should optimize the platform to allow developers to find solutions to high-value problems. The value of a problem, and the quality of a solution are almost never clear until a prototype exists. The quicker we can prototype, and get that prototype solving real problems the better.
In order to maximize code reuse, and minimize time to creating full-feature prototypes, we would like to leverage the existing systems as much as possible. The topology of your system, meaning the routes interconnecting each process, plays an important role here. The more rigidly we create these routes, the harder it is to introduce new components. This is further complicated by the fact that all components of the system are iterating forward, both to add features and for maintanence.
Thus I want to create a loose topology, where components can flex without breaking the system.