![]() ![]() I tend to take a different approach, looking at the scaling and operational properties of systems. ![]() That's a very informative approach, and you can hear him talk about it here: My colleague Colm MacCárthaigh likes to think of control planes from a control theory approach, separating the system (the data plane) from the controller (the control plane). With this pattern worked out, the block diagram of the system starts to look something like this: Sometimes, the control plane components aren't components at all, and rather people and processes, but the pattern is the same. Two roles: control plane and data planeĮvery distributed system has components that fall roughly into these two roles: data plane components that sit on the request path, and control plane components which help that data plane do its work. On the other hand, failure tolerance, scaling and deployments are control plane concerns: they scale differently (either with a small multiple of N, with the rate of change of N, or with the rate of change of the software) and can break for some period of time before customers notice. Along with the monolithic application itself, storage and load balancing are data plane concerns: they are required to be up for any request to succeed, and scale O(N) with the number of requests the system handles. What's notable here is that these concerns can be broken into two clean categories: data plane and control plane. Any system needs to change over time.Įven in the most monolithic application, these are separate components of the system, and need to be built into the design. Systems which need to handle variable load may add and remove resources over time. Highly available systems need to be able to handle the failure of hardware and software without affecting users. Distributed applications need some way for clients to distribute their load across multiple instances. Most modern applications separate business logic from storage and caching, and talk through APIs to their storage. Some kinds of concerns are almost always separated out. It's worth noting, though, that there are almost no true monoliths. Arguments about these two approaches can be endless, but ultimately not important. The monolith approach is the other end of the spectrum, where the diagram consists of a single block. The microservices and SOA design approaches tend to push towards more blocks, with each block performing a smaller number of functions. One very common pattern when doing these design exercises is to separate components into a control plane and a data plane, recognizing the differences in requirements between these two roles. Getting the block diagram right helps with the design of database schemas and APIs, helps reason through the availability and cost of running the system, and even helps form the right org chart to build the design. It's such a basic design step that many of us don't think about how important it is, and how difficult and expensive it can be to make changes to the overall architecture once the system is in production. If you want to build a successful distributed system, one of the most important things to get right is the block diagram: what are the components, what does each of them own, and how do they communicate to other components. ![]()
0 Comments
Leave a Reply. |