Recently, we were working with a church on a new website and came across a situation that was less than optimal. Their infrastructure had originally been configured so that their development web server was located on the same
VM as their production Rock instance. We wanted to take some time to discuss why this is not a good idea in case anyone else finds themselves considering the same pattern.
The reasons why you would want to separate your development and production environments fall into two categories: shared resources and complex configuration. Let's look at each in detail.
Shared Resources
The primary concern about running both production and development on a single server centers around server resources. Development environments are created because you want to do
things in them that you would not want to do in production. Production environments on the other hand are critical to the day to day operations of your organization. These two missions are fundamentally at odds.
During a website project we include a step to consider if the current environment has enough capacity to support the load of the new site. Because their current partner does not
maintain an architecture map for the church, there was no indication that this anti-practice was in place.
We did hear that there were some current concerns about weekend check-in performance.
Consider that last point: there are scaling questions centered around check-in performance. The evaluation of the current state and possible fixes is made much more difficult knowing
that one VM is serving two roles. If you go back to the Azure performance logs and look at CPU and memory usage during the check-in periods, there is no way to know if the load came from the
production IIS instance or the development instance. Perhaps someone was using or testing something on the development machine at the same time.
Complex Configuration
If shared resources were not enough to consider this a bad idea, we also need to look at the configuration required to run two instances of Rock on the same VM. This primarily
comes down to the IIS bindings required to separate traffic coming in on one IP address but being serviced by two or more IIS instances. In this configuration, each host name needs
to have two bindings (one for HTTP and one for HTTPS).
With a normal IIS installation all traffic is sent to a single IIS instance. This makes adding new host names (say for a new microsite you have just added) easy. Just adjust your DNS
and you can now be assured that Rock will get that traffic. When you run multiple instances, you will now need to also add two new binding rules to the production instance of IIS.
While these settings are not rocket science, they are also not expected and represent another point of failure.
Conclusion
Splitting production and development environments is critical to a stable and predictable Rock environment. This is especially true when you consider that an Azure burstable VM
capable of running a development environment can be had for around $30 per month.
At Triumph we are always passionate about doing things with best practice in mind. We are also equally passionate about sharing these best practices with the Rock Community to
help educate and help as a way of giving back.