Reading Time: 2 minutes
Many organizations are making fundamental changes to the way their applications are structured and operated. These changes are intended to address real problems.
Structurally, monolithic applications can severely hamper change delivery rate as the regression test process comes to dominate change delivery time or changes from many teams being held up by a problem with one feature.
Operationally, monolithic applications can be difficult to scale and may lack isolation between co-located functions that trigger cascading failures across the entire deployment of the monolith.
The usual prescription for these architectural problems is to split the application up into more components, but this stresses other parts of system which we will explore next.
Effects of Structural Change and Decomposing Applications
Application architectures are changing so that teams work within a structure that provides more independence and autonomy. Large applications are being split into collections of smaller, specialized components. These smaller components might be services, microservices, or functions.
These application structure changes are also reflected in team structure, meetings, source code, and delivery pipelines, amongst others.
If you transformed your monolithic application by splitting it into 4 services each handling one of your businesses bounded contexts, and then further decomposed each of the bounded contexts with 4 microservices each, you’d go from 1 to 16 services. Extending this architectural refactoring to an implementation of 4 functions per microservice would leave you with 64 functions.
The trend of “quickly growing” application component count is more important than specific numbers (also, estimate with your own), because it leads you to a valuable question:
What would break in your delivery and operational processes if you had 10x or 100x more application components?
With your current tools and 10x more application components, think about how you would:
- analyze library dependencies and trigger critical security updates
- define and maintain build and delivery pipelines
- monitor and alert on app metrics; collect and analyze app logs
- monitor and alert on security events; audit and analyze deployments for risks
Assume you don’t even know the names of all the deployed application components anymore. This is normal and expected at the scale you’re headed.
A lot of manual processes break down badly when you throw 10x more load at them.
Mergers and acquisitions have a similar effect on scaling of application components. The folks you’re merging with will probably increase application component count by 2x or more. Maybe you’re already ‘there.’
If your organization is growing and your architecture is transforming, you should adjust your mindset to accommodate a 5x, 10x, or greater increase in application components.
This should also help you see where your existing tools act as a constraint on your architecture transformation and lift that constraint.
#NoDrama
Photo Credit: Image from Star Trek: The Original Series episode, The Trouble With Tribbles © 1967 Paramount Pictures, produced by Gene Roddenberry.
