Move back to Azure app-service and hosted Postgres

[mbarton]

After #828 we no longer need a docker-compose setup in production. We can move back to using app-service and Azure hosted Postgres.

This setup is simpler, easier to move to CI/CD and avoids us having to maintain and patch a VPS.

We will need to decide how to run long-lived or scheduled async tasks in the future.

They do support postgis: https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-extensions

[pacharanero]

They do support postgis:

Yes we had postGIS running previously when we were on the managed Azure App Services and Managed Postgres (with PostGIS added) - however I am unsure how much of postGIS's features we are using for the limited mapping that is in place? @eatyourpeas will be able to add more detail on whether postGIS is definitely needed or was paart of past envisaged functionality.

[eatyourpeas]

Yes we had postgis running in the past and it worked well. It is an add on that is included in the azure portal.

If we were to remove postgis it would be quite a large refactor because we have used the postgis django models, rather than the standard django models, which includes fields such at Point. We would then lose the geocode features in admin as well. And of course we would not have the maps on the landing page since the boundaries for those are stored in the database, so those would also have to be removed. If we remove all the organisation models from E12 altogether and abstract into their own service there might be an argument to make that postgis rather than E12. But if E12 then consumes that service, presumably it would need to be geocode aware also.

We are not using much function yet, but it would be a relatively easy step with it in place to calculate average distance to epilepsy clinic for example, and then correlate that with particular outcomes, for example MRI or EEG wait. Or produce a map of all the patients in a given organisation or trust and look at patient density. My guess is that both of those features would be very useful to organisations when planning clinics or interventions, and commissioners would be very interested in patient distribution vs complexity for example when planning services. My bet is that HQIP equally would find the shoe on the other foot if RCPCH were able to report insights of this sort back to HQIP, that they had not anticipated, and that were gathered incidentally while meeting the main objectives of the audit.

And adding postgis back in in future will be much harder than replacing celery would be but of course I will go with consensus.