We use ECS (Zyrous prefers Fargate over EC2) to host our Drupal containers (the same ones that our developers create) and configure a scaling policy to ensure that each one remains at a stable utilisation level (we found that scaling based on CPU works well rather than memory usage but your mileage may vary). It’s the middle subnet where things get more interesting. These components could be used for any Drupal site (or any other application for that matter), regardless of the hosting method. Meanwhile, one of our private subnets hosts an Aurora cluster of MySQL instances (here we’re showing three instances total, assuming that we’re in a region with three Availability Zones for redundancy). Our public subnet contains only two things the load balancer for our site instances and a VPN server for admin access. Our developers didn’t thank us for it to start with, but I assure you that we’ve reaped the benefit of this approach many times. At Zyrous, we explicitly disallow any SSH connections to any of our running instances to enforce this approach. It gives you the freedom to address some issues quickly (by automatically destroying instances that are unresponsive), to easily scale out/in when necessary (by creating or destroying instances) and to make your deployments painless and dependable (by replacing healthy instances with new versions). This can be a tough change to make if your current infrastructure or deployment/management methods depend on access to specific machines, but it’s fundamental to getting the most out of your cloud platform of choice. This means that they are expendable, identical (or nearly identical) to one another and are easily replaced when necessary. If you’re the kind of Developer/Engineer that names their servers and likes to know their individual IP addresses, or if you regularly use a terminal to run drush commands on a deployed site, you’ll need to start thinking about Drupal instances less as pets and more like cattle. The change to running Drupal in a serverless way starts with a mind-shift. A system that can dynamically scale in and out ensures that resources are released when they aren’t needed, saving you money. By replacing entire instances rather than updating them, we produce a repeatable and dependable deployment outcome.Ĭost Saving: Paying for computing resources that you’re not using (or that you only use sporadically) is wasteful. Reliability: Relying on static Drupal instances with manual configuration can be a risky proposition and can lead to unexpected behaviour between environments. ![]() Especially for sites that experience regular peaks and troughs of demand, being able to dynamically scale-out ensures your site continues to work in any condition. Scalability: Although forecasting and planning for load is important, things often happen in production that we don’t expect. By using a container management system, site instances are automatically replaced as needed. Robustness: Nobody wants the 3am call to reboot a server because the site is unresponsive. ![]() But what happens when the server goes down? How about when your site experiences a huge increase in traffic that your single server (or cluster of servers) wasn’t designed to handle? How do you manage drift in the configuration of one server over time, ensuring that it stays in sync with other servers and environments? By using a serverless approach, you’ll achieve the following outcomes: The classic method of running a Drupal site is on a dedicated server (virtual or otherwise, on-premise or in the cloud) that remains in place to serve requests.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |