A solution architecture is typically the outcome of the bundle of ideas and experiences that you may apply to any specific business and customer context in order to meet a specific vision, within the constraints of timelines and budget availability.
Over the past two to three decades, organizations have progressively invested in building enterprise applications and systems that aim to do the following:
- Provide a competitive advantage.
- Reduce wastage and manual effort.
- Limit costs to improve revenue and profit.
The primary goals have always revolved around a few key priorities, such as improving business processes for greater productivity, timely decision-making ability, and the seamless flow of information across various siloed systems and channels to foster more effective coordination among various departments and personnel within the enterprise.
From monoliths to SOA and microservices
With the evolution of the World Wide Web around early 2000, the adoption of IT within enterprises gained momentum. Information was accessible remotely, thereby opening up new avenues of business collaboration:
Figure 1.1 – Solution architecture trends
Since early 2010, enterprises have started leaning toward mobile apps as their primary channel to offer an online experience to their customers. Over the past decade, there have been tremendous advances in the field of mobile technology, especially with internet connectivity and mobile devices being a viable alternative to desktop computing devices. This has led to a surge in the present-day user-friendly business apps, enabling users to get a job done from anywhere in just a few steps.
Furthermore, the evolution of cloud computing technologies has revolutionized how enterprises plan to deploy their line-of-business (LOB) applications. CNCF and online services (SaaS) served as game-changers for enterprises. The cloud offered the promise of elastic scale, with high performance and availability. This was possible through managed services and scaling on-demand capabilities available on all public clouds. Basically, the cloud provider would manage the underlying server infrastructure to meet the workload demands. This allowed enterprises to modernize their business and work environments.
There was a gradual decline in the traditional development style of building applications, leading to a more microservices-based approach. By making use of this approach, complex and massive distributed systems can easily be broken down into smaller components, also termed microservices.
Microservices are self-contained and can be independently deployed and scaled. These microservices perform just one business function and are relatively easy to change and upgrade without impacting the broader ecosystem of services. This approach allows enterprises to take a more customer-centric approach and react quickly to market demands. The differences between microservices and monoliths are explained later in this chapter.
As was evident in the years that followed, Solution Architecture Blueprints progressively shifted from monoliths to microservices-based architectures, preferably deployed in the cloud. With these changing trends, developers shifted their focus to building robust API platforms comprising granular and loosely coupled microservices, with each service acting as a business sub-system serving a specific purpose within the ecosystem. These API platforms can be easily integrated with, and consumed from, lightweight mobile or web apps.
For your understanding, the following are the differences between microservices, mini-services, and monoliths (or macroservices):