Many software businesses starting out today benefit from being cloud-native, API-first and composable. These are core qualities of modern tech stacks because developer friendliness is good for business and these aspects drive business. Let us take a closer look at these aspects of web architectures.

The rise of the cloud manifested in microservices development and while the initial step was about squeezing web applications into containers, most took the next step to embracing composable web architectures. This evolution emphasizes modularization, flexibility, and re-usability of components. The way people went about it was to take an axe to the front-end, backend and data sources to split them into components that could develop, scale and be tested independently, especially with a perspective for combining or replacing as needed. This reduced development time to releases significantly and tremendously helped with integration of new services. The flexibility of the technology stack freed us from the vendor lock-ins. It also put pressure on the vendors, specifically the established ones to offer more out of the box that could be weighed in trade-offs against “rolling your own”. One of the overlooked components of this split but held a significant promise in observability and telemetry was the runtime component with other components pertaining to frontend, backend or data. This component alone focused on finding the right environment for the technology choices made by the other teams to ensure the availability, stability and security of the system. Its main stakeholders are the operations teams.

As with any trends in process or practices, roles start to emerge to take care of different components. Choices that were made for the programming language, speed of development, ease of deployment or ease of use tends to become local and less interfering with others, something that monoliths lacked. Business choices that were impeded by technology could now avoid conditionals, branches and partials that proved frustrating and could now be made with an intent to reach the market with value propositions faster. A single stakeholder such as online marketing and their choice of data management system was now bound in scope, spread and timeline. Campaigns including creating, editing and publishing could be realized faster, tracked and closed with a set of disposable or re-usable artifacts. Processes and workflows including those pertaining to campaigns could now be leveraging the same versioned releases of data or content. In a headless mode, apis did the communication with no need for administration or presentation while allowing them to be added on independently and where appropriate. This way of organizing into headless and decentralized system provide the main point for composition. The application layer could then be distributed into single-purpose services which come with modularity, scalability, resilience, lightweightedness and programmability. These architectural properties allow you to maximize on Consistency, Availability and Partition tolerance which is bound by CAP theorem that says only two of these three guarantees can be picked for distributed data access.