Are you deploying a WordPress installation on a Debian-flavored Linux instance maintained by Bitnami? Specific enough? Yes, to both? Then this write-up is for you!
Below are the considerations, design, and exact steps to follow to set up your environment for your client(s).
Recovery Time Objective #
RTO, in simplified terms, is the amount of time my customers are okay with being offline. Do you have an agency agreement with a client? If so, that contract may detail your SLA tolerance. For my clients, under the agreement, we agree to 99.99% calculated per annum, but we measure per quarter to guarantee a higher uptime. The difference between 99.99% and 99.9999% is drastic!
Calculate downtime https://uptime.is/
Monitor downtime for free – https://www.freshworks.com/website-monitoring/login/
I do have a client that fell to 99.33% due to a misconfiguration with their plugins – not managed by us. If you’re doing SLA-based contracts, make sure it’s clear that the server, network, etc.. is online, but not the apache instance, which can be tripped due to plugins overloading the instance, DDoS attacks, etc… – unless, of course, you’re capable and ready to support that type of behavior. The clients also need to understand that the more architected environments (microservice-based design) cost far more than a monolithic approach.
Recovery Point Objective #
RPO, on the other hand, is the amount of data loss to be tolerated. This is way more important for my clients when comparing it to RTO. They can handle being offline for extended amounts of time, but they cannot tolerate data loss. With these two objectives defined, we can start to architect a solution for our clients.
aka, budget busters. More features, plugins, or “stuff” = more time, fewer efficiencies, teams spread thin, or more staffing hours needed!
Oh, did I mention a more complex architecture too? Yeah, that too.
Your Clients budget may vary drastically; depending on expectations. I have clients that expect $15/month websites and others that are used to beefy costs of $1,000+/month.
Once we define the RTO and RPO, we can now scope the project. For me, I cannot do anything with a CMS for less than $120/yr hosting. My architecture work varies between $75-$135/hour and I generally pass the hosting fees directly onto my clients.
For static sites, I can do those for a minimum of $60/yr hosting. Again, my $75-$135/hour fees apply on top of the hosting.
For the majority of my clients, static sites would work, but because they like to test additional features, and plugins or have periodic features added, I generally promote a CMS-based platform.
Sizing (RAM, CPU, Storage) #
Size matters. This should be predicated on the usage requirements. Spec an instance based on usage over budget is always the preferred method. However, some clients are looking for cost-efficient models where their budget is maintained, but their site performance takes a hit.
Load Balancing & Edge Caching #
For the majority of my clients, I prefer to maintain the same design and tooling. Cloudflare offers a full stack of features for global distribution, load balancing, caching, security, etc… The base package by Cloudflare is often enough to kick off DNS, DDoS protection, a few firewall rules, and a few other features that I enjoy utilizing.
For my clients searching for an affordable solution, I use Cloudflare for caching and distribution. For my clients that are less concerned about affordability and more about uptime, speed, accessibility, etc.. we deploy load balancers on the cloud provider and store the various compute instances in different zones/regions with a globalized database.
This topic can be complex, but it’s not necessary for now.
Read more about the “tooling” I like to use with all/most of my WordPress customers.
Checkout my next document for the Deep Dive, where I actually run through the design and deployment of that design.