When architecting MuleSoft applications, you’ll often hear about “the three layers.” This concept is widely recognized among both technical and non-technical users, including sales executives who frequently highlight the importance of the three layers.
So, what are the three layers, and how do they apply to the API world?
Three Layers in History
The three-tier architecture might sound familiar if you’ve ever designed client-server applications. This architecture divides applications into three logical tiers: the presentation tier (or user interface), the application tier (where data is processed), and the data tier (where data is stored and managed).
Developed by John J. Donovan of Open Environment Corporation in the early 1990s, the three-tier architecture became widely adopted due to its separation of concerns. This separation enhances maintainability, scalability, and flexibility in applications.
Moving Forward
Moving forward into the future, the three-tier architecture influenced many modern architectural patterns, such as service-oriented architecture (SOA) and microservices. One of the early adopters in the context of SOA was Amazon. Amazon’s transition to SOA began in the early 2000s, significantly influencing the evolution of SOA and later microservices.
By breaking down monolithic applications into smaller, more independent services, it allowed for greater flexibility to accommodate the constant changes being passed down by businesses through regulations, compliance, and market demands. This laid the groundwork for what would be later known as microservices architecture.
Another early adopter is Netflix, which transitioned to a microservices architecture in 2009 prior to the name being coined. Early microservices for Netflix were written in Java. Additionally, Netflix developed several open-source tools and frameworks to support its microservices architecture, which have become widely used across the industry.
Introducing MuleSoft
MuleSoft “Mule” started in 2006 as an open-source software project and quickly grew. It wasn’t until around 2015 that they introduced “API-led Connectivity”. Building on the same concepts as SOA, API-led Connectivity is a microservice approach built on three layers. Much like the client-server architecture, the experience layer allows different users or channels (i.e., mobile apps, web interfaces), the process layer consists of business logic and data orchestration, and the system layer connects to core systems of records and data sources.
The main difference between the three layers and the three-tier architecture is that the three layers are used for the integration of systems, whereas the three-tier architecture is used for client-server applications. This means the entry point of data for the three layers is a microservice or API (Application Programming Interface), whereas the entry point for the three-tier architecture is a user interface.
The Application Network
The motivation behind using microservices is the ability to adapt to change quickly and effectively. The application network is a way to connect applications, data, and devices through APIs that expose some, or all, of their assets and data on the network. Building an application network involves developing reusable assets and encouraging those in the business to reuse and self-serve said assets.
The layers provide a logical way to organize those assets in an application network, preserving fundamental principles of maintainability, scalability, and flexibility.
The principles of API-led Connectivity are not exclusive to Mule. These principles go back in history and are well-socialized and accepted as the best practice when designing any type of system. If you’re talking about an application network, you could find the layers go even deeper than three layers, depending on what business case you’re trying to achieve. In the 1990s, this was referred to as an “n-tier” architecture.
Summary
The main thing to understand is that what we do often is tried and tested historically. It’s a blueprint for what works, regardless of the language it’s written in, the runtime it’s running on, or even the audience it serves. It’s crucial for learning, efficiency, risk management, and overall improvement in the quality and robustness of software systems. The “three layers” leverage proven solutions and carry them forward with a fresh take using microservices.
