Simple application deployments aren’t always that simple

Most install guides for WordPress say the set up takes five minutes or less. The reality is that before you can install WordPress, you need an operating system, a web server, a database server, and the user accounts and databases WordPress will use.

If you’re serious about your shiny new WordPress site you’ll want multiple web servers, a load balancer, periodic backups, and maybe even multiple database servers. Before you know it you’ve spent several orders of magnitude longer to set up WordPress than the install guide promised.

This problem isn’t unique to WordPress. In fact, WordPress has a relatively straightforward install process. The setups for most application installs are even bigger hassles.

And the process of doing that prep work is always left as an exercise for the reader.

Why can’t WordPress describe its own reference architecture? A proper one that includes all the components you’ll actually need? One that we can all agree upon or discuss and adjust? Why must we figure this out for ourselves?

It doesn’t have to be this way.

This is one of the problems we want to fix with aaSemble.

WordPress could include a reference file that describes the components used in an actual WordPress deployment. It could say that you need one or more stateless web servers, one or more database servers, and zero or more load balancers.

A deployment engine could use that description to create the required resources for your target environment.

• If the deployment engine is configured for Amazon Web Services, you’d get an RDS instance, an Elastic Load Balancer, and a couple of EC2 instances.
• If configured for Google Cloud, you’d get a Google Cloud SQL instance, an HTTP load balancer, and a few Google Compute instances.
• If configured for bare metal, you’d get some systems running web servers, some running MySQL, and some running haproxy, nginx, or whatever load balancer suits your fancy.

All of it would be based on the description that shipped with WordPress. Mapping those requirements to your target environment is handled by the deployment engine for the initial installation and for subsequent updates.

If done right, it really could take less than five minutes to deploy a full WordPress environment. And automating the end-to-end process means you’d be production-ready right away.

How cool is that?