Software Architecture
“Architecture is about the important stuff. Whatever that is”
Software Architecture is the founding stone for any project. It is the set of principal design decisions made at the start of the project, the blueprint for a software system’s construction and evolution. It describes the system’s major components, their relationships, and how they interact with each other.
Let’s start with understanding how Software Architecture has evolved over the years.
Earlier in the 1990s, codes were organized as spaghetti with very little structure given to the whole product. Over the next decade, the structure was improved and codes were arranged in layers like lasagna. In recent times, a lot of push has been towards a ravioli-oriented structure, which is a bundle of many self-contained items. If you want an Indian equivalent, it started with sevaiya /maggi— everything tangled, then went to layered biryani — it’s big but structured and now they are like Kofta curry — each kofta complete in itself and the whole dish, taken all at once, is amazing.
Monolithic
The layered structure, used by most of the companies then in the 2000s refers to the Monolithic structure. Here, the software is built as a single unit. Any new feature is added to the core software. With every feature addition, the codebase becomes more and more complex, increasing the testing requirements to ensure no adverse impact on any other functionality. This complexity makes further development processes very slow. Monolithic software is like a baby elephant: cute and fun when they are little, but difficult to steer and resistant to change when they get big. But if you are sure to have a limited user base, it makes sense to build a monolithic structure, as it is simple to build and quick to launch.
Microservices
The latest in the evolution, currently preferred by most of the large technology companies, is the Microservices architecture. Amazon, Netflix, Spotify, Uber, all have transformed their base structure from Monolithic to Microservices. Here, instead of building one big program, developers create a number of different tiny programs that are bundled together as one service. These programs connect with each other via an application programming interface (API), i.e., some tightly-controlled set of rules that both programs can handle. These collections or programs can be independently developed, deployed, and maintained, as long as it is ensured that they play well with the API.
Consider an example of Netflix. It uses around 700 microservices to control each of the many parts of what makes up the entire Netflix service: one microservice stores all the shows you watched, one deducts the monthly fee from your credit card, one provides your device with the correct video files that it can play, one takes a look at your watching history and uses algorithms to guess a list of movies that you will like, and one will provide the names and images of these movies to be shown in a list on the main menu, and more with other functionalities. Netflix engineers can make changes to any part of the application and can introduce new changes rapidly while ensuring that nothing else in the entire service breaks down.
Some more architectures
While the ones discussed above are two ends of a spectrum and commonly used architectures, there are many more architecture patterns designed and documented for varied use-cases. These patterns help as a reference point for future work, to align one’s designs with what has been successful in the past. A live application may have one of the specific patterns as its base structure or it might be a mixture of two or three or even more, given the business use case. Some more examples of Software Architecture patterns are:
Event-driven Architecture — Many programs are triggered only after a specific event takes place. This structure has a central unit that accepts all triggers/data and delegates them to respective programs handling that trigger. For example, every time you click on the mouse, it generates a trigger for the respective Javascript code to run at the backend for the intended action to take place.
Layered/ Multi-tier Structure — This is one of the most common structures for enterprise software systems, as it is built with a database at its base, and many business applications have data storage as their prime function. Usually, a three-layered architecture is used: a client-side user interface, a database, and a server-side application. Here, each layer in the structure is a monolith, has a different task, and can be managed by different programmers with access limited to specific layers. This is a useful feature where data protection is an important concern.
Microkernel Architecture — Consider the famous Dell customization offer when buying laptops. It has a core hardware over which you can select and drop features to get the final output as per your choice. Similarly, in Microkernel Architecture, as the name suggests, there is a central core part in the system. Multiple standalone, separately managed plug-ins with different features based on business use-case can be added to this core to form a variety of products. This is an ideal structure for applications with a fixed set of core routines and a dynamic set of rules that must be updated frequently.
The architecture makes everything float. You decide it right, you are done with half the job. You do that poorly, it takes everything down. As it is said, “The captain goes down with their ship ” — it also applies to engineers and architectural decisions. So without a doubt, these are the decisions you would want to get right early in the project.
Govinda Nathani
IIM Calcutta (2019–21)
