History of application architectures in an enterprise
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):
- Microservice: This refers to a granular unit of a business functionality that can be independently developed, deployed (as a service), and managed without having a significant dependency on other services around it. It is loosely coupled and is based on the single-responsibility principle.
- Mini-service: This refers to a group or collection of microservices that come together as a unit to solve a specific business functionality. Typically, this group of microservices is deployed on a common infrastructure and shares any underlying database.
- Monolith or macroservice: This refers to the legacy way of building applications, wherein all business services were deployed as a single package on an application server. The components in the system were tightly coupled and have less complexity in both design and deployment. System upgrades were expensive, even requiring downtime.
Note
Refer to the following article to understand more about the differences: https://thenewstack.io/miniservices-a-realistic-alternative-to-microservices/.