Frameworks are a Service level primitive which provides a standardized structure and sequence flow. Frameworks support delivery by providing platforms with unified service structures, which minimize on boarding and ramp up time, provide conventions to minimize cognitive overhead and troubleshooting and provide a platform with uniform zero-cost abstractions such as metrics/observability. Frameworks can provide a cornerstone to build a platform’s library ecosystem, laying a foundation for platforms to further accelerate an organizations delivery.
What is a Framework?
Frameworks are a language level pattern which help to reduce boiler plate code and impose an application level structure. Framework Abstracts an execution environment expanding on libraries by not only answer “How” is something executed but by answer “Where” is something executed within a transaction or application, which provide:
Uniform Sequence / Data Flow
Frameworks achieve their benefits by providing a uniform application data flow. In order to illustrate this consider HTTP web frameworks. Without a framework their might be multiple interpretations of where certain actions take place. A team that had detailed understanding of reactive systems may have a highly different solution to a reactive worker than a team with only Request/Response service experience. Some may check the headers during parsing, others may.
Clear explicitly abstract data flow. Using a framework it’s not up to the team for interpretation, they have an executable structure, and can hook into the parts that they want. The Framework implements the data flow in terms of its domain, ie HTTP services. Clean abstraction, HTTP domain is represented in the above framework. Frameworks provide a clearly defined domain abstraction. Each of these events is ubiquitous in HTTP infrastructure, and clearly encodes each of the state/data transformations.
Uniform Structure
The sequence forms the spine of the framework structure. By having uniform data flow sequence, Structures either emerge implicitly through convention, or are required explicitly as part of the framework. Having an explicit data transactional sequence gives rise to explicit abstractions in order to achieve that sequence.The framework defines specific entry points into the sequence:
Structure defines abstractions and interfaces around the sequence.
Frameworks provide Clear separation through encapsulating but also expose well know extension points. Consider an HTTP service: most teams shouldn’t ever have to deal with HTTP protocol parsing. While most organizations offer HTTP services if HTTP protocol isn’t a core competency than any time spent parsing HTTP or having teams reason about the HTTP protocol is low value. Frameworks help to insulate teams from implementation details around protocols, and common actions allowing them to focus more on their application logic! Having clear abstractions and implementations of those also supports a clear, supporting difference services using shared abstractions, terminology but also having uniform on disk file layout structures!!!
Having explicit structures that expose clear extensions points minimizes the amount of time necessary for engineers to get full end to end functioning services.
Ecosystem
Frameworks can provide the foundation for rich application library ecosystems. Through shared Abstractions, benefits for a platform because teams can solve a problem once and other teams then get to use it for free
Ecosystem are implemented in terms of libraries, establishing a rich synergy for reuse and further increasing velocity. Ecosystem can arise through the structure that frameworks impose. In the above example each of the frameworks exposed interface gives way to build a library based ecosystem.
The above image shows an ecosystem arising around the frameworks. This ecosystem is along the dimensions of request middleware. Generic state interfaces (`RequestMiddleware` in this case) allows for generic implementations. When scoped correctly the Rate Limiting component can be domain agnostic, allowing multiple teams to share and use it (Team 1 and Team n). The implementations no longer have to be one off or duplicated, but can be shared for each consumer of the framework. Exposing interfaces and clear data flow supports generic solutions and components. The framework above just focuses on the request middleware ecosystem, but in well defined frameworks, many base states implementations can be packed and reused. If using open source these ecosystems should be very familiar. Most Web frameworks have a rich ecosystem of plugins, which is made possible through the explicit sequence and structures that frameworks provide.
Organizational Topology
Frameworks, like libraries, are a shared resource with a tight application (language) level coupling. They exist within a service process and are not executed directly:
Frameworks also have a tight coupling between application workload pattern (Service, Batch, Streaming). This results in the same dependency attributes as Platform Libraries.
How Do Frameworks Support an Orgs Ability to Deliver?
How do frameworks offer a positive ROI?
Velocity Reduced Implementation Time — OTS service framework that minimizes the boiler plate required in order to launch a service.
Less work is required in order to launch equivalent services resulting in less latency between starting and ending a service for equivalent teams.
Reduced Implementation Cost
The same charts displayed above for velocity affect implementation cost. Teams no longer have to duplicate and/or spend time on tasks that aren’t core competency. The same benefit applies in terms of cost, team that can use already completed work has less cost associated with launching a service than an equivalent team that is responsible for performing that work. The velocity diagram above shows the overhead of framework vs no framework in terms of latency and the diagram below shows it in terms of percentage of components:
Non-trivial frameworks contribute a measurable amount of complexity to projects, which translates to time which equals cost:
The diagram provides an optimistic estimate of 25% but for larger services or more complicated frameworks this could easily comprise even more logic than the business logic. Teams that have to develop a framework capabilities for themselves incur that cost in terms of dollars.Teams that have access to already developed frameworks only incur an integration cost instead of an implementation cost.
Agility — Uniformity
Frameworks provide each service with the same foundation. This enables agility through lowering the barrier to entry when switching projects. The uniform data sequence and structure enables less ramp-up time when switching between projects. This is especially important in a microservice environment, or an environment where teams may be touching many different projects in order to deliver their work.
MTTR/Debugging
Have an explicit data sequence structure can help during incident debugging. After learning the framework the general structure can be applied to every application that uses the framework.
Consider when no frameworks are used. An incident responder not familiar with the framework will have to learn that specific projects conventions and data flow, whereas if a framework is used incident responders can apply their framework understanding to the project.
Understanding where errors are generated in the framework data processing sequence or which components are likely to generate errors, Ie in an HTTP framework models or Data Access Objects may be responsible for talking to the database understanding sql/db errors are generated here may help with pinpointing issues and reducing MTTR during incidents and debugging time during development.
Ecosystem
Establishing a uniform service framework support framework ecosystem. This can be seen in many popular open source HTTP frameworks which often have a rich ecosystem of plugins or libraries available. Authentication middle-wares, rate limiting, frameworks have a rich synergy with libraries though providing a foundational primitive in distributing functionality. The ecosystem arises because frameworks expose well known abstractions. The follow graph shows how a rich ecosystem of libraries can arise:
Framework libraries can be bundled in with the framework which help platform uniformity by creating a default action, which doesn’t even require the end engineer to opt-in, or they can be explicitly required, allowing the end engineer to “compose” applications from many different framework libraries.
Conclusion
Use frameworks whenever you want to impose structure to projects, or sequences. Even poorly scoped and formed frameworks can provide a platform with more uniformity and structure while establishing shared tooling and terminology. Frameworks are essential patterns in engineering a platform which provides both structure and uniformity to services. They are ubiquitous and most languages/application types offer a wide variety of frameworks. If a platform doesn’t define explicit frameworks, teams will either make their own technology choices leading to a fractured platform or frameworks be inherited from the closest level of abstraction, or from the execution environment. Both are sub optimal outcomes which will most likely not align with an individual businesses goals or domain.
References
