@SkylarAstarot te estás liando.
De MySQL te refieres a las
opciones que da Azure en cuanto a precios de MySQL, que van desde 1 núcleo hasta los 64 y 320 GiB de RAM. El uso de recursos de MySQL no depende de esto, depende de la carga a la que lo sometas. Estos niveles son los
recursos máximos que ese servicio puede tener asignados en Azure, pero no quiere decir que esté consumiendo eso constantemente.
Por cierto, es buena idea utilizar MariaDb en lugar de MySQL.
Azure también tiene un servicio de MariaDb, y tu aplicación ya es compatible con ésta porque MariaDb es 100% compatible con MySQL.
Dicho eso, por partes
Servidor de desarrollo
En este caso te interesa que tu plataforma de desarrollo sea local. El código siempre lo vas a escribir en local, la pregunta más bien es dónde va a ejecutarse mientras lo depuras o lo pruebas. Esto,
casi siempre, lo harás en local. Si desarrollas en .NET, siempre es local. Cuando inicias una solución de Visual Studio, se lanza en un IIS Express local. Si haces Java, se lanza en un GlassFish, Tomcat u otros también en local. Si lo haces en PHP, se puede lanzar en un Apache+PHP local (sea con quien sea: XAMPP, WAMP o el que quieras).
Existen entornos de desarrollo que te permiten
sincronizar tu código con un servidor remoto (NetBeans, PhpStorm), mediante FTP, rsync u otros. Esto no necesariamente te aporta ventajas, salvo que no tienes que tener el servidor web, el PHP y el MySQL instalados en tu máquina.
Este servidor remoto
puede ser cualquier cosa: un PC en tu red local con Linux, un Linux virtualizado en tu propio Windows con VirtualBox, o incluso una máquina en Azure u otras nubes, aunque por practicidad normalmente no lo haces así, sino que lo haces en local. Principalmente porque la máquina remota cuesta dinero y la local no y hay que administrar dicha máquina remota (iniciar, apagar, mínima seguridad para que no accedan a ella, etc).
Por lo tanto, digamos que tu servidor de desarrollo
siempre es local.
Servidor staging
Tradicionalmente era un servidor en el que se ejecutaba el software para probarlo en un entorno casi idéntico al de producción. Gracias a cosas como la virtualización y la
integración continua puedes tener un entorno prácticamente idéntico al de producción de forma automatizada para ejecutar pruebas. Incluso el servidor de desarrollo puede ser exactamente igual al de producción si virtualizas.
Por lo tanto, no vamos a hablar de este servidor de staging ya que
no lo vas a necesitar.
Servidor de producción (aquí desplegamos la app)
Este es el sitio donde la app va a correr en producción. Entorno final, definitivo, donde vamos a explotar la app. Aquí no hay ni el más mínimo lugar a dudas:
tiene que ser un Linux. Dicho eso,
en Azure dispones de máquinas Linux donde puedes desplegar la aplicación. Básicamente son máquinas virtuales con un Linux instalado, no tiene más.
Ahí puedes instalar tus servicios de servidor web, PHP, base de datos... Porque
es un Linux 100% estándar, normal y sin cosas turbias hechas, más allá de instalarle la capa de compatibilidad con el hipervisor que instalan todos los proveedores.
Podrías utilizar los servicios de Azure de base de datos en lugar de tener la base de datos instalada en el servidor. Esto ya entra más dentro de la arquitectura que del desarrollo, ya que esos servicios son en realidad máquinas virtuales con un servicio MySQL gestionado por Azure instalado dentro, por lo que te ofrecen puerto abierto para que entres y le hagas lo que quieras.
Desplegar la app puedes hacerlo en la VM que consideres oportuna, pero yo te recomiendo empezar por las más básicas. Tienes VMs Linux desde 4 € al mes con 0.5 GiB de RAM, suficiente para aplicaciones de bajo tráfico con todo incluído*.
Escalar esa máquina ya dependerá de la carga que vaya teniendo tu aplicación. Si es mucha evidentemente la máquina se quedará corta y tendrás que subir. Hasta dónde subir, hasta dónde optimizar la aplicación y cómo irla escalando ya es otro problema diferente.
* Sí, puedes tener servidor web, PHP y base de datos en 0.5 GiB. Durante años yo he tenido máquinas sirviendo webs de clientes con esa configuración y cero problemas. En el mundo Windows parece que cualquier cosa que abras va a empezar a devorar gigas y gigas, pero los servicios Linux habituales son muuuy eficientes y empiezan consumiendo cantidades ridículas de recursos. Para que te hagas a la idea, un servicio de MariaDb en mi servidor LAN (lo uso para descargas, compartición de ficheros en casa y copias de seguridad automatizadas) está consumiendo ahora mismo unos 40 MiB de RAM. No es que tenga mucha carga, pero no se acerca a lo que dices de 64 GiB de RAM... No funciona así