Software Architecture Styles
Following the “software roadmap” that I’ve started to outline, inspired by this Medium article, the next step is to think about software architecture styles. Software architecture, which is named aptly, refers to the fundamental structures of a software system and the discipline of creating those structures. Each structure includes software elements and the relationships between them, as well as the properties of the elements and the relationships. And since software architecture is the fundamental organization and plan for the code, it is extremely difficult to modify after starting work, so it is an incredibly important part of the process to take into consideration. There are many styles of software architecture, each with its own advantages that teams should take into consideration when making the blueprints of the project. These styles tell software engineers how to organize their code, to the highest level of granularity and specifying layers, high-level modules of the application, and how those modules and layers interact. Like general architectural styles, they are reusable 'packages' of design decisions and constraints that are applied to an architecture to induce chosen desirable qualities, and each style has distinguishing aspects.
A popular style of software architecture is Monolithic, or Monolithic Application. A monolithic application is traditional and simple, built as one single unit. It’s single-tiered, and combines the user interface and data access code into one program from a single platform. It’s also self-contained and independent from other applications, which was an intentional design feature meant to ensure that the application can perform every step necessary for a specific function. While monolithic applications still exist, most teams choose to go with another software architecture style because monolithic applications don’t have modularity, a desirable feature that supports reuse and modification or maintenance, but it is still a fundamental and important style of software organization.
Another style is SOA, or Service-Oriented Architecture. As opposed to Monolithic Application, where the entire application is self-contained and self-reliant, SOA is designed so that services are provided to the other components by application components, through a communication protocol over a network. A number of services communicate with each other, in one of two ways: through passing data or through two or more services coordinating an activity. SOA is pretty abstract, so the specific characteristics themselves vary team-to-team, but some core values include Business value, Strategic goals, Intrinsic inter-operability, Shared services, Flexibility, and Evolutionary refinement. These values bring important benefits and improvements from traditional closed styles of development, as it allows for re-usable code and easier modification/maintenance because everything runs through one interface, it promotes interaction due to its standard form of communication, it makes scalability easier since it cuts back on client-service interactions, and it reduces cost.
A subset of SOA is Microservice architecture. In Microservices, the application is arranged as a collection of loosely-coupled services. True to the “micro” description, there are lightweight protocols and fine-grained services. Similar to the SOA, and most software terminology in general, there is no true definition of Microservices. However, in general, services in a microservice architecture (MSA) are often processes that communicate over a network to fulfill a goal using technology-agnostic protocols such as HTTP, organized around business capabilities, can be implemented using different programming languages, databases, hardware and software environment, depending on what fits best, and are small in size, messaging-enabled, bounded by contexts, autonomously developed, independently deployable, decentralized and built and released with automated processes. Again, some of the benefits are its modularity, which makes the application easy to understand, develop, and test, is scalable due to its independence, and numerous other benefits that come with SOA.
The last style of Software Architecture that I’ll discuss in this post is Serverless architecture. Serverless architecture is is a software design pattern where applications are hosted by a third-party service, eliminating the need for server software and hardware management by the developer. Applications are broken up into individual functions that can be invoked and scaled individually. From its description, it’s evident that Serverless architecture isn’t truly “server-less”- instead, it’s named that since the team doesn’t need to actually purchase or rent servers for the back-end code to run on, they can just use a third-party application (a common one being AWS). Serverless is very convenient, as it can be used in conjunction with other styles of architecture like microservices (part of an application can be written in microservies and the other part in serverless), and there won’t be any errors. It also saves time, energy, and money, since developers don’t need to address the complexity of building and maintaining the infrastructure themselves- they can just pass the burden along to the third-party providers.
These styles of architecture are three of the most common and generally beneficial styles, though there are a plethora of styles left out of this post. Just like the Development methodologies, development principles, and the programming principles, the software development team has a ton of different options to choose from, and needs to make an informed decision based on which styles provide the best possible organization for whatever their product is.