Bitnami Content

▼

Wednesday, April 25, 2018

Top reasons to move to multi-tier deployments with Bitnami


Authored by Greg DeRenne, Technical Marketing Engineer

 Introduction

The majority of images available in the Bitnami catalog or any of the Cloud Service Provider’s marketplace (Azure, AWS, Oracle Compute Infrastructure, Google Compute) are single tier architectures. This means that all of the required components run on a single Virtual Machine (VM).

A single VM solution has its benefits:
  • Extremely simple to understand and get started with
  • Cost effective. Depending on the cloud, usage may even fall into a free tier.
  • Quick to deploy (some VM’s spin up in just 2-3 minutes)
In summary, single VM solutions are ideal for development, testing, demonstrations, proof of concept and small scale use cases. 
To meet user demand for larger production use cases, Bitnami has been focused on building out multi-tier solutions. Multi-tier solutions have more than a single VM, and usually include additional infrastructure resources, such as gateways, security groups, load balancers, etc. Multi-tier solutions are ideal:
  • For production use (where higher run costs are justified)
  • When additional deployment options are needed (such as sizing, snapshots, and cloud-native managed services)

Current examples of multi-tier solutions include:



In addition to customer inquiry and demand, several factors influence what stacks we develop multi-tier solutions for. They generally follow into the following categories:
  • Horizontal scaling or high availability through redundancy (Jenkins, Elasticsearch, MySQL)
  • Vertical scaling flexibility and security (Wordpress, MEAN stack)

Knowing the scaling and usage requirements of multi-tier solutions, it’s understandable that they are often more complex and require additional assets and output types.

  

As you can see, a single-tier simply consists of a machine image for the specific cloud. For a multi-tier solution, Bitnami auto-generates the templates needed to build out all resources based on several configuration options you specify at the time of creation. (More on this later.)

The rest of this blog will explain what the top reasons to use Bitnami multi-tier solutions are, and why they matter. Several example multi-tier Bitnami deployments that are already available in the Marketplace will be used to help illustrate the points made. Note that some of the reasons may overlap with single VM solutions. For example, from an end-user perspective, both our single and multi-tier solutions are simple to use. However, the single VM is even simpler. 

Top reasons to consider using Multi-tier over Single-tier solutions

Price


Bitnami application and developer stacks are offered for free to the user, only cloud consumption is paid for. It’s true, single-tier solutions are free from Bitnami as well, and cost less with respect to cloud usage… but as mentioned earlier, there are scenarios that justify the extra run costs. (Such as a production roll out, not a simple demo or proof of concept that only needs to run for a few hours.)

Further, if you consider the age old adage:
“Time is money.” Quoted by just about every business owner… ever.

Price can be more than just a monetary value. There is also time and effort to consider. As you read on, you will learn the complexity under the hood of Bitnami multi-tier solutions shields you from spending a lot of time and effort. How much? It differs from case to case, but it is usually measured in days and weeks, not just hours.

Performance


Improved performance is arguably the most important reason to go to a multi-tier architecture. When the database is split out from the application, the workload becomes distributed. Further, the configuration for each tier can be optimized. For example, if your application is CPU heavy, but light on database read/writes, you can use VMs that are optimized for compute on the application tier, but save money by not incurring extra cost for additional IOPS (input/output per second) and high disk throughput VMs on the database tier. In some use cases, a managed database service (such as Azure Cosmos DB or AWS RDS (Relational Database Service, using Aurora or MariaDB) may be preferred to rolling your own database install on VMs. Cloud Service Providers (CSPs) tackle the most challenging of IT and operations roles for their managed database services, including performance. Several Bitnami multi-tier solutions include managed database services. A good example is deploying a custom Node.js application that uses Azure’s load balancer and Cosmos DB configured for MongoDB.
                                                

Security


The first step in moving from an all-in-one architecture to a multi-tier architecture involves splitting the database tier out on its own. Data is paramount, hence keeping the data secure is critical. Security best practices, many internal enterprise policies, and PCI (Payment Card Industry) compliance require database isolation. A multi-tiered architecture reduces the number of threat vectors to the data. Consider the basic multi-tier architecture for one of the most popular Bitnami application stacks (WordPress):
                                              
By default, firewall rules do not allow any remote access to the database, only access from the VMs in the data tier. However, the application tier allows external traffic to ports 22 (SSH), 80 (HTTP) and 443 (HTTPS). If that does not meet with your more robust security policies, not to worry, you are not without options. Simply modify the inbound firewall rules to turn off SSH access to the application tier. Some enterprises set up a dedicated management VPC (virtual private cloud), that includes a bastion host. Hence, remote access via SSH must go through the bastion host. That VPC and bastion host can be closely monitored, and restricted to a list of source IP addresses as well, greatly reducing the potential for a data breach.

Bitnami multi-tier solutions are more secure by default, and our images are monitored and updated, especially when it comes to security patches.
Availability

A discussion about availability often includes reliability and redundancy as well.

The Node.js deployment discussed earlier also utilizes a managed database service. Azure’s Cosmos DB is a reliable, available, high throughput database service with geo-replication capabilities. Nice!

                                                  

Note the write region is in the western U.S., and a read replica in the eastern U.S. This was configured at the time of creation, but it can be modified or added to later. Setting up a highly available, reliable, redundant and high throughput solution for your data like this is no small task. The majority of small and medium sized companies, even some larger enterprises, simply don't have the resources to design, configure, and maintain such an endeavor. The Cosmos DB service level agreement (SLA) offers 99.999% high availability. Bitnami has taken this into account when designing the Node.js HA cluster deployment for Azure.

From the application perspective, high availability is achieved through a load balancer sitting in front of multiple front-ends running your application.

Simple and includes Best Practices


There is no simpler way to roll out production ready, secure, reliable, performant application and development stacks than Bitnami’s multi-tier solutions. To help illustrate this, recall the Node.js application with load balancing on the front-end and MongoDB on the backend just discussed. When you click “create”, the following assets are generated for you by Bitnami via an Azure Resource Manager (ARM) template:

                                             

The Bitnami auto-generated ~1,000 line template used to create all resources is available for download and modification if needed. In addition to creating the resources, many best practices specific to the application are also included in the template. For example, various permissions, ports, enable/disable authentication for servers, etc. Once the VMs are up and registered with the load balancer, browse to the public IP and your good to go.

As another example, take the Kafka cluster on Google Compute.

                                           
Rather than configuring and launching a Zookeeper cluster, then multiple Kafka brokers on top of that, Bitnami generates the templates needed to configure the entire deployment. You can choose the number of Zookeeper and Kafka nodes to include with your cluster. The default values include a 1-node Zookeeper cluster with a 2-node Kafka cluster (as shown from a partial Deployment Manager (DM) template and the Google Cloud console):

                                                     

Not to be forgotten, all of the multi-tier solutions available in the cloud marketplaces are built on the back of years of experience. They include extensive acquired knowledge baked in as best practices.
  • Unmatched experience building, packaging, deploying, and updating images (1000’s of builds and updates every month)
  • Stacks deployed over 1M times per month
  • 120+ applications and development stacks available
  • Stacks utilize cloud-native resources and managed services (when it’s best to do so)

“Make no mistake, you can only achieve simplicity through a lot of hard work.”  - Clarice Lispector

Let Bitnami’s hard work and proven best practices simplify rolling out multi-tier architectures in the cloud for you.

Next Steps

Take a multi-tier application or development stack for a test ride! Check out the Bitnami documentation on multi-tier solutions, the Bitnami Engineering blogs, and visit your favorite Cloud Service Provider’s (CSP) marketplace and search for: Bitnami Multi-Tier (or in some cases Bitnami Cluster)

Azure Documentation 
Amazon Documentation 
Google Documentation