Page Comparison

...

We want to find the best way to support the Midwest species selector tool. Based on my initial investigation it’s currently hosted on one digital ocean droplet that contains the following tools.

1. MCCC row Row crop tool Vue.js application

2. MCCC row Row crop tool PHP API

3. MCCC MySQL data entry tool Vue.js application

4. MCCC MySQL data entry tool PHP API

5. MCCC vegetable Vegetable tool Vue.js application (on the develop server)

6. MCCC vegetable Vegetable tool PHP API (on the develop server)

7. MCCC WordPress site

8. MySQL database that stores data for all of the above(?)

...

1. Because there are so many tools on a 1GB memory server, it would be very easy for a high traffic scenario to cause downtime

2. Because there are so many projects all hosted on one server, it is it’s easy for bugfixes, deployments, or over utilization of any app to cause downtime for one or more of the tools. When I started looking at how the cover crop row tool is architected, it caused an outage for the MCCC WordPress site even though those tools should be logically independent.

3. The tech stack is somewhat outdated.

   1. More JavaScript developers are familiar with React.js over Vue.js.

   2. Most entry level developers don’t have PHP experience.

4. Reduced redundancy

...

1. Rebuild.

   1. Rebuild the tool using the stack that our team is familiar with. Move each service into it’s own server. Move the DB to a managed azure instance to implement further redundancy. Setup CI/CD to handle deployments in a controlled matter.

      1. Pros

         1. Improve the speed of future bug fixes and maintenance.

         2. Maintain independence between the tools and avoid unrelated downtime.

         3. Have automated builds, deployments.

         4. Data will be hosted on a managed instance and much less likely to be corrupted/lost.

      2. Cons

         1. This will likely increase the initial time needed to fix the issues.

2. Use existing code base

   1. Use existing code base but split into multiple VMS. Make a copy of the current develop server (this step will cause guaranteed downtime, but the timing can be controlled) and then divorce out the tools listed above into their own servers so that they aren’t comingled. Move the DB to a managed azure instance to implement further redundancy. Then update the DNS to point to the new VMs (this step will also cause guaranteed downtime).

      1. Pros

         1. This will allow development of one tool to be independent of the others.

         2. Data will be hosted on a managed instance and much less likely to be corrupted/lost.

      2. Cons

         1. The danger of this solution is that the develop server may not start up cleanly after making a copy. This may prolong the downtime for one or more of the above tools.

         2. Setting up CI/CD will be difficult, deployments will still be manual.

         3. Bug fixes and maintenance will be slower.

   2. Make changes to the live server without divorcing out the tools. This is the most dangerous solution because at any time a change to one tool could cause an outage to one or more of the others.

      1. Pros

         1. May save time assuming no downtime.

      2. Cons

         1. Will likely cause downtime.

         2. Very little redundancy.

         3. The server is undersized for the amount of things on it.

         4. Setting up CI/CD will be difficult, deployments will still be manual.

         5. Data has little redundancy and is at risk.

         6. Bug fixes and maintenance will be slower.