I see this concept coming back a lot as of late, at least in my ongoing learning and discovery of good design and architecture. The Single Responsibility Principle is one of the SOLID principles for good object oriented design and development. I think the SRP, and likely many other principles, have become applicable at higher levels of abstraction.
Some amazing advances in approaches to infrastructure and configuration management, deployment, scaling have hit our industry hard in recent years. Historically, before virtual machine technology was really the norm there was still a need and desire to consolidate applications and services to run on a minimal physical footprint. After all you want to use the hardware that you've purchased effectively. You don't want to run a beefy server at 10% utilization all day, so you load it up to more fully utilize it. This drives a lot of coupling at the infrastructure level of our architectures.
When VM technology became heavily adopted this started to become less of an issue. You could use the same physical hardware, but host many logical VMs on it. Thus, you've separated more of the concerns, thereby further decoupling co-hosted applications. This improves architecture, but trades for increased complexity and load on infrastructure teams. If we're going to build more single-purpose servers then we'll need more VMs. This spawned the need for greater automation in the infrastructure space. Along come tools like Puppet, Chef, SaltStack, and Ansible. These tools have done an amazing job fulfilling exactly this need. Write your infrastructure as code, version it, and leverage it for infrastructure, on demand.
We now have tools that enable us to rethink our approach to design and architecture in support of the single responsibility principle. In the early 2000s when Uncle Bob wrote about the SRP he raised visibility to a concern that we should be asking ourselves as we design and change classes. It's now 2015 and our tools have advanced incredibly. We need to ask ourselves this same question as we design all layers of our systems.
I have been particularly interested in Docker lately. I believe it adds a tremendous amount of value in this space. Despite great tools like Puppet, Chef, etc., their approach is still bulkier. With Docker's lightweight VMs the creation of individual service or application images is fast, and spawning them is even faster. You can start a Docker container just as fast as your service itself can start. Docker also really shines in its simplistic mechanism for linking together containers for interactions. If you have a typical web server, app server, database architecture it does not take long to get those pieces Dockerized and running together, linked, in a Docker environment. I really like what Fig did to simplify this even further.
Many of us likely have some work to do to improve our applications and systems in consideration of the SRP. There won't be any shortage of work there. The good news is that there is little holding us back when it comes to available tooling. It's there and most of it is free. Despite the challenges it seems to me that it's worth giving some thought and moving in that direction. More easily changed services will yield business agility, and therefore customer satisfaction.
Some amazing advances in approaches to infrastructure and configuration management, deployment, scaling have hit our industry hard in recent years. Historically, before virtual machine technology was really the norm there was still a need and desire to consolidate applications and services to run on a minimal physical footprint. After all you want to use the hardware that you've purchased effectively. You don't want to run a beefy server at 10% utilization all day, so you load it up to more fully utilize it. This drives a lot of coupling at the infrastructure level of our architectures.
When VM technology became heavily adopted this started to become less of an issue. You could use the same physical hardware, but host many logical VMs on it. Thus, you've separated more of the concerns, thereby further decoupling co-hosted applications. This improves architecture, but trades for increased complexity and load on infrastructure teams. If we're going to build more single-purpose servers then we'll need more VMs. This spawned the need for greater automation in the infrastructure space. Along come tools like Puppet, Chef, SaltStack, and Ansible. These tools have done an amazing job fulfilling exactly this need. Write your infrastructure as code, version it, and leverage it for infrastructure, on demand.
We now have tools that enable us to rethink our approach to design and architecture in support of the single responsibility principle. In the early 2000s when Uncle Bob wrote about the SRP he raised visibility to a concern that we should be asking ourselves as we design and change classes. It's now 2015 and our tools have advanced incredibly. We need to ask ourselves this same question as we design all layers of our systems.
How can we leverage the SRP to reduce coupling not just in our classes, but in our application / service design, and in our infrastructure design?Modern tools enable, and frankly necessitate, that we ask ourselves this question across our entire stack. It's really this thinking that drives teams and organizations to microservice architectures. A class that is designed with a single responsibility changes for one reason and one reason alone. This keeps classes small, thus easier to change. Services should be easy to change as well. What better way than to enable that than to give each its own, single purpose and therefore small, changeable implementation.
I have been particularly interested in Docker lately. I believe it adds a tremendous amount of value in this space. Despite great tools like Puppet, Chef, etc., their approach is still bulkier. With Docker's lightweight VMs the creation of individual service or application images is fast, and spawning them is even faster. You can start a Docker container just as fast as your service itself can start. Docker also really shines in its simplistic mechanism for linking together containers for interactions. If you have a typical web server, app server, database architecture it does not take long to get those pieces Dockerized and running together, linked, in a Docker environment. I really like what Fig did to simplify this even further.
Many of us likely have some work to do to improve our applications and systems in consideration of the SRP. There won't be any shortage of work there. The good news is that there is little holding us back when it comes to available tooling. It's there and most of it is free. Despite the challenges it seems to me that it's worth giving some thought and moving in that direction. More easily changed services will yield business agility, and therefore customer satisfaction.
No comments:
Post a Comment