# data[].attributes.attachment_link.readable_text
Many Bitnami applications are available as both Single-tier and Multi-tier packages. Single-tier offerings meet the needs of the majority of users who are just getting started in test or development environments or are looking for small-scale deployments. At the same time, interest in multi-tier application packages which distribute workloads across servers for improved scalability, availability and overall performance is increasing. This document is designed to help users determine which will best fit their needs.

Differences between Single-Tier and Multi-Tier solutions

Single-tier architecture implies putting all of the required components for a software application (both the backend and the frontend) on just one server. This is a good way to test your application in development environments and it is an ideal solution for small sites with low traffic demand which require effective resource utilization. It is handy to manage and maintain and, of course, a Single-Tier deployment is cost-effective.

But having all the resources on the same machine can create an availability and security risk. If the server is down, the application will be down, and it will not communicate with the database. If the server is externally attacked, you are at greater risk of data loss if you do not have a replica of your database.

The typical architecture of a Bitnami Single-Tier Solution looks like this:

Multi-tier architecture solves these problems by splitting data access across more than one server. Having all the resources spread into different servers boosts your deployment performance. In addition to this, having different layers for different resources implies adding an extra security layer by separating data from code. In those applications that include replication, the database can be replicated across more than one server which prevents the loss of data in case of cluster failure.

This architecture also provides high scalability and failover: you can add as many nodes as you need to increase the capacity of your cluster. This way, the workload is also decentralized ensuring that when a node is down, the rest of the deployment is working.

All Bitnami Multi-Tier stacks are production ready following industry conventions: you can move your deployments from development to production in an easy and a reliable way. Multi-tier solutions are a perfect choice to ensure high availability and performance in medium/large size production environments.

Bitnami Multi-Tier solutions features and benefits

High Performance

Extended workloads into different servers provide better performance of the deployments.

Ability to add capacity by increasing the number of nodes in the cluster.

High Availability / Failover

Fault-tolerance: if a node is down the cluster can continue working.

Replication

Replica set is configured by default in those solutions where replication is a must.

Security

Improved security and access control by separating data from code.

Configured to work on a Virtual Private Cloud (VPC).

Authentication configured for external access in most solutions.

Other production configuration features

Log rotation and system monitoring for servers.

Kernel settings and the right disk type for optimal performance are configured by default.

Types of Bitnami Multi-Tier Solutions

Bitnami offers the following types of Multi-tier topologies to better address user needs:

Multi-Tier web applications

The default configuration separates the database (backend) from the application (frontend) in different servers. You can see this application setting in stacks such as Bitnami WordPress Multi-Tier:

Bitnami Jenkins Cluster is an example of these kinds of applications. In this case, the frontend is also separated from the backend and in addition, you can build multiple virtual machines to allow the Jenkins master to distribute workloads:

Infrastructure servers

The default configuration varies depending on the solution you choose. Bitnami follows best practices established by application developers. For example, you can find the typical cluster with replica nodes in Bitnami Cassandra or Bitnami MongoDB with Replication as you can see below:

Another option is the one configured in Bitnami Redis HA where the cluster is comprised of, at least, three nodes: a master node and two slave nodes.

A similar case is Bitnami Kafka Cluster which consists of a three-node configuration that permits selecting a leader inside of the cluster. This topology involves more than one server and multiple infrastructure resources:

Learn more about Bitnami Multi-Tier Solutions

If you want further information on how to install and use Bitnami Multi-Tier Solutions, review the documentation for the following platforms:

To find online support navigate to the Bitnami Community Forums.

# data[].attributes.attachment_link.title
Single-Tier vs. Multi-Tier Architecture: Choosing the Right Bitnami Package

# data[].attributes.attachment_link.description
Many Bitnami applications are available as both Single-tier and Multi-tier packages. Single-tier offerings meet the needs of the majority of users who are just getting started in test or development environments or are looking for small-scale deployments. At the same time, interest in multi-tier application packages which distribute workloads across servers for improved scalability, availability and overall performance is increasing.

# data[].attributes.attachment_link.title
Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)

# data[].attributes.attachment_link.description
This chapter introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems, describing the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, while contrasting them to the constraints of other architectural styles.

# data[].attributes.headline
3-Tier Architecture: A Complete Overview

# data[].attributes.subject
3-Tier Architecture: A Complete Overview

# data[].attributes.attachment_link.readable_text
What is a 3-Tier Architecture?

A 3-tier architecture is a type of software architecture which is composed of three "tiers" or "layers" of logical computing. They are often used in applications as a specific type of client-server system. 3-tier architectures provide many benefits for production and development environments by modularizing the user interface, business logic, and data storage layers. Doing so gives greater flexibility to development teams by allowing them to update a specific part of an application independently of the other parts. This added flexibility can improve overall time-to-market and decrease development cycle times by giving development teams the ability to replace or upgrade independent tiers without affecting the other parts of the system.

For example, the user interface of a web application could be redeveloped or modernized without affecting the underlying functional business and data access logic underneath. This architectural system is often ideal for embedding and integrating 3rd party software into an existing application. This integration flexibility also makes it ideal for embedding analytics software into pre-existing applications and is often used by embedded analytics vendors for this reason. 3-tier architectures are often used in cloud or on-premises based applications as well as in software-as-a-service (SaaS) applications.

What Do the 3 Tiers Mean?

Presentation Tier- The presentation tier is the front end layer in the 3-tier system and consists of the user interface. This user interface is often a graphical one accessible through a web browser or web-based application and which displays content and information useful to an end user. This tier is often built on web technologies such as HTML5, JavaScript, CSS, or through other popular web development frameworks, and communicates with others layers through API calls.

Application Tier- The application tier contains the functional business logic which drives an application's core capabilities. It's often written in Java, .NET, C#, Python, C++, etc.

Data Tier- The data tier comprises of the database/data storage system and data access layer. Examples of such systems are MySQL, Oracle, PostgreSQL, Microsoft SQL Server, MongoDB, etc. Data is accessed by the application layer via API calls.

The typical structure for a 3-tier architecture deployment would have the presentation tier deployed to a desktop, laptop, tablet or mobile device either via a web browser or a web-based application utilizing a web server. The underlying application tier is usually hosted on one or more application servers, but can also be hosted in the cloud, or on a dedicated workstation depending on the complexity and processing power needed by the application. And the data layer would normally comprise of one or more relational databases, big data sources, or other types of database systems hosted either on-premises or in the cloud.

A simple example of a 3-tier architecture in action would be logging into a media account such as Netflix and watching a video. You start by logging in either via the web or via a mobile application. Once you've logged in you might access a specific video through the Netflix interface which is the presentation tier used by you as an end user. Once you've selected a video that information is passed on to the application tier which will query the data tier to call the information or in this case a video back up to the presentation tier. This happens every time you access a video from most media sites.

What Are the Benefits of Using a 3-Layer Architecture?

There are many benefits to using a 3-layer architecture including speed of development, scalability, performance, and availability. As mentioned, modularizing different tiers of an application gives development teams the ability to develop and enhance a product with greater speed than developing a singular code base because a specific layer can be upgraded with minimal impact on the other layers. It can also help improve development efficiency by allowing teams to focus on their core competencies. Many development teams have separate developers who specialize in front- end, server back-end, and data back-end development, by modularizing these parts of an application you no longer have to rely on full stack developers and can better utilize the specialties of each team.

Scalability is another great advantage of a 3-layer architecture. By separating out the different layers you can scale each independently depending on the need at any given time. For example, if you are receiving many web requests but not many requests which affect your application layer, you can scale your web servers without touching your application servers. Similarly, if you are receiving many large application requests from only a handful of web users, you can scale out your application and data layers to meet those requests without touch your web servers. This allows you to load balance each layer independently, improving overall performance with minimal resources. Additionally, the independence created from modularizing the different tiers gives you many deployment options. For example, you may choose to have your web servers hosted in a public or private cloud while you're application and data layers may be hosted onsite. Or you may have your application and data layers hosted in the cloud while your web servers may be locally hosted, or any combination thereof.

By having disparate layers you can also increase reliability and availability by hosting different parts of your application on different servers and utilizing cached results. With a full stack system you have to worry about a server going down and greatly affecting performance throughout your entire system, but with a 3-layer application, the increased independence created when physically separating different parts of an application minimizes performance issues when a server goes down.

Register to See It in Action

# data[].attributes.attachment_link.title
3-Tier Architecture: A Complete Overview - JReport

# data[].attributes.attachment_link.description
What is a 3-Tier Architecture? A 3-tier architecture is a type of software architecture which is composed of three "tiers" or "layers" of logical computing. They are often used in applications as a specific type of client-server system. 3-tier architectures provide many benefits for production and development environments by modularizing the user interface, business logic, and data storage layers.

# data[].attributes.attachment_link.title
5 Benefits of a 3-Tier Architecture - Izenda

# data[].attributes.attachment_link.description
With 3-tier architecture, you have the ability to utilize new technologies as they become available. This ensures your product is ready for the future.

# data[].attributes.headline
Why to use multitier architecture for application development?

# data[].attributes.subject
Why to use multitier architecture for application development?

# data[].attributes.attachment_link.readable_text
A Multi-Tier architecture separates the UI/Presentation, the application and business logic layer, the data access layers, and the database itself in separate applications, potentially running on different computers. In this blog post we'll examine some of the key traits of this architecture and discuss key reasons for adopting this model.
Multi-tier architectures are fairly common these days and they are becoming even more relevant in today's mobile world, given the traditional client/server model doesn't adapt much to lean and remote devices. Multi-tier applications are better suited to accommodate a multi-device world, in which users need to access information from apps running on different devices and different types of connectivity. Multi-tier architectures are certainly not new, but interest in this model keeps growing due to increased use of mobile devices and extended availability of cloud computing.

From One to Three Tiers

In the early days of computing, developers built applications that were running on a single computer. As technology progressed, most non trivial applications migrated towards a client/server architecture. In many cases the server was a database server (or Relational Database Management System: RDBMS), in others it was a server implementing a standard Internet protocol (HTTP, NNTP, SMTP, FTP, ...), and occasionally a custom server with a proprietary implementation.

In this blog post, I will focus on data access so let's consider the client/server scenario. It can be used in two "extreme" modes... with a continuum in between:

Fat Server Scenario. Have a fat server, with the business logic and data processing implemented in SQL, using views, stored procedures, triggers, and all of the wealth of features a database server provides -- and a fairly thin client with only UI rendering of the data and data entry.

Fat Client Scenario. Have a light server, with tables and little more, and have all of the business logic in the so-called fat client, which generally helps improving the quality of the UI and user experience, given data entry can be driven by the data and logic available at the client.

Why does it matter for this analysis on multi-tier? Because it is exactly that business logic layer that you might want to keep on the server, while you implement it with client technologies (like Delphi, or other programming languages).

In a typical 3 tier scenario, you have the database server with limited customization, an application server that accesses the database, processes the data, and provides data to the client, which is just a thin UI layer. These three logical tiers can be three physical tiers (ie, running on separate hardware) or they can be virtual.

Beyond the 3-Tier Model: Modern Multi-Tier

Over time multi-tier and web services have been implemented with different technologies and communication layers. As an example, RAD Studio's DataSnap started by using DCOM and TCP/IP, and later migrated to HTTP and REST. Among the various options, the combination of SOAP and XML was the most popular for a few years.

Modern multi-tier architectures, also known as web service architecture or service-oriented architecture (SOA), favors REST/JSON over the older SOAP/XML approach. We also see a trend in app development that moves from single large monolithic services to smaller focused services federated together (generally called micro-services).

Finally, a modern web service architecture tends to follow the HTTP protocol core tenet of being stateless. Each operation is complete in itself and each new operation doesn't depend on a previous one. This way the services can be distributed flexibly on the physical servers, in multiple redundant copies, for failover and scalability.

Advantages of Modern Multi-Tier

There are so many different ways to define a multi-tier architecture, so I'll focus on a fairly specific scenario, which is taking a "fat client" client/server application and migrating it towards a REST-based web service.

1. Server-Side Business Logic Provides Easier Updates

It is easier to update an application that has the database access and significant part of the business logic on the server, without having to update the client software that is installed on dozens, hundreds or thousands of client devices. For example, if you want to move to a per-customer discount and need to add extra fields in the database, modify SQL queries, and update a price list that depends on the customer, you can probably do this change without updating the client software used for placing orders. You might have to update only the software used for managing the customers and their discounts. Consider that even popular mobile games these days update the game logic from a central location and are heavily based on web services, with user status and progress saved in a central location, but at times even offering a way to play live and in real time with other players.

2. Faster, More Secure Data Access

Originally, one of the reasons for multi-tier was also to reduce the number of the users licences in the RDBMS, but licensing rules have since changed -- so this is rarely relevant these days. Direct database access also causes more dependency on having a proper and updated database client driver (which is not trivial on mobile) and as mentioned above requires a way to update queries in the client application dynamically (or updating the entire client software) as rules and data structures change.

Both for security reasons and performance, unless all of your client applications are on a VPN, granting remote access to the database is generally a security concern. This increases exponentially with clients on mobile devices, using public WiFis or other fairly unsafe scenarios. But even more, direct database access over the Internet is generally slow as the database access protocol are not optimized for low latency and potentially slow and unstable connections. A stateless HTTP access is much more reliable for an Internet and a mobile connection.

3. Better Scalability and Easier Cloud Migration

As your application grows and adds users, you could approach the problem of scalability with mirrored databases and more powerful network infrastructure. This approach requires advanced planning and can become expensive quickly - both in terms of database server licenses and more expensive network services.

Multi-tier architecture offers a less expensive approach through an intermediate tier of web services that absorb some of the network traffic burden. Having additional servers to handle HTTP requests (and any peak in network traffic) is much easier to manage, particularly when deployed to a cloud infrastructure. In other words, migrating a web service architecture to the cloud is generally easier and less expensive, compared to migrating an architecture relying on databases as the primary backend. Even if a database will still be there, if it is not the interface to the clients, this ends up adding flexibility to the system -- despite some additional complexity.

4. Separate the Data Access Layer

From the RAD Studio perspective, the migration of a Delphi or C++Builder client/server application to a multi tier model requires taking your data access layer (possibly hosted in data modules) and moving it to the web service side. The same data access layer you are using in client/server (we prefer FireDAC in our apps) can be used in the middle tier. Now depending on how clean is the separation of your data access code to the UI code (your data modules-to-forms coupling) this migration can be simple or require a significant rewrite.

This is an area we could discuss at length, but a general suggestion is to make sure you reconsider and rethink your architecture. What makes sense on a client (for example, caching a lot of data for future use) might not make sense on the web service, specifically if this is a stateless web service discarding any intermediate data after each individual request is completed. Some developers still prefer a fat middle tier (with an ORM or similar rich object models) but this is not always ideal for a web service, because of its stateless approach (you want to limit the data associated to a user or short-lived session) and the need to access the data model concurrently by multiple threads processing multiple requests by different clients.

So why is this data access layer separation an advantage of multi-tier? Rethinking your application architecture will be an effort, but you can reach the goal of having a more modern, flexible, scalable, and performant architecture, compared to what you started from.

In general terms, avoiding the rich database server model reduces your dependency on the server vendor, so you could potentially switch your database back-end. You can achieve this with either a fat client or a web service. The fat client tends to move a lot of data to the user's machine, while the web service application can run the DB locally and have a huge bandwidth available to access database data.

5. Many Clients, One Service... and Multiple Client Models

A very significant advantage of going towards a multi-tier model these days is the ability to use a single backend service for many different types of client applications. If you have a Windows client/server application today, you can start migrating the Windows applications to the multi-tier model, keeping most of the UI unchanged. Once this is done, you can create mobile or web applications based on the same web service and the same application logic the service already provides.

The mobile clients might be different from the Windows application, and generally "thinner" (less powerful, focused on specific features) but ultimately part of the same application architecture.

6. Caching Data Locally

Adopting this architecture doesn't mean the data lives only remotely. For example, it often makes sense to build UI rich clients that handle data entry or local data processing for your customers. Also, on mobile platforms you might not always have a good quality connection and you might want to save some of the bandwidth cost to your end users.

In all of these cases, a multi-tier architecture can be augmented by caching some of the database data locally on the client.

This might be done by using simple persistent data structures (like a FireDAC MemTable or a ClientDataSet in RAD Studio) or by embedding a full database on the user device (like the embedded version of InterBase, IBLite -- which is free to use for RAD Studio developers).

7. Ability to Build MicroServices and Use Additional Data Conduits

Another advantage of this architecture is the ability to build many web services that work together, rather than a single monolithic piece of software. Individual web services can access different back-end databases, if needed. They can also provide a unified way to access to additional cloud services (for storage, collaboration, and more), without the need for the client to authenticate with all of these services directly. The main advantages are a significant additional security and a way to change some of these services (like moving to a different provider) behind the scenes with no impact on the client application.

One interesting aspect of RAD Server is a single server can load multiple independent runtime packages providing custom APIs. If you have multiple servers, you can combine these APIs freely. But you can also make them all available in a single RAD Server instance if you prefer -- while the development can be focused on one module at a time, in isolation.

8. Migrate Versus Rebuild

Some companies think if they want to go to web service architecture they have to start from scratch. We believe that if you have an existing investment in RAD Studio source code, you can leverage it by migrating the existing code to a new architecture. You can also do it in phases, as this is not an all-or-nothing proposition. A phased migration to multi-tier is an significant advantage of this model. For example, you could take a limited subsystem, create a web service for it, build a mobile application using it, and retrofit an existing Windows application to use the web service as well -- even if the bulk of the application architecture remains based on client/server.

9. A Better Architecture for Mobile

While you might not be keen on abandoning the fat client/server model for desktop applications, consider that mobile applications have unique challenges:

Limited Connectivity

Data processing on server, optimized communication from web service to client. Possibly also local caching.

Limited CPU power

Use the more powerful server-side for CPU-intensive cycles.

Intensive CPU data processing negatively affects device battery

Use the more powerful servers for processing cycles, reducing battery drain.

Higher Risk of Device Loss and Theft

Ability to disable an account on the server and block the application, and get users back up running quickly with replacement devices.

Difficulty Installing and Updating database drivers

No installation required on the user device (mobile but also desktop).

In Summary, It's Worth the Effort

Creating multi-tier applications increases the complexity and adds migration work, but is worth the effort. The ability to open your architecture might be critical, if you want your application to remain relevant in the future and avoid falling behind your competition.

By adopting a multi-tier architecture, as I've discussed, you gain easier updates, faster and more secure data access, better server scalability, a cleaner data access layer, easier migration to mobile platform, and better integration with other available services.

Want to Learn More?

It's easy to add multi-tier logic to your Delphi and C++ applications with RAD Server. Explore our RAD Server videos for examples using REST, web clients, and more. The docwiki provides a technical RAD Server reference. For a high level overview of RAD Server, along with deployment license information, visit https://www.embarcadero.com/products/rad-server.

Note: RAD Server deployment licenses are now included in Enterprise and Architect editions of RAD Studio, Delphi and C++Builder, so if you've got those editions you can get started immediately, as the development tools are also already in the product.

# data[].attributes.attachment_link.title
Build Flexible and Robust Apps with a Multi-Tier Architecture

# data[].attributes.attachment_link.description
A Multi-Tier architecture separates the UI/Presentation, the application and business logic layer, the data access layers, and the database itself in separate applications, potentially running on different computers. In this blog post we'll examine some of the key traits of