Cloud Platform versions
This page details the FAQs that are specific to Cloud Next.
Note
Acquia began upgrading customer applications to Cloud Next on 24 March 2021. Cloud Next technologies provide better performance, scalability, and resiliency during high load. Powered by advanced serverless architecture, Cloud Next ensures applications can scale faster to satisfy the demands of high traffic events and resource intensive processes.
For more information about Cloud Next and to learn how it differs from Cloud Classic, see Cloud Next and Cloud Classic.
Important
FAQs about upgrading to Cloud Next
What are the benefits of Cloud Next?
Cloud Next provides you an enhanced platform experience where Acquia’s Kubernetes-first architecture ensures maximum performance and resilience. For more information about the key benefits of Cloud Next, see Key benefits of Cloud Next.
When will Cloud Next be available to me?
Acquia Cloud Enterprise
Acquia is committed to provide access to Cloud Next technologies to all Cloud Platform customers as early as possible. Cloud Next is available to all new and existing Acquia Cloud Enterprise customers with compatible applications. However, Cloud Next has a few limitations.
Acquia Cloud Professional
Acquia Cloud Professional applications will gain access to Cloud Next technologies in 2024.
Site Factory
Site Factory applications will gain access to Cloud Next technologies in 2024.
What happens during the upgrade process?
The detailed steps for the upgrade process in both production and non-production environments are listed in the Upgrading to Cloud Next section.
Can Acquia provide me the exact date and time of my upgrades?
Maintenance windows for Cloud Next upgrades follow Acquia’s standard maintenance procedures and take place during each hosting region’s designated “dark hours” slot, which is 11:00 PM to 7:00 AM infrastructure local time.
Acquia assigns environments to these maintenance windows based on multiple factors, including the application’s size and configuration. Cloud Next upgrades involve multiple factors such as the nature of upgrades and the number of environments being upgraded every night. Therefore, Acquia cannot provide an exact start or end time for your specific environments. You receive an update in your maintenance notification ticket on completion of the maintenance event.
How long does the upgrade process take?
Depending on the size of your file system and databases, the upgrade process might take up to 30 minutes in your non-production environments, and up to 5 minutes in your production environment. In either case, Acquia might begin automated preparations for the final cutover process hours in advance. However, no visible impact to you or your end users is anticipated during that pre-cutover phase.
Will there be downtime during the upgrade?
Yes. The portion of the upgrade process that requires limited downtime is not expected to exceed 30 minutes in non-production environments, and 5 minutes in production environments. In both cases, the total downtime is proportional to the size of your file system and databases. You can get an estimate of the total time required for these tasks on your applications by initiating a file or database copy between environments in the Cloud Platform user interface or through Cloud API v2.
For customers with larger file systems and databases in their production environments, Acquia utilizes specialized tools to reduce the time to deploy your files and databases to Cloud Next. Those tools make it easier to achieve near-zero downtime for most customer applications, with up to 5 minutes in production environments on the largest applications.
What can I do to reduce downtime during the upgrade?
Based on how your application works, you can do the following:
For applications with all or mostly cacheable content, ensure that your CDN or Varnish cache settings are set to hold onto content for at least an hour on the night of the maintenance event. This ensures that your unauthenticated end users can see the content on your site, even when the site is down for maintenance.
However, this approach is ineffective for applications with authenticated traffic or uncached content. For example, your sites cannot be rendered properly without write access to the file system or database, even when users browse content and not trigger any actions.
- Empty your cache tables and backup, and delete any file system or database content that might reduce the size of either on each environment. You must complete this step before the maintenance event starts, so that the visitors of your site do not experience a reduction in performance.
Typically, smaller file systems and databases can be upgraded quicker than the larger ones.
Do I need to take any action to prepare for upgrades?
The upgrade process is designed to minimize the need for your involvement. However, depending on the structure of your specific application, there might be steps that Acquia recommends you take to optimize your application’s performance in Cloud Next. For more information about the changes that might require you to take action, see Changes that may require customer action.
Do I need to take any action after the upgrades?
Acquia recommends that you test your non-production environments as soon as your application is upgraded to Cloud Next, so that you check whether your application works as expected. Otherwise, critical functionality on your applications and environments might be adversely impacted after your production environment upgrade is complete. For more information, see Testing your environments upgrading to Cloud Next.
What are the technical issues that one might encounter because of Cloud Next upgrades?
While many applications are successfully upgraded with no additional effort, some applications require changes to align with Acquia’s best-practice recommendations based on the underlying technologies of Cloud Next. For more information, see Changes to Cloud Platform features.
How long does Acquia take to upgrade all environments on my application?
After the upgrades in non-production environments are complete, you have approximately 14 calendar days to test all upgraded environments and verify that the essential Cloud Platform and Drupal site features work as expected. This includes automations and scheduled cron jobs. For any technical issues discovered after the upgrades, you must create a Support ticket.
If no critical issues are identified after 7 days, Acquia sends a second maintenance notification for your production environments. Your production environments are upgraded at least 7 calendar days after that, depending on the maintenance window availability.
Therefore, you can expect production and non-production environments to run on two separate versions of Cloud Platform for approximately 2 weeks, unless otherwise noted.
Can my production environment be upgraded sooner once my non-production environments are done?
Yes. To have your production environments upgraded immediately after completion of upgrades in your non-production environments, respond to the maintenance notification ticket that Acquia sends for your non-production environments, stating that you want to move forward with your production upgrade.
Acquia makes every effort to accommodate your request based on the availability of open maintenance windows and other scheduled upgrades. Ensure that non-production environments are tested immediately after they are upgraded. This mitigates any risks involved with upgrading your production environments on an accelerated schedule.
I have multiple applications that are all eligible for upgrade. Can Acquia upgrade them in a specific order?
If you have multiple applications in Cloud Platform, Acquia schedules your applications for upgrade when they are eligible. To get a specific application upgraded first, contact your Acquia Accounts team.
I have blank applications. Can Acquia upgrade all of these applications at once?
Yes. Acquia might contact you on a case-by-case basis to upgrade all the blank applications at once.
Can Acquia upgrade my applications over the weekend?
Acquia performs upgrades during each region’s designated “dark hours” slot from Monday to Friday. Upgrades are not performed on weekends.
Can I postpone my upgrade to a later date?
Acquia permits upgrades to be postponed if the selected date and time might adversely impact your business operations. For example, with a site launch or major event. In such cases, the delay period cannot exceed 4 weeks.
Can I reschedule my upgrade if something comes up at the last minute?
If a critical issue or business event increases the risk of complications during a scheduled maintenance event, you can request a postponement. However, you must make that request at least 4 hours prior to the start of the maintenance window.
Why should I upgrade from Cloud Classic to Cloud Next?
Cloud Next has many benefits over Cloud Classic. For more information about the key benefits of Cloud Next, see Key benefits of Cloud Next.
Are these upgrades required, or can I remain in Cloud Classic infrastructure indefinitely?
Acquia is in the process of discontinuing the Cloud Classic infrastructure. Therefore, these upgrades are mandatory, and requests for deferral for longer than 1 month are not granted.
What should I do if I need one or more of the features only available in the Cloud Classic infrastructure?
If your application is not already provisioned, Acquia can provision it in the Cloud Classic infrastructure to ensure that you have access to the features you need until they are available in Cloud Next. After the features are available in Cloud Next, Acquia schedules upgrades for your environments.
If your application is already provisioned in Cloud Next, contact your Acquia Accounts team to schedule a temporary migration to the Cloud Classic infrastructure. Acquia does not upgrade an application to Cloud Next if the application leverages any of the features listed in the Temporarily unavailable features section.
What happens if Acquia upgrades my environments and I discover something wrong?
Acquia Support is available 24x7 to assist with any critical issues that you discover on your environments after an upgrade. For any assistance, create a Support ticket. After you provide steps to reproduce the issue, Acquia Support attempts to identify the source of the anomalous behavior.
Typically, Acquia attempts to resolve the issue without the need for a reversion to your Cloud Classic infrastructure. However, certain issues might require you to make changes to your application’s code or configuration. In such cases, Acquia cannot make the changes on your behalf. However, Acquia Support can share recommendations on possible remediation approaches.
For critical issues, Acquia coordinates with your teams to determine if the fastest and safest path to resolution is a reversion to your Cloud Classic infrastructure. If Acquia cannot contact your team in a timely manner, Acquia might revert your application to restore normal operations on the impacted environments immediately.
How much time do I get to notify Acquia when something is wrong with my environment?
After your environments are upgraded, you can create a Support ticket to report any technical issue. However, if you need your infrastructure to be reverted to the previous state, you must inform Acquia within 7 calendar days of your upgrade.
Typically, Acquia keeps your Cloud Classic infrastructure for 1 week following the completion of both non-production and production upgrades for the last application running on it. After 7 calendar days without any environments actively running on that infrastructure, Acquia terminates the infrastructure.
After the 1 week period is complete, Acquia attempts to resolve any issues that require a reversion to the Cloud Classic infrastructure. Acquia provisions a new Cloud Classic infrastructure and makes every reasonable effort to replicate your original settings and configuration. However, this might not be possible in a few cases. Therefore, alternative solutions are determined in close collaboration with your team.
Is there a risk of data loss during the upgrade or reversion processes?
Acquia takes every effort to avoid any data loss during the Cloud Next upgrade and reversion processes. These efforts include setting your file system and database to read-only during the final cutover. This ensures that no changes are made to your source infrastructure after the final data sync is underway or complete.
What if I lose some data?
Depending on the criticality of the missing data, Acquia can review the available disaster recovery snapshots and make them available to you for data inspection and recovery.
Will my site be backed up before the upgrade starts?
Acquia takes disaster recovery snapshots in Cloud Platform at regular intervals, including hourly for the past four hours. After the upgrade is complete, the final version of your pre-upgrade file system and database continues to persist on your Cloud Classic infrastructure in an idle state for up to 7 days. For more information, see Cloud Platform disaster recovery.
How does Cloud Next impact my existing subscriptions?
For customers on Acquia’s Views and Visits pricing model:
No additional paperwork is required, and your contract does not change. Views or Visits measurements are not impacted by the upgrade to Cloud Next. Acquia monitors the storage utilization on all environments. You are subject to the Fair Use guidelines in the Products and Services Guide.
For customers on Acquia’s legacy instance-based pricing model:
No additional paperwork is required, and your contract does not change. Acquia converts the instance-based CPU/Memory capacity associated with your existing infrastructure to Cloud Capacity Units in Cloud Next.
Do I need to pay extra to use Cloud Next?
No. These upgrades are offered to all customers at no additional cost.
How can I know if my environment runs in Cloud Next?
Environments that run in Cloud Next are indicated with the following icon:
Are there any other major maintenance events happening soon?
Acquia is committed to maintain security and stability of Cloud Platform. To do so, Acquia removes software that reach end-of-life, and adds new features. Whenever such an event occurs, Acquia updates documentation and shares communication around these events. Acquia provides adequate lead time to ensure that your application continues to run smoothly when these upgrade and retirement efforts are underway. For more information about upcoming maintenance events, see Software end-of-life schedule.
How do I contact Acquia if I have questions?
For any assistance, you can create a Support ticket.
How does infrastructure upsizing and downsizing work 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. This architecture allows non-production environments to run in a high-availability configuration by default. Also, 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.
Could the dynamic auto-scaling in Cloud Next result in overage fees?
The dynamic auto-scaling functionality in Cloud Next provides flexibility and almost limitless growth when extra cloud capacity is required.
For customers on Acquia’s Views/Visits pricing model, Acquia reaches out only if:
- the aggregate resource utilization across all applications and environments exceeds the Resource Limits guidelines published in Acquia’s Products & Services Guide for a period lasting longer than eight hours.
- recurring spikes above thresholds are observed on a routine basis over the course of two or more weeks.
In either case, overage fees will be assessed starting from the date of initial notification by Acquia.
For customers on Acquia’s legacy infrastructure-based pricing model, Acquia doesn’t notify you about transient Cloud Capacity Unit spikes that exceed your contractual capacity limits. Such spikes must be rare and shouldn’t exceed three hours in duration. However, recurring or excessive spikes in resource utilization above your contractual capacity limits may result in:
- overage fees
- requirement that you upgrade your subscription to an appropriate package using Acquia’s Views/Visits pricing model.
In either case, overage fees will be assessed starting from the date of initial notification by Acquia. However, fees may be waived in the event of a subscription upgrade.
Can I limit or manually trigger scaling on my Cloud Next environments?
Environments running in Cloud Next dynamically scale to meet active demand. Hence, they can’t be scaled manually, even upon request. Acquia will provide the ability to limit scaling per-environment in a later release.
Can I run my applications on a dedicated (non-pooled) version of Cloud Next?
Cloud Next leverages pooled capacity to ensure every production environment can utilize as much capacity as it needs and when it needs it. It was also designed with security and compliance in mind, and leverages an architecture that virtually eliminates the need for permanently dedicated capacity to properly protect an environment.
Hence, Cloud Next is currently only available in a pooled configuration. More information about dedicated capacity configurations will be available later this year.
Should I still notify Acquia in advance of high traffic events on my site? Should my sites still get upsized proactively?
As a Cloud Platform customer, you are always advised to contact Acquia Support before any high traffic event occurs. This information ensures that Acquia’s on-call teams know about the possibility of a spike in legitimate traffic on an environment. This also gives Acquia the context needed to provide assistance, if required.
Environments running on the Cloud Next technologies don’t require proactive capacity increases as such environments dynamically scale as needed. However, Acquia teams may adjust some settings in anticipation of increased traffic to ensure optimal performance throughout the event.
If Cloud Next leverages Kubernetes and containers, can I download and run a local image or provide my own custom builds for Acquia to run?
At this time, Acquia can neither provide build scripts and images for the Cloud Next containers nor run container images and build scripts provided by customers. To get this functionality added to the Cloud Platform roadmap, contact your Acquia account team.
How are atomic code updates different from traditional code deployments?
On the Cloud Classic infrastructure, code deployments involve a multi-step process.
An overview of the Cloud Classic code deployment process is:
- After you trigger code deployment, the Cloud Classic web infrastructure performs a
[git pull]operation to pull the new code to a hidden repository folder. - After that process is complete, the Cloud Classic web infrastructure syncs the changes to the active directory for your docroot.
This process, while typically fast, can result in inconsistent code deployments across multiple web nodes.
Note
How is Memcached architected differently in Cloud Next?
On the Cloud Classic infrastructure, Memcached was typically configured to run across all available web nodes with 64 MB of memory allocated to each infrastructure. This isolated a relatively small amount of system memory, pulling it away from PHP, cron, and other application-layer services for the exclusive use of Memcached.
Some customers on the Cloud Classic infrastructure also invested in dedicated Memcache capacity, where some infrastructure was set aside for the exclusive use of Memcached so that two or more nodes could allocate nearly all of their available memory to Memcache. This configuration was typically only available to top-tier accounts and for production environments.
In Cloud Next, Memcached is rearchitected to run in a high-availability configuration in both production and non-production environments. This not only results in improved performance in non-production environments but also expands access to a more performant Memcached configuration to all customers by default.
For environments running in Cloud Next, Drupal pods connect to Memcached pods through a relay point running mcrouter for improved performance and resiliency. Owing to this optimization, the [mcstat] command won’t function during SSH sessions and the Memcache module. After using SSH to access an environment, use acquia-memcache stats to access Memcached data.
The Cloud Platform team is actively researching potential mid-term solutions to both limitations to improve customer visibility into the health and performance of Memcached on your environments.
How does logging behave differently in Cloud Next?
On Acquia’s Cloud Classic infrastructure, you have access to the /var/log/sites directory to view environment log data and store custom logs. On average, these logs remain available for weeks or months at a time, but would be lost whenever infrastructure was relaunched during maintenance events, sometimes limiting the historical data available.
Since Cloud Next leverages ephemeral containers and pods, the same methodology is not available for upgraded environments. Hence, you must configure your custom logs to be stored in an alternative location: /shared/logs. Hence, you must access historical logs for your environments using an alternative method such as Acquia CLI.
For this reason, Acquia has updated the Download Logs functionality in the Cloud Platform user interface and Cloud API v2. Prior to this update, you could only download logs for the current day. However, with this update, you can select a day or time period over the past 30 days. You can download logs of up to 24 hours. This enhancement not only makes log access easier but also ensures that your logs persist even after maintenance events.
How do Cron, SSH, and Cloud Hooks behave differently in Cloud Next?
On the Cloud Classic infrastructure, cron jobs, SSH, and Cloud Hooks run on the same infrastructure. Hence, they might compete with other processes, such as PHP or MySQL for system resources. You can also ssh directly to a specific web node and purchase dedicated cron capacity to ensure that a single node was always available and isolated for the sole use of frequent or resource-intensive cron processes.
In Cloud Next, the existing Cloud Classic functionality is enhanced. By default, all production and non-production environments have access to isolated cron, SSH, and Cloud Hooks pods that run only when needed and shut down whenever they are not. Thus, your environments are more efficient by default and utilize fewer Cloud Capacity Units when idle because excess pods are not left running. Additionally, cron, SSH, and Cloud Hook activity cannot interfere with Drupal, Memcached, or MySQL activity by competing for resources.
In Cloud Next, long running or stuck processes, such as processes running cron or Cloud Hooks, can’t be terminated manually. Contact Acquia Support for assistance if this happens in one of your environments.
Environments upgraded to Cloud Next may require adjustments to scripts, cron jobs, and other automations due to the updated location of several file directories. For more information, see Working with files.
FAQs about Cloud Platform trial applications
What is included in a trial application?
A trial application includes access to an application on Cloud Platform with non-production environments, that is, development and staging. Acquia CMS with the current Drupal version is installed on the development environment by default. Trial applications are entitled with access to Platform Email and Cloud IDE.
What value does a trial application offer?
A trial application provides users the self-service opportunity to experience the core tools and capabilities of Cloud Platform prior to purchasing a subscription.
How long is a trial application available?
A trial application is available for 14 calendar days from the date of provisioning.
What happens to a trial application after the trial period?
A trial application is automatically deprovisioned after the trial period. The deprovisioning process deletes all data associated with the trial application and environments.
What happens if the trial application has a bug or an issue?
Trial application users have access to Acquia Support within their trial experience. Trial users can create a Support ticket for assistance with any bugs or issues during their trial period.
How can I submit feedback about the trial experience?
At the end of the trial period, the trial application presents a survey where users can provide their feedback.
Are multiple Cloud IDEs available with the trial application?
Trial applications are entitled to one Cloud IDE for their trial experience.
Can I add custom domains to my trial application?
Custom domains are not supported for trial applications.