Below you will find several sample diagrams of cloud-based solution architectures that you can build with the World Cloud Hosting platform using Datacenter as a Service infrastructures. Most of these architectures can be built using existing Templates.
Each application is unique and will have a custom set of requirements. The purpose of the system architecture diagrams below is to provide you with real-world examples that you can use as base reference architectures when you design your own custom system architectures in the cloud. Once you find a system architecture that is similar to what you are trying to build, you can modify and customize it accordingly to meet your own project's requirements. The diagrams are designed to demonstrate a particular concept such as disaster recovery or multicloud deployments. When you are designing your own solution architectures you should consider integrating several of the concepts described below.
Here are several factors that you need to take into consideration before designing your own Datacenter as a Service architecture, particularly if you're considering a multi-cloud/region architecture.
Cost - Before you architect your site/application and start launching servers, you should clearly understand the SLA and pricing models associated with your cloud infrastructure(s).
Complexity - Before you construct a highly customized Datacenter as a Service solution architecture, make sure you properly understand the actual requirements of your application, SLA, etc. Simplified architectures will always be easier to design and manage. A more complex solution should only be used if a simpler version will not suffice. For example, a system architecture that is distributed across multiple clouds (regions) introduces complexity at the architecture level and may require changes at the application level to be more latency-tolerant and/or be able to communicate with a database that's migrated to a different cloud for failover purposes.
Speed - The cloud gives you more flexibility to control the speed or latency of your site/application. For example, you could launch different instance types based on your application's needs. For example, do you need an instance type that has high memory or high CPU? From a geograhic point of view which cloud will provide the lowest latency for your users? Is it necessary or cost effective to use a content distribution network (CDN) or caching service? For user-intensive applications, the extra latency that results from cross-cloud/region communication may not be acceptable.
Cloud Portability - Although it might be easier to use one of the cloud provider's tools or services, such as a load balancing or database service, it's important to realize that if and when you need to move that particular tier of your architecture to another cloud provider, you will need to modify your architecture accordingly. Since Templates are cloud-agnostic, you can use them to build portable cloud architectures.
Security - For MultiCloud system architectures, it's important to realize that cross-cloud/region communication is performed over the public Internet and may introduce security concerns that will need to be addressed using some type of data encryption or VPN technology.
The architecture diagrams below show a progression from simple to more complex reference architectures.
Use the Stand Alone Datacenter with LAMP (Linux, Apache, MySQL, PHP) to launch a single cloud that contains a web server (Apache), as well as your application (PHP) and database (MySQL).
In a standard three-layer website architecture, there is at least one dedicated server in each tier of the system architecture. (Load Balancing Server, Application Server, Database Server)
If you are only testing the interactivity between each tier of your architecture, you may want to use a non-redundant system architecture to save on costs and resources. Since it is a non-redundant system architecture it is primarily used for basic test and development purposes. In the example diagram below, there are dedicated servers for each tier of the application/site. A non-redundant architecture is not recommended for production environments.
Any production environment that is launched in the cloud should also have a redundant architecture for failover and recovery purposes. Typically, you will use a Server Array for your application tier to take advantage of autoscaling in the cloud, however there may be some scenarios where your application is not designed to autoscale. In such cases, you can still create a redundant multi-tier architecture where you have redundancy at each tier of your reference architecture. In the example below, there are two load balancer servers, two application servers, as well as master and slave database servers. A redundant architecture will help protect your site/application from system downtime.
This example diagram also demonstrates the use of a striped volume set at the database tier. If your database is large and requires faster backups, you may consider using a set of striped volumes for data storage.
If your cloud infrastructure supports multiple datacenters (or zones), it's recommended that you spread your system architecture across multiple datacenters to add another layer of redundancy and protection. Each datacenter in a cloud is designed to be an isolated segment inside the same geographical cloud. So if a power failure occurs in one datacenter, the other datacenters will be unaffected. The benefit of using multiple datacenters is to protect your entire site/application from being negatively affected by some type of network/power failure, lack of available resources, or service outage that's specific to a particular datacenter.
As a best practice you should always leverage multiple datacenters in your reference architecture if they are supported by the cloud infrastructure.
One of the key benefits of the cloud is the ability to horizontally scale (i.e. grow or shrink the number of running server resources) as the demands of your application/site change over time. With World Cloud Hosting, you can use Server Arrays to set up a particular tier of your architecture to auto scale based on predefined alert conditions. Auto scaling is most commonly used for the application tier of your cloud reference architecture.
If you do not want to use a Master-Slave MySQL setup, you could also use Membase (Couchbase) nodes for your database tier, which is a distributed NoSQL database, which replicates data across all of the Membase nodes. If you are using the Enterprise edition you can attach volumes to each node (shown below), but the Community Edition doesn't support the use of volumes.
For applications/sites that require lots of reads from the database and serve a lot of static content, you might want to add a Memcached layer to your cloud system architecture to offload a read-heavy database. Memcached is an open source distributed memory object caching system that's ideal for speeding up dynamic web applications by alleviating database load. In the example diagram below, the application servers can still make writes to the database, but many commonly used objects will be retrieved from one of the Memcached servers instead of the Master-DB server.
Another way that you can protect your site/application in the cloud is to design a hybrid cloud site architecture that leverages multiple public/private cloud infrastructures or dedicated hosted servers. One of the key benefits of the World Cloud Hosting platform is cloud portability, where you can use the same assets to launch identically functioning servers into multiple public/private clouds. Avoid cloud lock-in and design a solution architecture that takes advantage of multiple cloud resource pools instead of just a single cloud. Similarly, you can also design a hybrid cloud architecture where servers in a cloud can communicate with dedicated servers that are hosted in an internal/external datacenter.
In the example below, you're using one cloud infrastructure to host your site/application, but you've also set up a Server Array for auto scaling your application tier in a different cloud infrastructure. For example, you might use your own private cloud servers before incurring any costs associated with launching servers in public cloud infrastructures. The MultiCloud Architecture diagram below gives you the flexibility of primarily hosting your application in your private cloud infrastructure but also auto scale out into a public cloud for additional server capacity, if necessary.
In the example diagram below, the same Server Templates and scripts are used to configure and launch functional servers into either Cloud X or Y. When you are designing your cloud system architecture across multiple clouds, there are several factors that you will have to take into consideration. In the example below, there is a running Slave-DB server that's serving as a "warm" backup, but it's replicating data with the Master-DB across the public, not private IP address. Remember, only servers within the same cloud infrastructure can communicate over a private IP address. However, if there is ever a problem or failure that would require you to switch clouds, a MultiCloud Architecture would allow you to easily migrate your site/application. Notice that the other tiers of the reference architecture have already been configured and are ready to be launched if you need to migrate your production environment from Cloud X to Cloud Y. It's important to remember that the clouds could be any combination of public/private cloud infrastructures that are enabled in a World Cloud Hosting account.
If you want to send/receive data in a secure manner between servers in two different clouds, you can use data encryption or a VPN wrapped around the public IP address since any data transmitted between different cloud infrastructures (except if they're both private clouds) is sent over the public IP. In the diagram below, data replication across the public Internet is sent between the servers in two different clouds over a secure VPN tunnel.
One of the key benefits of the World Cloud Hosting management platform is that you automatically gain a multi-cloud disaster recovery solution simply by following best practices with our ServerTemplates. Remember, no cloud is disaster-proof. Servers and services will eventually go down so it's important that your system architecture is structured to handle various different disaster recovery scenarios. For example, what would happen if there was a sudden outtage in the cloud in which your production environment is currently deployed? In the traditional dedicated hosting model, you are at the mercy of your service provider because your only option is to wait for your hosting company to fix the problem and get your servers back to an operational state. But in the cloud, if you have architected your site appropriately, you have the ability to respond immediately and recover your site yourself. For example, if you have launched your production environment using World Cloud Hosting's published ServerTemplates, you'll be able to use those same ServerTemplates to launch identical servers across multiple clouds. So, if there is a major service outtage in a cloud (e.g. AWS US-East), you can rebuild your production environment by launching servers into a different cloud/region. If you're currently deployed in an AWS region using bundled AMIs and are not using ServerTemplates, you will not be able to perform any of the disaster recovery operations described below.
The diagram below demonstrates two types of disaster recovery solutions that are available exclusively through the World Cloud Hosting management platform.
In this example, snapshot backups are taken periodically by default, but you can also take manual LVM backups of the database. So, if you need to perform a database migration or there is a cloud outtage, you can use the LVM backup to relaunch your database server into a different cloud/region. Once the database server is operational using data from your LVM backup, periodic backups of the database will continue. Note: The diagram currently shows a database server using a volume for database storage, but you can also store the database locally on the server. In this example, an LVM backup is stored in a different cloud storage option (e.g. RackSpace Cloud Files Container) and is used to restore the database on a new server that's launched into a different cloud (e.g. Rackspace Cloud Servers). Once the database server is operational, periodic backups of the database will continue.
Note: Currently, ServerTemplates that perform these operations are in beta.
Another type of hybrid cloud solution architecture is to leverage a public/private cloud's resources along with existing servers from an internal or external datacenter. For example, perhaps your company has strict requirements around the physical location of your database server because it contains sensitive user information or proprietary data. In such cases, even though the database cannot be hosted in a cloud infrastructure the other tiers of your application or site are not subject to the same levels of restrictions. In such cases, you can use the World Cloud Hosting platform to build a hybrid system architecture using a virtual private network (VPN) solution to create a tunnel for secure communication across a public IP between cloud servers and dedicated servers.
Server Hosting
Web Hosting
E-shop
Domain Names
