Comparing Cloud Platform to virtual private infrastructure¶

Cloud Platform provides more than just virtual private infrastructure. It is a carefully designed, configured, tested, deployed, and crafted open-source platform optimized to run highly available Drupal applications that meet modern security and compliance standards.

Your Cloud Platform infrastructure may consist of a single dedicated virtual infrastructure, multi-tenant infrastructure distributed across one or more virtual infrastructure or one or more dedicated virtual infrastructure. Each Cloud Platform environment runs the same versions of each element of the platform:

• Linux operating system
• Apache infrastructure
• MySQL database
• PHP (multiple versions available)
• nginx reverse proxy load balancing infrastructure
• Varnish® cache

This standardization enables Acquia to efficiently provision, test, manage, monitor, and upgrade the platform. As a result, you cannot select and install your own versions of the operating system, infrastructure, or other platform software your application runs on. For more information about what is installed on Cloud Platform and what software is and is not supported, see Cloud Platform technology platform and supported software.

With Cloud Platform, you have the following permissions:

• Non-privileged access to your infrastructure using SSH, using a public key you register with your Cloud Platform user account.
• No root or sudo permissions.
• Full control over the Drupal docroot, including Drupal core, contributed and custom modules, and the infrastructure’s .htaccess files.
• No write permissions for php.ini,my.cnf, or Apache configuration files.

Code, databases, and files¶

The key components of a Drupal application are the code, databases, and files.

• The code is your Drupal core installation, any contributed or custom Drupal modules you have installed, and themes.
• The databases store your application’s content, configuration, and other information, including Drupal nodes, user information and log information.
• The files store user-uploaded objects, such as pictures and PDF files.

The Cloud Platform workflow enables you to manage your application’s code, database, and files separately in your development, staging, and production environments. For more information, see the following pages:

• Working with code
• Working with databases
• Working with files

Multiple environments: Local, development, staging, and production¶

Each Cloud Platform application has three (or more) environments to optimize your application development and publishing workflow:

• Local - In the local environment, you develop your application locally, and see the effects of your changes immediately. With version control, multiple web developers can work simultaneously on different parts of the application.
• Cloud IDEs - Provide you with a remote, cloud-based URL that can be used for live development and debugging operations. For more information, see Cloud IDE.
• Development - When you have multiple developers working on an application, the Development environment is for initial integration testing. The developers commit their changes to the version control system (VCS), Cloud Platform deploys the changes in the Development environment so that everyone can see them. Alternatively, for environments running on Classic Cloud infrastructure, you can enable the Live Development feature, and edit your code directly in your development or staging environment.
• Staging - In the staging environment, you can test changes to your application before deploying them to Production.
• Production - Your end users see only your Production environment. You can pull your application’s database and files from your production environment to your non-production environments, so you can work with the current state and content of your application as you test and develop it.

Cloud Platform provides a separate infrastructure of your databases and file directories for each of your application’s environments. For environments running on Cloud Classic infrastructure, the Cloud Platform include file for your application configures your settings.php file to connect each application to its correct database infrastructure and files directory.

Cloud Platform Enterprise subscribers can set up additional environments. Additional environments are useful for integration or load testing, and may also enable Cloud Platform to fit better with your development workflow.

Developing code locally or in the Development environment¶

Cloud Platform supports three models for developing code: local development, Cloud IDEs, and live development.

• Using local development, you develop your application locally, using a local checkout of your Cloud Platform repository, and then commit to your codebase.
• Cloud IDE provide access to a remote development environment designed to work similar to a Cloud Platform workflow environment.
• Using live development, you develop your application on your Cloud Platform non-production environments.

Dynamic auto-scaling in Cloud Next¶

Cloud Next is powered by Kubernetes-managed clusters and advanced file system and database management technologies that leverage pooled resources across hundreds of containerized and virtually isolated environments. In addition, it allows production environments to leverage the full capacity of an entire regional cluster, if necessary, to respond to spikes in traffic or other forms of high resource utilization.

In Cloud Next, non-production environments are permitted to scale up to a predefined point before additional resources stop getting allocated. This limit is lower than the limit in the production environment. Therefore, you must not use non-production environments for load testing or any other activities that might result in more traffic. However, if you use non-production environments for such activities, the environments react negatively with slower responses or elevated error rates as compared to similar levels of traffic in the production environment.

Production environments are also permitted to scale up to a predefined point above the expected amount of cloud capacity, required to satisfy the level of traffic, associated with a given subscription. However, in the unlikely event that any production environment nears that threshold, Acquia Support will step in to audit the activity on your account and determine if additional auto-scaling can be permitted or if some form of intervention is required to reduce utilization back to normal levels. For example, if your site is under attack or inadvertently consumes more resources than expected.

Once a spike in resource utilization subsides, all environments in Cloud Next automatically reduce the amount of dedicated capacity to make it available to the regional pool once more.

Version control and multiple environments¶

Cloud Platform enforces the use of a version control system to efficiently manage your codebase. Acquia supports the Git VCS. When developing locally, you send changes to your application’s code on Cloud Platform using version control software, instead of copying the files directly using file upload tools, such as FTP. Following these best practices leads to more efficient, more flexible, and less error-prone development and deployment.

Any environment can deploy any branch or tag from your code repository. An environment deploying a branch immediately receives any code committed to that branch. When committing your code to your branch (for example, master), your changes deploy immediately.

Debugging your application¶

If your application is on Cloud Platform Professional, you are responsible for managing your application, while Acquia manages your infrastructure. Successful application management requires you to perform the following basic debugging tasks:

• Viewing application logs to review PHP and Apache errors, PHP and Apache activity, and MySQL slow query data.
• Running basic Drush commands from the command line, such as drush status, to retrieve error messages for debugging applications that may be offline

Load balancing¶

Cloud Platform uses nginx for HTTP and HTTPS load balancing. To guard against load balancer failures, Acquia uses a redundant load balancer configuration, with an active load balancer backed up by a passive load balancer. If the active load balancer fails, the passive load balancer is available to take over.

Environments with TLS (SSL) certificates installed using the Legacy (ELB) method operate with load balancers in an active-active configuration.

Acquia’s operational infrastructure constantly monitors all load balancers (and the websites behind those balancers) to ensure they are accessible, reliable, and reachable. When Acquia’s monitoring system detects an error, it immediately alerts Acquia’s 24x7 operations staff. Acquia will then determine the reason for the failure, which can include high website traffic, a denial-of-service attack, or infrastructure failure. Depending on the type of failure, the passive balancer is brought online within minutes.