MCCC Questions

Introduction

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. Row crop Vue.js application

2. Row crop PHP API

3. MySQL data entry tool Vue.js application

4. MySQL data entry tool PHP API

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

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

7. WordPress site

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

Questions for Juliet

1. Is there anything else on either server that I’m missing?

2. How are deployments onto the digital ocean droplets handled? I didn’t see git repositories, how is new code pulled?

3. How is code deployed from develop to production server?

4. How is data from MySQL deployed from develop to production?

5. Are all the tools using the same MySQL installation, databases?

6. Will the servers startup cleanly after a reboot?

Challenges with supporting the current build

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’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

Possible solutions

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.

         6. Bug fixes and maintenance will be slower.