Cuando comienzas un proyecto en Internet una de las primeras preguntas que te haces es el hosting para tu sitio web. En realidad deberíamos hacernos más preguntas, sobre todo si planteamos hasta dónde queremos llegar con nuestro proyecto.
Estas primeras decisiones van a ser cruciales para que el resto del proyecto funcione bien. Algunas cuestiones que hemos de plantear es si nuestro sitio simplemente va a tener información, si va a tener transacciones (comerciales, por ejemplo), si va a ser multi-país o multi-idioma, si nuestros usuarios serán principalmente locales (país) o internacionales. Cada una de esas preguntas requiere de una serie de opciones, y todas las opciones te han de dar una respuesta de qué necesitas.
Premisas
NOTA: Este artículo está actualizado a fecha de agosto de 2019, por lo que se hace referencia a versiones y productos disponibles para esta fecha. Es probable que cuando leas esto haya cosas más actualizadas, así que mantén al día tus sistemas.
Una de las frases que más me habrás escuchado decir es que para hacer cosas en Internet hay que saber de Internet. Y partiendo de esta premisa hay que saber una cosa de Internet: cada «cosa» es un servicio distinto. El dominio, las DNS, el correo, la web, la base de datos… cada uno de estos elementos se puede gestionar por separado o en conjunto.
Como supongo que quieres tener un proyecto gratificante y que funcione. Si es así y quieres estabilidad, has de invertir algo de dinero. ¿Cuánto? Un buen amigo mío siempre decía que hay que invertir al menos un 3% de la facturación en tecnología (principalmente en infraestructura en el caso de los proyectos de Internet).
Y quizá la pregunta principal: ¿sabes o no sabes de sistemas? Doy por hecho de que el 95% de la población no sabe de sistemas, por lo tanto busca algo fácil porque no se quiere complicar. El hosting es como alquilar un local para montar una tienda, o buscar un piso para comprar o alquilar. Es posible que sepas cambiar un enchufe o colgar un cuadro, pero si has de reformar la cocina entera, has de pintar todo o cambiar la fontanería, no lo haces tú. Ahí entran los Administradores de Sistemas. Si vasa montar algo en serio necesitas a alguien en el equipo (o fuera) que se encargue de ello: un panel de control te ayuda, pero no te da soluciones óptimas.
Básico
No voy a darle muchas vueltas, porque no es de esto en concreto a lo que vengo a hablar. Si no tienes ni idea, el resumen es tenlo todo en un mismo lugar. Es lo peor, pero funcionará. Esto es que el dominio, las DNS, el correo y el hosting esté todo en un mismo lugar. Probablemente ese proveedor te de un hosting compartido con un cPanel desde el que gestionar todo. Con un poco de suerte ese proveedor sólo (y cuando digo sólo es sólo) ofrezca WordPress, de forma que los servicios de PHP, Web y Base de Datos estarán optimizados para WordPress. ¿Alguno que conozca? Ninguno. Todas las empresas de hosting compartido alojan cualquier tipo de proyecto, por lo que aunque se ofrecen alojamientos para WordPress, no suele ser verdad, es un alojamiento en el que puedes poner cualquier cosa.
Un poco más en serio
Vale, si quieres atreverte a ir un poco más en serio puedes comenzar separando algunos servicios.
Comencemos por el principio, el dominio. Para estos casos siempre hay que ir a un registrador oficial. En general no vas a usar ningún servicio añadido, simplemente el de registrar y gestionar el dominio, por lo que lo mejor es algo sencillo y claro. Mi opción principal está en DonDominio. Un dominio te puede costar unos 10-12 euros/año.
Para que un dominio funcione lo siguiente que hace falta son las DNS. Para esto hay varias opciones, pero si quieres algo potente has de irte a algo potente. En este caso recomendaría dos opciones, una de ellas inicialmente gratuita y la otra no (pero muy barata). Una opción es Hurricane Electric que tiene su propio servicio de DNS y es muy potente; son una gente que llevan muchos años trabajando con redes o IPv6. Una segunda opción es Amazon Route53 que, aunque es un servicio de pago que suele rondar los 1-5 euros/mes por dominio, tiene algunas características interesantes de cara a su uso futuro (sobre todo si vas a tener sistemas grandes o distribuidos).
Para acabar está el tema del correo. En este punto hay que diferenciar los sistemas de envío de los de recepción.
Para recibir correo, si vas a hacer algo en modo profesional, es recomendable usar un Google Suite o un Microsoft 365. En estos casos hay que crear cuentas de correo exclusivamente para las personas y nunca cuentas de tipo «info@», «marketing@»… Para este tipo de cuentas a las que tiene que acceder mucha gente necesitas un sistema de tickets, un sistema de atención al cliente. Para ello hay servicios como Zendesk, Freshdesk o similares. Esto significa que más o menos pagarás 5 euros/mes por cuenta de correo, y luego entre 0 y 20 euros/mes por agente para el soporte.
Para el envío de correo lo mejor es utilizar un servicio de SMTP profesional. Así no tendrás ningún problema de validación ni de spam, pero tendrás que pagar por cada correo enviado. Algunos servicios te ofrecen un mínimo de correo al mes gratuito. Para estos casos tienes opciones como Elasticemail o Amazon SES. En cualquier caso estos servicios te obligarán a verificar el correo, que es lo que hace que funcione sin problema.
Vamos a por la web
En WordPress cuando hablamos de la web hablamos de 3 elementos: PHP, Base de Datos y Servidor Web. Estos son los tres elementos que hacen que un WordPress funcione y que hemos de mantener con frecuencia para que no se queden obsoletos. Según evoluciona el software hemos de mantener los servicios.
Tal y como evoluciona WordPress lo mejor es mantenerse al día en cuanto a estos tres servicios y sus versiones. Por ejemplo WordPress está haciendo muchos esfuerzos para que el software sea compatible con las versiones a las que PHP se le da soporte y dejar atrás versiones obsoletas. En el caso de las bases de datos, WordPress usa un SQL estándar, por lo que en realidad usar un sistema de base de datos u otro no afectará mucho, o que sea nuevo u obsoleto. La diferencia estará en que un motor de base de datos nuevo será mucho más potente en cuanto a rendimiento, por lo que mantener la base de datos al día es también una buena idea. Con los servidores web para lo mismo, a que están apareciendo muchas novedades en cuanto al HTTP (2 y 3) que soportan los navegadores, por lo que cuanto más moderno sea más velocidad y optimizada será la comunicación con el usuario final.
PHP
Si vamos al detalle concreto de las versiones de PHP, hoy en día lo óptimo es tener PHP 7.2 o PHP 7.3. A finales de 2019 saldrá PHP 7.4 y está previsto que WordPress le de soporte. Si usas plugins, revisa en la ficha de los plugins que funcionan con una versión mínima soportada. No hace falta ir a la última versión de PHP, pero sí a una soportada, y PHP mantiene siempre 3 versiones, una con parches de seguridad y dos con funcionalidades nuevas. Puede que no quieras ir a la última, pero cada año deberías subir una o dos versiones.
Para esto es importante tener un entorno de desarrollo o de pruebas. Puedes hacer una copia de seguridad de todo el sitio (exceptuando por ejemplo el «uploads» (la carpeta donde están las imágenes y eso) y probar que tus plugins funcionen correctamente cuando hay versiones nuevas. Aunque sea una versión obsoleta del sitio en cuanto a contenidos, es muy recomendable mantener una copia funcional en la que poder probar y hacer pruebas cuando aparecen nuevas versiones.
Hay que tener en cuenta que cada versión de PHP tiene novedades tanto con elementos nuevos como con elementos que se van eliminando. Por ejemplo, uno de los más conocidos y que afecta mucho es la eliminación de las funciones mcrypt que dieron paso a las sodium. Este cambio es muy importante de cara a la seguridad y hace que todas las versiones previas a PHP 7.1 sean inseguras.
Por otro lado, hay que tener presente que PHP no es sólo PHP; sino que dispone de muchísimas extensiones. Por ejemplo, una que sí o sí has de tener instalada es la que permite conectar PHP con MySQL (sirve para cualquier tipo de base de datos de ese estilo). O por ejemplo la extensión GD para poder generar los thumbnails de las imágenes. O por ejemplo, la extensión de Opcaché, para optimizar el rendimiento y activar una de las capas de caché de WordPress en lo que a velocidad de código se refiere. Aunque WordPress requiere muy pocas extensiones los plugins y themes pueden requerir algunas más, por lo que es muy recomendable tener las que sean necesarias para el buen funcionamiento. Tampoco hay que instalarlas todas, ya que hará que WordPress funcione lento. En general los hosting compartidos te dan una serie de extensiones que hacen que todo funcione, pero si montas tu propia infraestructura deberás seleccionar según el sistema operativo, versión y requerimientos de tu proyecto. Por ejemplo, si vas a trabajar con fechas o calendarios la extensión calendar te será muy útil ya que probablemente tu plugin la use.
Nunca des por hecho de que tu hosting tiene las extensiones correctamente. Pregunta y pide que instales las que realmente necesitas para que todo fluya.
Base de Datos
WordPress funciona con MySQL o cualquiera de sus forks, entre los que están MariaDB o Percona. Cualquiera de estos sistemas funciona bien, por lo que aquí ya entran determinados elementos más concretos de cada proyecto. MySQL es parte de Oracle y parece que las últimas versiones ya no son lo que eran, lo que hacen que no sea tan óptimo como parece. Para eso podríamos elegir Percona como sistema alternativo que toma la base de código abierto de Oracle y le aplica sus optimizaciones o directamente nos vamos a MariaDB que poco a poco se está convirtiendo en un software completamente distinto.
En cualquier caso, como decía anteriormente, en cuestión de bases de datos lo mejor es ir a la última versión. Tampoco hay que correr cuando aparece una nueva versión mayor, pero si estamos en la versión 10.2.10 y ya está la 10.3.2 (que significa que ya tiene un poco de rodaje) podríamos hacer el planteamiento de subir de nivel, ya que cada versión suele incrementar entre un 10% y 30% el rendimiento previo.
Las bases de datos son un elemento que tienen poca maniobra en cuanto a un usuario final, ya que la configuración suele estar en el my.cnf al que sólo tiene acceso el proveedor del alojamiento. Si tienes un proyecto en el que el consumo de base de datos es alto o requiere de muchas consultas cruzadas, como por ejemplo una tienda con WooCommerce con muchos productos variables, necesitarás optimizar la configuración mucho, y de forma personalizada, analizando el tamaño de las tablas, de los índices… algo que un hosting compartido nunca te va a poder ofrecer.
Redis / memcached
Otras bases de datos que WordPress puede requerir si quieres que la cosa vaya mucho más ligera es un sistema con Redis o con memcached. Personalmente prefiero Redis. Estos no son requeridos por el propio WordPress pero son muy útiles para activar algunas capas de caché del sistema. Por ejemplo, la capa de caché de objetos que permite hacer caché en determinadas consultas de SQL, con lo que haces caché del MySQL y por tanto quitas peso a consultas recurrentes.
En general los hosting compartidos no disponen de esto, aunque algunos sí. En caso de querer hacer un poco de optimización, revisa que tu proveedor te ofrezca alguno de estos sistemas y de qué manera puedes aprovecharlo, que normalmente es con un plugin de caché general, o con alguno concreto para estas tecnologías.
Servidor Web
Servidores web hay muchos, aunque principalmente yo uso alguno de los tres más conocidos: Apache HTTPD, nginx o LiteSpeed Web Server. Cada uno de ellos tiene sus ventajas e inconvenientes. Un clásico en ellos es por ejemplo el uso del .htaccess ya que Apache o LiteSpeed lo utilizan y permiten que cualquiera haga configuraciones sobre el servidor desde el propio FTP, y en cambio nginx no. Esto hace que cada uno cargue las configuraciones de forma distinta y eso afecta al rendimiento.
Para mi la elección de un servidor web u otro suele ir muy relacionado con la gestión de la caché de WordPress. WordPress siempre ha de ir acompañado de las distintas capas de caché posibles y existentes ya que sin ellas simplemente no escala, y en esto el servidor web tiene muchísimo que decir.
Depende de los proyectos y las configuraciones de caché yo uso nginx o LiteSpeed. La opción de nginx suele ser porque el sistema está distribuido o hay capas de caché por encima del sistema (tipo Varnish o un CDN) y el caso de LiteSpeed cuando el sistema es más propio. Lo interesante de LiteSpeed es que tiene su plugin LiteSpeed Caché que gestiona la caché bastante bien sin necesidad de muchas historias de infraestructura o de sistemas, por lo que a nivel intermedio es una gran opción. Hay que tener en cuenta que dependiendo de qué tamaño es tu sitio, LiteSpeed es de pago, pero en general es muchísimo mejor que simplemente Apache, que yo no suelo recomendar.
La opción de nginx implica que si quieres hacer algunos cambios concretos en las configuraciones has de hacerlas mediante fichero de configuración, por lo que necesitarás a alguien que lo sepa configurar y gestionar.
¿Qué hosting elegir?
Para empezar un poco de claridad en el asunto, y poner algunas palabrotas sobre la mesa, y es que hay que diferenciar entre «tipos de hosting»: hosting compartido, hosting dedicado, VPS, Cloud…
Tipos de alojamiento
Un hosting compartido es como vivir en un apartamento dentro de un edificio de apartamentos. Todo el mundo comparte algunas cosas (electricidad, agua, ascensor…) pero con algunas limitaciones… por ejemplo, puedes hacer crecer el trastero o el aparcamiento, pero es difícil hacer crecer el apartamento en sí ya que está limitado.
Un hosting dedicado es tener tu propio edificio, ya que tú eres el dueño del esqueleto del edificio. Esto te permite dividirlo como quieras o darle el uso que quieras… eso sí, los recursos globales son los que son. Si el edificio tiene tres plantas y un sótano, si quieres hacerlo crecer es posible que tengas que parar todo, hacer obras, pedir permisos y, al final, tiene ciertas limitaciones.
Un VPS o servidor privado virtual vendría a ser como vivir en un camping en tu propia caravana. En principio estás siempre en el mismo camping aunque puedes decidir el tamaño del bungalow o de tu autocaravana. Puedes decidir si tiene más habitaciones o menos, pero estás limitado a lo que ese camping pueda ofrecerte. Podrías llegar a hacerte con todo el camping, aunque no será barato.
Y para acabar el Cloud, que vendría a ser como una cadena hotelera. Esta cadena hotelera tiene varios hoteles en la ciudad, tiene habitaciones simples, dobles, suites… cuando haces el check-in te dan una habitación, que puedes ir ampliando según necesitas, pero teniendo en cuenta que te pueden cambiar la habitación de sitio sin avisar, e incluso te pueden cambiar de hotel. Eso sí, tu siempre entras por la misma puerta y mágicamente estás en un sitio u otro sin saber cómo has llegado allí (y la verdad es que te da igual, mientras haya una cama cómoda donde poder descansar).
Estos alojamientos, a nivel de precios, seguramente van en el orden de hosting compartido (más barato), VPS (relativamente barato) y posteriormente el hosting dedicado o el Cloud, donde los precios variarán dependiendo de los recursos (CPU, RAM, disco…) que sean necesarios.
En general, también hay que tener en cuenta si el alojamiento es administrado o no-administrado. Esto es como tener casero, que se encarga o no del mantenimiento de tu apartamiento, edificio o lo que sea. En general, al igual que en los edificios de apartamentos donde suele haber un casero, el hosting compartido suele estar administrado y gestionado, por lo que no te has de preocupar de gran cosa, sólo de tus cosas. Lo mismo pasaría con el Cloud y las habitaciones de un hotel, donde suele haber servicio de habitaciones. En el caso del hosting dedicado o de los VPS todo es mucho más autogestionado, ya que si tienes tu propio edificio tú eres tu propio casero, o si vives en un camping, el camping te ofrecer algunos servicios básicos para que te puedas conectar (luz, agua…) pero te has de apañar tú. En cualquier caso, siempre podrías contratar a un tercero, un administrador de sistemas, para que se encargue de esas cosas.
Mi proyecto, mi alojamiento
Según el proyecto que tengas necesitarás un tipo de alojamiento u otro. Por ejemplo, si tienes un blog o un sitio sin mucha complejidad (pocos plugins, un theme sencillo) en un hosting compartido bueno y optimizado puedes conseguir picos de 10.000 visitas/hora sin despeinarte, pero el hosting ha de tener elementos muy bien pensados para WordPress. Lo normal es que un hosting compartido aguante unas 25.000 visitas/día si el WordPress está optimizado y es sencillo. Por ejemplo, mi blog o mi página personal están en alojamiento compartidos porque no necesitan más. Si tienes un sitio más grande o con más tráfico (incluso una red de blogs) ya hablamos de subir de nivel y lo más probable es que tengas que irte a un VPS.
Cuando vamos a un sitio multi-idioma la cosa se complica. Si usas un plugin como WPML un hosting compartido va a morir ahogado, ya que esa configuración consume muchísimos recursos y harán que el WordPress vaya lento y mal. En estos casos puedes plantearte para un proyecto como una web corporativa en varios idiomas el uso de un hosting compartido con un WordPress MultiSite. Pero poco más.
Si ya nos vamos a un comercio electrónico, por ejemplo con WooCommerce, el sistema dependerá más de cómo de optimizado esté. Si tienes poco tráfico (menos de 10.000 visitas/día) en un hosting compartido podrás llegar a funcionar correctamente, pero no escalará. Si el comercio es serio, si inviertes en publicidad, seguro que necesitas montar al menos un VPS, incluso dos (uno para la web y PHP, y otro para base de datos). Si se monta bien un WooCommerce sencillo puede funcionar bien en un VPS de 4 CPU, 8 GB de RAM y 80 GB de disco y hablamos de unos 50 euros/mes. En cualquier caso si ya estás en este nivel, es más que necesario que un administrador de sistemas lo monte todo correctamente y haga los mantenimientos necesarios, lo que puede implicar invertir 100 euros/mes más en este servicio. Sí, la administración de sistemas puede ser mucho más cara que el alojamiento en sí.
El problema de los WooCommerce es cuando se le mete multi-país o multi-idioma y se hace con un WPML. En estos casos, por ejemplo, nosotros hemos tomado la decisión de simplemente no tomarlo como cliente, porque es un caso perdido. Si vas a vender y eliges esa opción estás muerto, ese proyecto hay que tirarlo a la basura. Otra opción es montarlo con un WordPress MultiSite + MultilingualPress, donde es mucho más sencillo escalar y hacerlo funcionar, ya que se vuelve todo mucho más normal y estándar.
En cualquier caso, la gran diferencia y momento clave es saber cuándo necesitas a alguien que sepa de WordPress (y no hablo de esa gente que instala un plugin de optimización de WPO para comprimir los CSS y JS, o que te pone un par de plugins de caché) ya que hay cosas de fondo, de entrar por consola (la pantalla esa negra que los hackers de las películas usan y escribe muy rápido) y hacer cambios en el sistema directamente.
Disaster Recovery
Otra cosa importante es tener un plan B. Hace poco que hubo una tormenta en Barcelona y ha hecho que en el centro de datos donde está parte de nuestra infraestructura se fuera la luz. Es algo muy raro y difícil que pase, pero las tormentas eléctricas es lo que tienen, que cae un rayo y te achicharra un generador eléctrico y se va la luz. En estos casos ¿cuánto tiempo estás dispuesto a que tu proyecto no funcione? Pues por ejemplo, este sitio estuvo 3 días sin funcionar debido a esto, y personalmente como sé que se estaba trabajando en ello, pues la preocupación era cero. ¿Tengo plan B para estos casos? No, porque no lo necesito.
Pero imagina que tienes un blog con mucho tráfico y muchas visitas y que ganas dinero con él, o ya me voy a algo más claro, que tienes un WooCommerce donde vendes tus productos y lo tienes en un hosting compartido… ¿sabes que si se estropea un disco duro puedes estar horas sin trabajar o tener acceso? Aquí si que quieres un plan B y ese plan B se llama Disaster Recovery. Creo que el nombre es bastante claro, y es un sistema para recuperarse de un desastre, como por ejemplo el que os he comentado. Si yo hubiera tenido contratado algo en este modo es probable que en tan sólo unas pocas horas hubiera podido estar en línea de nuevo. No es un sistema automático, pero te puede permitir tener una copia de tu sitio bastante actualizada y poder recuperar información en unas pocas horas. Y esto no es una copia de seguridad, ya que en realidad un Disaster Recovery ha de estar físicamente en otro centro de datos (y habitualmente en otra ciudad). Por ejemplo, los nuestros están entre Barcelona y Madrid respectivamente el uno del otro, e incluso tenemos algunos en París.
Normalmente el precio de un sistema de recuperación ante desastres es el doble del precio de la infraestructura que tengas, ya que básicamente lo que hay es lo mismo en dos sitios a la vez, con una copia de los cambios cada N horas, y si el habitual deja de funcionar, se levanta manualmente el sistema alternativo.
High Availiability
Aunque sin duda el elemento clave en caso de tener un negocio importante (y aquí vuelvo a lo que comentaba al principio de invertir el 3%) es el sistema de alta disponibilidad. Si tienes un comercio electrónico, un medio de comunicación o algo que requiere de estar el 99,99999% del tiempo en línea (vamos, que sea casi imposible que la web deje de funcionar) lo que necesitas es esta alta disponibilidad.
Aunque esto pueda parecer algo sencillo de montar, no lo es. A diferencia del sistema de recuperación donde tienes una copia oculta del sistema que se va sincronizando cada N tiempo, un sistema de alta disponibilidad implica tener el mismo sistema funcional en tiempo real en varias localizaciones a la vez.
La mayor problemática se encuentra en dos puntos: tener los mismos ficheros en todos los sistemas a la vez, y tener los mismos datos en la base de datos a la vez. Y esto no es tan sencillo de montar como puede parecer. Además, en lo que respecta a bases de datos, han de estar en al menos 3 localizaciones si realmente quieres tener alta disponibilidad, lo que complica aún más las cosas.
¿Cuánto cuesta mantener esto? Pues menos de lo que parece, aunque depende mucho de los recursos y el tamaño de los datos que se usan. Para empezar hay que multiplicar la infraestructura por 3, en 3 localizaciones distintas (para que tenga cierto sentido) aunque se pueden hacer algunas cosas bien pensadas y con un poco de inteligencia en la red.
Conclusión y resumen
Antes de nada, si has llegado aquí ¡felicidades! Este documento es muy extenso pero quiere hacer ver la complejidad a la hora de montar y escalar un WordPress. Y es que parece una tarea simple, pero no lo es.
Como ves cuando hablamos del alojamiento para un WordPress, estamos hablando desde alojamiento de 5 euros/mes hasta 500 euros/mes tranquilamente, aunque el límite está en las necesidades de tu proyecto. Eso sí, no te pienses que si te gastas 5 euros/mes vas a tener un servicio que haga que una tienda en muchos idiomas y que vende a muchos países funcione bien, porque puede haber excepciones, pero no es ni mucho menos lo normal. Y otra cosa, antes de montar un WordPress, consulta con alguien que sepa de verdad sobre WordPress, porque hay mucho vende humo (cualquier persona que recomiende WPML entra dentro de ese saco, por ejemplo).
En cualquier caso, si tienes alguna duda, puedes dejar un comentario o escribirme por correo y te atenderé lo mejor que pueda para ayudarte a la hora de elegir un tipo de alojamiento según el proyecto que vayas a lanzar.
NOTA: Antes de que se me tire nadie encima, que conste que no tengo nada en contra de WPML aunque lo pueda parecer. Este plugin funciona muy bien para una serie de cosas, pero no para otras y, en general, se usa para lo que no se debe usar.
Sobre este documento
Este documento está regulado por la licencia EUPL v1.2, publicado en WP SysAdmin y creado por Javier Casares. Por favor, si utilizas este contenido en tu sitio web, tu presentación o cualquier material que distribuyas, recuerda hacer una mención a este sitio o a su autor, y teniendo que poner el material que crees bajo licencia EUPL.