The days of gigantic, monolithic programs are archaic; frankly, the complexity of a single-program approach is overwhelming. A modular approach to architecture is, therefore, the clear winner and a logical choice. Modular systems support a work breakdown structure (WBS) of the functionality of a larger system into smaller parts, and good architecture designs use microservices within their architecture to accommodate service-based design principles to accommodate the required functionality.
Modularization is based on the principle of dividing the program into small, discrete modules or units that are independent, nonsequential, typically short in duration, and limited in scope and function. Microservices describes both an approach to software architecture that builds large, complex apps from multiple small components and the term for the small components themselves. In this approach, an application is built with one or more functions that can be called to provide a service to the calling program.
Microservice architecture is comparable to and is a variant of the service-oriented architecture (SOA) program application style, which arranges an application into coupled services that serve one or more functions from the program. In a microservice architecture, services are very fine-grained, rather than monolithic, and the protocols to which the service communicates are lightweight.
The objective of such a structure is to break the whole into smaller, more manageable functions. Loose coupling reduces dependencies, constraints, and complexity, the goal of which is to support modularization and not force system changes onto other components of the system. This modularity approach, along with loose coupling fosters an architecture in which an old version of a microservice can be unplugged from the systems and a new version can replace the old version with minimal if any disruption. This has huge consequences for growing systems that grow fast and are big. Communications requirements and application dependencies are significantly reduced, which promotes service independence. Having multiple interfaces to the same service, or multiple (redundant) versions of the same service minimalize or even eliminate disruptions of existing consumers of the application interface.
A Microservices Approach to Architecture
In the early days of building application programming interfaces (API), entire systems had to be rebuilt or taken offline to implement new versions. This is dated, inefficient, and creates significant risk as change is introduced into the system. If the new API is not compatible with all of the integrations, then there can be consequences to other components of the system, thereby “breaking” other systems and causing the application to fail. This is a prominent cause in system updates and upgrades. They cause the introduction of significant risk if the API is caused to fail. In a microservice environment with multiple, redundant interfaces, this problem is significantly reduced.
Consider the following example.
In the traditional approach, a single point of integration exists in the application programming interfaces. There is one monolithic structure that continues to grow as the application grows. There is but one way to call the function through a single, API. As the system grows so do complexity – and risk. The approach and this model are not sustainable.
In a microservices approach, there are multiple services available. Calls to each of the services may be decoupled and changed to accommodate new functionality without breaking the old functionality. This allows the overall system to grow and to safely increase required changes, assists in managing complexity as complexity grows through requirements and minimizes risk and an acceptable manner. In a microservices approach, the services and integrations are changed to accommodate new functionality. In the traditional approach, everything needs to be considered, and touchpoints for application code become nearly everything in the system.
A Consequence of Traditional Architectures
It goes without saying the value of having an architecture by which customization is controlled through flexible development is immeasurable. Traditional architectures tend to grow to monolithic proportions and quickly get out of control. The consequences are enormous.
The most obvious is that it is not sustainable. As the application grows, so does the complexity. This is normal and not necessarily a bad consequence, but managing the change quickly becomes a nightmare. Often this depends on a system manager’s personal expertise to design changes that are manageable, executable, and can be accommodated. However, more often than not, the system grows out of control, and to a point by which updates, upgrades, and patches no longer become feasible simply because of the complexity and risk of doing so may “break” the system beyond repair.
Managing the Pace of Innovation
Innovation comes by introducing system changes to support innovation. For SAP customers, the adoption of innovative functionality is important to their success as a business. No one would argue that standing still – without development and adapting to market change – accelerates your ability to change and grow with it. During SAP’s history dating back to 1972, they found they were writing great code and providing new functionality, but their customer base found it difficult to keep up with the updates due to traditional architectures.
Then SAP entered into the cloud and began implementing cloud-based services. By moving to the cloud, enterprises could accelerate the pace of innovation and adoption, but only at the expense of customization. Customization of systems and applications became difficult to implement, for fear of reverting back to the complexity of traditional architectures.
SAP wants to innovate with its customers. Customers must adapt to ever-changing market positions and change their systems in order to not just sustain the business, but grow and improve.
The Benefits of a Modular Architecture
There are numerous benefits to such architecture. These include compatibility, independence, scalability, troubleshooting, and lean, agile continuous delivery.
Compatibility
As different points of interaction are considered, they must at some point have contact with the application solution. These must be simple, open – by supporting multiple function calls – and flexible. That’s why most microservice developers use RESTful API services. Uniform protocols and simple methods like GET or POST allow microservices to communicate and exchange information easily.
Independence
First and foremost, is independence. With a microservices approach, development teams operate with more autonomy. Each project group has the freedom to coordinate with other teams, but also to operate independently.
The value is important. Teams can focus on the solution that best fits their own project tasks and not the one by which other teams are constrained. This could imply code changes, database changes, and API changes. In an agile, microservices architecture, each team can work together, or they can work independently, whichever makes the most sense.
Scalability
Microservice architectures provide application developers with the ability to scale down to the minutia of detail. When enhancements are considered, only the project and functions of the service function need to be considered, not the entirety of the application. This makes the project leaner and therefore more agile, saving, of course, both time and cost. It also supports change management by controlling risk in an appropriate manner. Additional functionality can be added by creating new services and application code to support the service. Database changes can take on new context, or new columns or rows can be added to accommodate the new functionality without the need to circle back and change the entire system. In this manner, a system can grow and scale without “breaking” something incidentally.
There are no absolutes here, and of course system changes must be considered as well as limitations, constraints and multi-project dependencies. Yet, microservices promise the hope of greater flexibility and growth with substantially-reduced risk.
Troubleshooting
Another advantage of system independence is that if the service fails, the entire application will not crash; only the service and its associated components may be affected. This also makes troubleshooting much easier. Instead of researching an exorbitant about of code, the issue will be contained within a relatively small, subset of functions.
Lean Agile Continuous Delivery
Continuous delivery is one final benefit since the software is constantly being updated. Microservice architecture gives both SAP and its customers the option of not having to update large portions, and smaller updates can easily be accommodated in a lean agile methodology. It is much easier to manage a service that has one function since it consumes far fewer resources. Contrast that with traditional architectures which can be very expensive, and worse yet, very much high-risk projects.
For this reason alone, SAP has seen that its customers often do not patch, update or upgrade their systems. At some point, customers reach a point of risk saturation in that the system becomes too big and too risky to modify regardless of the need to implement patches and updates.
Lastly, the ability to support multiple projects and multiple teams acting independently improves the efficiency of project completion, as more projects can be implemented of smaller scope, reducing complexity, and risk from change. From a developer’s perspective, new features or bug fixes are less likely given the smaller scope of the service. Changes are quick and therefore become more likely to sustain the overall system stability in the long term.
Architectural Recommendations
Application architecture is simply the organization of a system, where a system includes the sum total of all applications. There can be one or more systems, or the entirety of a section of application solutions can contain multiple systems, working together to form a large system. The system includes all components and how they interact with one another, and the environment in which they operate.
An architectural approach provides a strategy on which a specific mission and overall design are based. It forms the governance of the design and its operating principles to garner the benefits of such an approach. The structure of the design impacts numerous, material decisions, so the considerations are that they are appropriate to support the mission of the enterprise and for the best possible results.
It should be clear at this point the value of modularization of components and microservices, as an architectural design approach. The basic principles of these two approaches provide numerous benefits and are the basis of the highest-level recommendations for a design approach.
Mark Ciminello is Vice President, and Chief Architect with SAP Global Security (SGS), having expertise in cloud, information security, and data privacy. He holds numerous certifications including CISSP (security), CCSP (cloud security) and PMP (project management), has an MBA in Management, a BA in General Studies with an emphasis in accounting, and has some 30+ years of business experience. Recently, he has attended advanced courses at Harvard University.
Disclaimer
© 2023 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.
