¿Es caro tener una web en Drupal?

 Hola, ¿qué tal? Aquí otra semana más en Drupalizate, donde yo, Robert Menetray, te cuento pues una cosilla sobre el mundo Drupal. Esa semana quiero hablar sobre si Drupal es caro o es barato. O mejor dicho, la pregunta que me han hecho es ¿Drupal es barato o más barato que WordPress? Esto me suena que ya lo he contestado en algún otro episodio, pero quizás pasando muy por encima. Y en este episodio quiero comentar los tres motivos principales por los que Drupal sí es más caro que otras tecnologías. Sobre todo cuando comparamos, por desgracia, con el que me preguntan más, que es WordPress. ¿Cuáles son los principales tres motivos por los que Drupal es más caro que WordPress y qué otros se merecen? Digamos que el primero es la complejidad del proyecto. Normalmente Drupal está pensado para proyectos más complejos que WordPress. A ver, con Drupal puedes hacer un blog simple también o un e-commerce. Un e-commerce simple. El problema es que quizás no es la mejor herramienta para hacer una cosa simple. Al final te va a salir más caro porque Drupal es mucho más flexible, te permite configurar muchas cosas. El problema con esto es que al final toda configuración lleva un tiempo y un tiempo lleva un coste asociado. Así que si lo que quieres hacer tú es un único un blog simple de un único idioma pues seguramente es mucho más simple y más rápido y más barato, usa WordPress. Ahora bien, si lo que tú quieres es un blog en múltiples idiomas y no digo en dos o tres sino en muchos más idiomas o no una web que es un blog sino que tiene landing page, un blog y un e-commerce al mismo tiempo y aparte es multi idioma, pues esto con WordPress como que no. En Drupal en cambio sí, es totalmente factible hacerlo. Así que el principal motivo es el tipo de proyecto al que está pensada esta tecnología. Drupal está pensado para cosas más complejas con lo cual normalmente son más caras y WordPress y otras tecnologías digamos más usadas. Para poner un poco de contexto se dice que en WordPress es el 40% de las webs de todo el mundo son WordPress, Drupal es un 1 o un 2 por ciento. La diferencia es abismal. Drupal se usa para muchas menos webs, eso sí, para webs más grandes y más complejas. Bueno, el primer punto viene a ser este. El segundo punto, el tiempo de desarrollo y la cantidad de personas que hacen falta en el equipo para desarrollar la web. Esto también va asociado al tipo de proyecto. Al final cuando son proyectos más grandes, digamos proyectos que pueden tardar perfectamente más de seis meses o más de un año en programarse y montarse, normalmente son proyectos donde hay más de una persona en el equipo o pueden haber más de un equipo, un equipo de Frontend y un equipo de backend por ejemplo y uno de factbuilding que depende cómo seguramente lo haga la gente de backend. Pero esto, que normalmente webs que se hacen como churros con WordPress que son en una semana está la web hecha, porque se usan plantillas ya hechas y apenas se configura nada de un WordPress. En Drupal esto no. En Drupal es una web, se configura todo, seguramente se hará un tema hecho a medida, un tema visual, porque al fin y al cabo es un proyecto hecho a medida para el cliente, pues son webs más complejas, más lentas de desarrollar y al final cuanto más tiempo se tarda y más personas hacen falta en el equipo básicamente es mayor coste. Así que sí, también es más caro en ese sentido. Y después está el último punto que es el tema relacionado con estos dos o con el principal que es el tipo de proyecto, es el tema del servidor. Y me dejo otro punto que lo comentaré después que es el tema de mantenimiento. Al final como veis todo va relacionado con el tipo de proyecto con el que está pensado hacer webs en Drupal. Primero el servidor. Las webs más o menos grandes digamos que requieren una mayor cantidad de recursos y cuando digo webs grandes o complejas puede ser que tengan pues yo que sé, una internet de una escuela que puede tener picos de visitas o digamos una gestión de miles de ficheros o de páginas, en barra que hay unos recursos de servidor más potentes que una web de un blog que sólo ven 10 personas a llevarse el mes, pero bueno, ya me entendéis. Que webs pequeñas con poco tráfico vea sus webs grandes con mucho tráfico. O quizás no son con mucho tráfico pues son webs que bueno, las funcionalidades que tienen pueden requerir un mayor consumo de cpu o de ram con lo cual normalmente no funcionan con hostings compartidos, que son los hostings más baratos que la mayoría de webs se instalan allí. Que sí, que puedes tener un webs que es un e-commerce que hace falta más potencia y un webs se puede instalar perfectamente en un servidor virtual, o sea en un webs se ha administrado o sin administrar, sí, pero la mayoría de webs están en hostings baratos. Con Drupal se puede poner un hosting barato, sí, pero seguramente va a ir mal. Yo para Drupal recomiendo sí o sí un servidor dedicado o un vps, un dedicado físico o un dedicado virtual, sólo para esa web. Porque Drupal consume algo más de recursos que un webs, pero escala mucho mejor. Al final el sistema de cachés que tiene Drupal es mucho más potente que el sistema de cachés que puede tener un webs, que sí, que le puedes poner plugins a web, de la misma forma que yo le puedo poner aún más módulos a Drupal para, por ejemplo, poner Memcache o Redis. Pero por defecto lo que viene uno y lo que viene en el otro, Drupal gana. Así que, bueno, esto, que los servidores también nuevamente son más caros. Y esto repercute en un coste mensual para cliente, porque al final el servidor, pues, son caros, o caros, si depende del proyecto. Y están proyectos que se gastan una pasta en servidores, en plan de más de 200 euros al mes en servidores, para una única web. También, de mismo modo, creo que lo comenté en episodios pasados de proyectos míos, yo me estoy gastando en algunos proyectos menos de cinco euros al mes en servidores. Y están en Drupal también. Como veis hay una gran variedad de precios para el tema de servidores, sobre todo depende de las características que tengas tú de tu servidor. Si tienes un solar, un elastic, un Redis, un Memcache y por potencia te hace falta, por decir algo, tienes una base de datos que tiene muchas solicitudes, te hace falta más RAM, más CPU, pues, al final esto lo pagas. Y en Drupal acostuman a ser webs más complejas, más grandes, con lo cual acostumbran a ser servidores más grandes, más potentes, más caros. Y después viene la última parte, que me había dejado al principio, no son tres cosas, sino que son cuatro, que es el tema de mantenimientos. En webs más pequeñitas, como en webes, se puede hacer que la actualización sea automática, lo cual tiene cosas buenas y cosas malas. Por ejemplo, que si es automática y revienta algo, pues, automáticamente te estás rompiendo la web sin enterarte tú, se te puede dejar la web tumbada, cosa que a mí me da un poco de miedo. Cuando son webs pequeñas o blogs que no son, digamos, monetizables como tal, o la monetización, digamos, es muy reducida, pues que la web esté caída unas horas o un día tampoco es tan importante. Cuando son webs empresariales, donde tu negocio depende de la web, y son webs más o menos grandes, como lo comento con Drupal, sí que es importante que la web en producción nunca se caiga, siempre esté online, con lo cual Drupal ahora mismo no permite actualizaciones automáticas, automáticamente en producción. Sí que hay una iniciativa para permitir esto, digamos, a corto, mediano plazo, o sea, quizá en un año o dos, veamos algo ya estable. Aún así, depende de qué tipo de web tengas, yo no te recomiendo que esto, cuando salga esto a luz, se use esta herramienta o no de forma automatizada, que se use una herramienta automatizada para hacer test, actualizarlo en local o en un servicio de desarrollo, ver que todo funciona bien, y una vez lo has probado que todo funciona bien, lo subes a producción, vale, pero para automatizar y estoy directamente en producción, yo no lo haría así. Y como digo, en webs, bueno, pues cuando son webs más pequeñas tiene otro sentido mundo, que si es un blog pequeño, que te importa poco, te importa más tenerlo actualizado al día para evitar hackeos, que no si la web está caída pues un día porque ha pasado algo, porque se ha actualizado mal y ha reventado alguna cosa. Total, de que el tema de actualización es, a día de hoy, hace falta que le pagues a alguien para que te actualice la web cuando toque, que normalmente es mínimo una vez al mes, así que también tiene un coste asociado de mantenimiento mensual, con lo cual el coste de mantenimiento ya es más caro que web, porque en muchos casos web no hace falta un mantenimiento como tal, o sea, se actualiza automáticamente, o se crece mucho más fácil que lo que es un Drupal, con lo cual es más barato un web-based en tema de mantenimiento. En temas servidores de normal, también es más barato un web-based, porque son pagueles más pequeñas que requieren menos recursos. Y la creación de una web entera, que esto es muy viable, una web puede ser cualquier cosa, desde una única URL que tiene la home, y ya está, a una web con dos millones de páginas. O sea, esto es una web, sí, pero es muy viable. Por esto, que normalmente las cosas más simples hechas con WordPress se hacen en mucho menos tiempo, pero son web más simples que las que son en Drupal. Así que, resumidas cuentas, sí, todo es más caro en Drupal, comparado con tecnologías, digamos, más usadas por muchas otras personas, como son WordPress. Y estoy diciendo encapié en WordPress porque bastante gente me ha preguntado sobre el tema de esto de WordPress, porque al final es, digamos, la competencia en tecomías directas. Y sí, sé que no se usan para lo mismo, pero igualmente la gente cuando dice quiero una web, ah, pero yo he escuchado cosas de WordPress, en Drupal a mí no me suena. Ya, pues que para tu tipo de proyecto web no te hace falta un WordPress, te hace falta una cosa más hecha a medida. Bueno, por eso. Y ya todo esto, creo que no lo he comentado. También está el tema relacionado con el coste de cuántas personas hacen falta para el proyecto y si requiere más tiempo o no el desarrollo de este proyecto es al coste de cuánto te vale un desarrollador, o sea, cuánto se le paga al programador. Esto para bien o para mal, digo para bien porque para mí es muy bueno, para clientes normalmente no es tanto. Se paga mejor, bastante mejor, la verdad, lo que es Drupal que WordPress. ¿Por qué? Porque en WordPress hay apatadas, hay mucha demanda de webs hechas en WordPress. El problema es que son webs que se pagan muy barato y después también hay mucho desarrollador WordPress, con lo cual, pues más o menos se compensa la oferta con la demanda y son de ticket tirando ticket bajo, medio bajo, el tema de esas webs. Por contra, en Drupal hay menos demanda que WordPress, por supuesto, hemos dicho que es un 40% pero eso es un 1 o 2 por ciento, pero son webs de ticket tirando a alto, medio alto, bastante alto algunas y al final hay muy poca oferta de desarrolladores en Drupal, sobre todo que tengan experiencia de varios años en Drupal, con lo cual el sueldo que se puede pagar por un desarrollador Drupal senior es mucho más alto de lo que se puede pagar para un senior en WordPress. Esto tiene el inconveniente que, bueno, pues, el tema de costes, se dispara el desarrollador de un proyecto cuando tienes, quieres tener uno o varios desarrolladores senior en tu equipo, con lo cual es una cosa más a tener en cuenta que son pedidos más largos que requieren más tiempo o más personas en el equipo y además el equipo acostuma ser más caro ya de por sí, sólo de sueldo base comparado con, por ejemplo, un web es así que si en general todo es más caro en Drupal, lo siento mucho. Y nada más, hasta la semana que viene. Chao.