Posted on

El coste oculto de lo gratis

el coste escondido de lo gratuito

He estado involucrado en el movimiento del software open-source (no confundir con el software libre) desde sus inicios. Con el tiempo, he visto cambiar su percepción. Al principio, había mucha gente escribiendo software y contribuyendo porque podía. Les hacía sentir bien aportar a los demás.

Los usuarios de software open-source reconocieron este regalo que se les estaba dando y lo respetaron, al igual que al talento de quienes lo daban. Muchos usuarios contribuyeron a sus proyectos favoritos a través de código, documentación, promoción y, a veces, incluso dinero.

Con el tiempo, las cosas han cambiado. Hoy en día veo a más personas que utilizan software open-source porque creen que es gratis. Piensan que, como no tuvieron que pagarle a un programador por sus esfuerzos, se libran. A veces, esto es cierto, a veces puedes instalar un software y comenzar a generar valor a partir de él. WordPress solía ser así.

Sin embargo, actualmente el software, incluso el Open source, es complejo. Sí, WordPress solía tener la “instalación en 5 minutos”, y sí, es posible que aún puedas instalar WordPress así de rápido, pero si tu objetivo es hacer algo más que escribir en tu propio blog, tendrás que añadir algunas horas o días a esos 5 minutos.

A día de hoy, el software es complicado. Los temas de WordPress solían ser bastante simples, pero ahora son más complejos, con páginas de ajustes y muchas opciones de configuración. Opciones que, si no estás familiarizado con el tema, pueden resultar difíciles de navegar.

Este es el coste oculto de lo gratis. Muy alto actualmente.

Muchos plugins son “gratuitos” pero requieren que te suscribas a su servicio de backend subyacente. Técnicamente son gratis, pero igual te van a costar. Otros plugins ofrecen una versión gratuita, pero bloquean sus mejores funciones hasta que pagues. Nuevamente, técnicamente gratis, pero si quieres que hagan cosas interesantes, tendrás que pagar.

No me malinterpretes, no estoy defendiendo que todo el software sea gratuito. Como alguien que se gana la vida escribiendo código, recomiendo encarecidamente pagar a los desarrolladores. Es solo que, como propietario de un sitio no técnico, debes comprender el coste de “gratis”.

[subscribe_cta]

Prepárate para contratar a alguien que te ayude. En la mayoría de los casos, necesitarás:

  • Un Project Manager. Esta es una persona técnica, pero no necesariamente un programador. Entienden sobre WordPress, los plugins y saben cómo hacer que trabajen juntos para hacer las cosas. También saben cuándo se necesita un desarrollador y, por lo general, conocen a unos cuantos a los que poder pedir ayuda.
  • Un diseñador. Definitivamente necesitarás a alguien que pueda hacer que tu sitio web se vea bien. Puntos extra si también es un experto en experiencia de usuario (UX) para que pueda hacer que tu web sea fácil de entender y usar.
  • Un copywriter. (Pensaste que iba a decir desarrollador, ¿no?) Sí, vas a necesitar un redactor, alguien que sea un artífice de las palabras. Vas a querer que vean cada palabra de tu sitio web y se asegure de que lo que estás diciendo sea claro y fácil de entender para el usuario.
  • Opcionalmente, es posible que necesites un desarrollador. Si es así, tu project manager lo sabrá y debería saber a quién contratar. No te adelantes en contratar a tu sobrina y ponerla en el equipo. Deja que los expertos hagan el trabajo por el que los contrataste.

Una vez que hayas creado tu sitio web, todavía no será gratuito. Asegúrate de alojarlo en un hosting de buena reputación que entienda de WordPress. Puede ser una sorpresa para algunos de vosotros, pero tengo sitios web que no están alojados en SiteGround. Algunas de mis instalaciones de WordPress están alojadas en un servidor virtual que yo mismo administro. Entiendo lo que se debe hacer y entiendo los riesgos de administrar mi propio servidor.

Los proyectos que yo mismo alojo son proyectos complementarios con requisitos especiales que muchos proveedores de hosting no proporcionan de forma inmediata. Si bien en un sentido técnico, sí, cada sitio adicional que pongo en mi servidor virtual es “gratis”, también es una cosa más de la que tengo que preocuparme. Mi tiempo no es gratis, por lo que alojar sitios web en ese servidor resulta muy caro.

Para todos mis sitios web que no tienen requisitos muy específicos, uso SiteGround. Después de más de 25 años administrando servidores web y más de 15 años administrando WordPress, sé lo que necesito en un proveedor de alojamiento web, y SiteGround marca todas las casillas.

El software gratuito y libre (FOSS) es increíble. Literalmente impulsa el mundo en el que vivimos. Pero muchas veces, gratis solo se aplica al precio que pagas por el código en sí. Cuando te estes preparando para lanzar tu próximo sitio web, ten en cuenta algo más que el coste del código. Si tu sitio web va a añadir valor a tu empresa, prepara un presupuesto que te permita hacerlo bien. No te olvides del alto coste de la gratuidad.

Posted on

Nueva configuración MySQL para un procesamiento más rápido de consultas

nueva configuracion MYSQL de SiteGround

Dos de las razones más frecuentes por las que un sitio web puede ser lento son los procesos PHP no optimizados y las pesadas consultas de MySQL. La optimización del código del sitio web es siempre una parte crucial de la batalla constante por una mayor velocidad del sitio web. Sin embargo, los webmasters que se alojan con SiteGround siempre han tenido un aliado confiable a su lado en esta búsqueda.

Recientemente hemos anunciado el nuevo PHP ultrarrápido, que acelera significativamente el procesamiento de scripts PHP y mejora el rendimiento del sitio web hasta en un 30%.

Como siguiente paso natural en nuestros esfuerzos por ofrecer un servicio premium y superrápido, hemos implementado una solución del lado del servidor para optimizar las consultas de la base de datos que ya ha reducido el número de consultas lentas entre 10 y 20 veces.

¿Qué son las consultas MySQL lentas y por qué son importantes?

Si estás administrando un sitio activo con una base de datos, probablemente comprendas que cuando un visitante accede a tu sitio, hay toneladas de scripts que comienzan a ejecutarse, algunos de los cuales solicitan información a tu base de datos.

Por ejemplo, si tienes una tienda online y un visitante está tratando de comprar un artículo, tu tienda debe verificar su disponibilidad en la base de datos y mostrar si es posible realizar un pedido.

Esa verificación activa una consulta MySQL y, dependiendo de cómo se escriba esa consulta, puede ser bastante pesada y llevar mucho tiempo al servidor procesarla .

Para ti, como webmaster, estas consultas lentas son un problema porque perderás clientes.

¿Sabes cómo los visitantes abandonan el sitio cuando tienen que esperar más de 2-3 segundos para que se cargue una página? Bueno, lo entiendes.

Para nosotros, como tu proveedor de hosting, no nos gusta cuando nuestros servidores se ralentizan al procesar demasiadas consultas lentas porque esto significa que la CPU y la RAM de la máquina se bloquean y no se pueden usar para otros procesos, que también son importantes para el tuyo y los otros sitios web alojados en el servidor.

¿Qué hemos hecho?

La batalla con las consultas lentas de MySQL es un proceso continuo que involucra tanto al webmaster como al anfitrión. Es por eso que recientemente lanzamos una nueva configuración de MySQL en nuestros servidores, que adopta un enfoque innovador para distribuir la RAM del servidor y asignarla a MySQL.

La nueva configuración permite procesar simultáneamente un número mucho mayor de solicitudes paralelas y esto tiene un gran impacto en el manejo efectivo de las consultas MySQL pesadas.Tan buena es que los administradores de sistemas, al ver cómo se cargaba el servidor después del lanzamiento de la nueva configuración de MySQL, todavía no lo creían: ¡vieron una caída en las consultas lentas entre 10 y 20 veces!

Todas nuestras últimas mejoras de servicio, como PHP ultrarrápido y ahora la configuración de MySQL, son posibles gracias a dos cosas: la plataforma Google Cloud y el cambio de cPanel a Site Tools. Desde que nos mudamos a Google Cloud, actualizamos nuestras configuraciones de servidor con más RAM. El precio unitario de la RAM no es más económico, pero trabajar en la nube ofrece posibilidades para una mejor distribución de ese recurso entre diferentes máquinas. Y el hecho de que no cumplamos con los requisitos de recursos de software de terceros, como cPanel, nos da más libertad para innovar. ¡Nuestros DevOps se sienten capacitados para crear y seguir desarrollando tecnologías inteligentes que beneficien a la gran mayoría de los sitios que alojamos!

¿Quién se beneficia de ello?

¡Todos los alojados en nuestros servidores compartidos de Site Tools ya tienen la nueva configuración de MySQL! Si has observado una mejora en el rendimiento durante la última semana, se debe a la nueva configuración.

Esto significa que es menos probable que te pidamos corregir una consulta lenta y “distanciar socialmente” tu sitio web debido a ello. ¡Menos consultas lentas, servidores más rápidos, menos molestias para ti!

Las cuentas Cloud también están programadas para recibir la nueva configuración de MySQL a finales de febrero de 2021.

¿Todavía estás en cPanel? Esperamos terminar con todas las migraciones a Site Tools a finales de marzo, por lo que todo lo que tienes que hacer es esperar tan solo un poco más.

Posted on

Consigue más velocidad web con el algoritmo de compresión Brotli

compresion_brotli

Estamos entusiasmados de anunciar que hemos implementado y habilitado de forma predeterminada el algoritmo de compresión Brotli en todos nuestros servidores con Site Tools, por lo que los sitios web alojados en ellos podrán obtener un aumento de velocidad de hasta un 15-20% al usarlo.

¿Qué es Brotli?

Brotli es un algoritmo de compresión de última generación desarrollado por Google como sucesor del popular método gzip, que hemos estado ejecutando en nuestros servidores durante años. La idea es simple: una vez que su aplicación produce la salida HTML de tu sitio web y se comprime junto con todos los recursos que carga, los datos se transmiten a través de Internet y luego el navegador descomprime el contenido antes de procesarlo. Este proceso reduce significativamente el tamaño de los datos que se han movido del servidor al visitante, lo que resulta en un aumento de velocidad (mucho) mayor que los milisegundos perdidos por/en la compresión y descompresión.

¿Cuánto más rápido es Brotli en comparación con gzip?

El nuevo algoritmo proporcionado por Brotli comprime el sitio web en un tamaño de datos más pequeño, lo que agiliza la transferencia. Los archivos JavaScript comprimidos con Brotli son aproximadamente un 15% más pequeños que los comprimidos con gzip. Los archivos HTML son alrededor de un 20% más pequeños y los archivos CSS tienen una reducción de tamaño de alrededor del 16%. Por supuesto, estos números diferirán dependiendo de tus archivos en particular.

A continuación puedes ver una prueba con uno de los temas predeterminados de WordPress: TwentyTwenty muestra que produce 19584 bytes de datos sin comprimir, 6003 bytes comprimidos con gzip y solo 4863 bytes cuando se comprime con Brotli. Esto significa que consigues más del 75% de reducción de tamaño del contenido sin comprimir y un 19,5% respecto a gzip.

¿Cómo usar Brotli?

Hemos habilitado Brotli en todos nuestros servidores con Site Tools y, si tu cuenta está alojada en uno de ellos, tu sitio web lo aprovechará automáticamente. ¡No tienes que hacer nada para conseguirlo! 🙂  Los navegadores que admiten la compresión Brotli, que son la mayoría de los navegadores ahora, pasan el encabezado “accept-encoding: br” apropiado al realizar la solicitud y obtienen el contenido Brotli comprimido. Los navegadores más antiguos que no lo admitan recibirán datos comprimidos con gzip. Si todavía estás alojado en un servidor cPanel, no te preocupes: esperamos que las migraciones a Site Tools se completen a finales de marzo, por lo que no tendrás que esperar mucho para disfrutar de Brotli también.

Posted on

¿Qué es CRON y para qué puedes usarlo?

“¿Qué es cron?” Respondo a esta pregunta al menos una vez al mes por parte de personas que no son desarrolladores. Es una gran pregunta. Sin embargo, voy a dividirlo en dos preguntas.

“¿Qué es CRON?”
“¿Qué es WP-CRON?”

¿Qué es CRON?

En esencia, un cron es un “programador basado en el tiempo”. Gestiona tareas que deben realizarse de forma regular y en un momento específico.

Por ejemplo, si quieres que tu blog en WordPress muestre el pronóstico del tiempo en el encabezado, entonces cada mañana debes obtener el pronóstico del tiempo. Sí, puedes contratar a alguien para que inicie sesión cada mañana, obtenga el pronóstico y lo pegue en un widget. Pero un plan mejor es tener un programa que se ejecute todas las mañanas y que conecte con una API para obtener el pronóstico del día y actualizar tu base de datos por ti. El programa que ejecuta tu programa de búsqueda del pronóstico del tiempo se llama CRON. El nombre se deriva de “cronológico”, que se traduce aproximadamente como “en orden de tiempo”.

La mayoría de los sistemas hoy en día tienen algún concepto de cron. Los sistemas basados ​​en Unix (Unix, Linux, macOS, etc.) en realidad tienen una versión de un cron tradicional. Si bien algunos pueden ponerles una interfaz gráfica más amigable, todos se reducen a un programa llamado cron y un archivo llamado crontab.

El programa cron siempre se está ejecutando en segundo plano y cada minuto mira el crontab y averigua si es necesario hacer algo. Si no, vuelve a dormir.

El archivo crontab contiene cuándo se debe ejecutar un programa y qué programa se debe ejecutar. Cada línea representa una tarea diferente. Se ven parecido a esto:

1 0 * * * ~/fetchForcast.sh

Si bien esto puede parecer críptico, todo lo que le dice a cron es que a las 12:01 AM todos los días, ejecute un programa llamado fetchForcast.sh. Aquí te dejo una guía fácil para leer un crontab:

# ┌───────────── minutos (0 – 59)

# │ ┌───────────── horas (0 – 23)

# │ │ ┌───────────── día del mes (1 – 31)

# │ │ │ ┌───────────── mes (1 – 12)

# │ │ │ │ ┌───────────── día de la semana (0 – 6) (Sábado a Domingo;

# │ │ │ │ │                                   7 también es Domingo en algunos sistemas)

# │ │ │ │ │

# │ │ │ │ │

# * * * * * <comando para ejecutar>

  1 0 * * * ~/fetchForcast.sh

Ahora que tienes la clave, es bastante fácil, ¿eh?

Esto es realmente todo lo que hay en un cron tradicional. La mayoría de los hosting como SiteGround te permiten acceder al cron de tu sistema. A veces, tienes que editar el crontab manualmente, pero muchos hosting tienen una interfaz mucho mejor para facilitar su uso. De cualquier manera, tienes la capacidad de ejecutar programas en un momento específico y de forma regular.

¿Qué es WP-CRON?

WordPress hace las cosas de manera un poco diferente. Debido a que muchos autores de plugins necesitaban poder programar las cosas para que sucedan regularmente, y debido a que muchos propietarios de sitios WordPress no saben dónde está su crontab, y mucho menos cómo editarlo, WordPress reinventó el cron.

En esencia, WP-CRON actúa como un cron tradicional en el sentido de que un desarrollador puede “programar” una tarea para que se realice de forma regular. Sin embargo, a diferencia de un cron tradicional, WordPress no tiene un programa que siempre se ejecute en segundo plano en tu servidor. Entonces, para hacerlo, WP-CRON es un proceso que se llama cada vez que se ve una página. En sitios web concurridos, esto funciona bien. Sin embargo, si tu web no es muy visitado, una tarea programada para las 2:00 a.m. podría ejecutarse a las 5:24 a.m. si nadie visita tu web hasta entonces. A veces esto está bien, otras veces es un problema.

Si las tareas que necesitas ejecutar son urgentes y deben ejecutarse a la hora programada, WP-CRON no es el programador que debes utilizar. Si, por otro lado, las tareas que debe realizar pueden ejecutarse “aproximadamente” en el momento en que las programas, entonces WP-CRON está bien. Nuevamente, depende mucho de lo visitado que sea tu sitio web.

¿Cuáles son las alternativas?

Si tienes tareas que son urgentes y tu proveedor de hosting no te permite acceder al cron del sistema, tienes 2 alternativas.

Primero, puedes cambiar a un proveedor como SiteGround que te brinde este acceso. Si esto no te es posible, hay varios servicios gratuitos o de pago que no son más que servicios cron. Ejecutan cron y puedes configurar un trabajo para que se ejecute a través de una interfaz web amigable. El trabajo usaría un programa como curl o wget que conectan a las URL de tu sitio web para activar una tarea específica.

La mayoría de los plugins que requieren un cron te darán la URL a la que conectar si deseas usar un cron externo. Todo lo que tienes que hacer es pegar esa URL, configurar el tiempo para que se ejecute y listo.

CRON es una herramienta de mucho valor y una vez que comprendas cómo trabajar con ella, encontrarás cómo darle más usos. Si tienes plugins, casi te puedo garantizar que tu sitio web tiene trabajos wp-cron en ejecución. Si tienes curiosidad, ve al repositorio de plugins de WordPress y busca cron. Hay plugins que puedes instalar que te mostrarán toda la actividad de WP-CRON en tu sitio web. Pero ten mucho cuidado. Los plugins los establecen por una razón. Si decides que no te gusta uno y lo eliminas, el plugin que depende del trabajo del WP-CRON dejará de funcionar.

Posted on

PHP8 disponible en nuestros servidores

Estamos muy contentos de anunciar que hemos implementado la última versión candidata a lanzarse de PHP 8 en todos nuestros servidores. Como siempre, estamos entre las primeras empresas en proporcionar el nuevo PHP en nuestra plataforma de hosting. Se espera que PHP 8 facilite a los desarrolladores escribir código más limpio, con mejor calidad y que se ejecute más rápido. Dado que las versiones beta no son adecuadas para sitios web activos, te invitamos a probarlo en una copia staging de tu sitio web o en proyectos que aún no hayas lanzado. Regalaremos unos fabulosos elefantes PHP de peluche a 5 de los primeros usuarios que lo probéis y compartáis vuestra opinión sobre PHP 8 con nosotros.

¿De qué se trata el nuevo PHP8?

Ejecución de código más rápida

La última versión de PHP trae muchas cosas nuevas, pero con la que estamos especialmente obsesionados es JIT (just in time compiler, o compilador justo a tiempo). Es la primera vez que la versión de PHP tiene un compilador JIT, que almacena en caché una versión de su código ya interpretado y genera un código máquina como salida (el código máquina utiliza solo 0’s y 1’s). El compilador JIT promete mejoras de velocidad para tareas y algoritmos complejos y abre nuevas oportunidades para que el lenguaje PHP amplíe su alcance y aplicación.

Algunos de vosotros os preguntaréis cómo se relaciona JIT con Opcache, que trajo mejoras de rendimiento significativas a muchos sitios web. El trabajo principal de Opcache es cortar los procesos de tokenización, análisis y compilación de Opcodes, que luego son procesados ​​por el motor Zend. El papel de JIT es ahorrar en la ejecución de los Opcodes por parte del motor Zend, por lo que une fuerzas e interviene para ahorrar recursos donde Opcache no puede ayudar.

Vale la pena mencionar también algunas desventajas que hemos notado hasta ahora:

  • La ejecución de PHP8 con JIT puede dificultarte la resolución de errores de código porque puede ser más difícil localizar qué parte de tu código en esta versión interpretada es realmente la culpable.
  • Si estás ejecutando un sitio web WordPress, es posible que no notes mejoras significativas en el rendimiento gracias a JIT. Los desarrolladores de WordPress todavía están trabajando para hacer que WordPress sea compatible con PHP 8 y ​​ahora están en busca de personas que lo prueben, lo que significa que no podrás probar PHP8 en tu sitio web WordPress de inmediato. Además, debido a la forma en que WordPress interactúa con MySQL, gran parte del tiempo de espera no proviene de la compilación de PHP, sino del tiempo de respuesta de MySQL, que no se puede resolver con la ayuda del compilador JIT.

Código con mayor calidad

Una de las principales diferencias que notarás es que muchas de las advertencias y avisos que no se podían detectar ahora son excepciones o errores que se pueden detectar y registrar. Es posible que, debido a este cambio, ahora surjan muchos problemas que permanecían ocultos con las versiones anteriores de PHP. Esta es una gran mejora, ya que permitirá a los desarrolladores detectar problemas potenciales más fácilmente. Sin embargo, ten en cuenta que puede ser una buena idea configurar display_errors = Off si decides usar PHP 8 en un sitio en producción para no mostrar tales errores a los visitantes de tu web.

Código más limpio y más corto

Algunos de los elementos nuevos, como el operador nullsafe, mejoran enormemente la legibilidad del código haciéndolo más corto y ordenado. En lugar de anidar varios “if’s”, puede usar el operador “null” para escribirlos todos en solo una línea de código.

La tendencia “Type”

Desde varias versiones en adelante, PHP ha estado tratando de definir los argumentos que cada método podría adoptar y convertirse en un lenguaje escrito. En esta última versión, hay una función llamada “union types” que te permite definir 2 tipos de valor para cada función, lo cual es una continuación natural de esa tendencia. Como muestra el siguiente ejemplo, la función puede devolver un número entero o uno flotante:

public function getNumber(): int|float {
return $this->number;
}

La lista de nuevas características continúa y creemos que este artículo puede ser un buen punto de referencia para los desarrolladores de PHP:

https://stitcher.io/blog/new-in-php-8
https://stitcher.io/blog/php-jit
https://wiki.php.net/rfc/nullsafe_operator

¿Cómo aprovechar PHP 8 en nuestra plataforma?

Todos nuestros clientes pueden cambiar la versión PHP de sus sitios web desde su panel de control – Site Tools > sección Desarrolladores, o cPanel > Versiones PHP -. Dado que PHP8 sigue siendo una versión de prueba, te recomendamos encarecidamente que no lo habilites para tus sitios web activos, sino que ejecutes pruebas con él en nuestro entorno de pruebas (disponible para los planes GoGeek y Cloud), o crees copias de tus sitios web si no tienes la función de staging.

Por el momento, hemos implementado PHP 8 sin los siguientes módulos: mcrypt, geoip, ioncube.

Danos tu opinión y gana un elefante PHP

Hemos intentado darte una idea general de lo que es el nuevo PHP8. Ahora nos gustaría saber lo que realmente piensas al respecto, una vez tengas la oportunidad de probarlo. ¿Qué te gusta y qué no te gusta? ¿Cómo funciona en tu sitio web? ¿Ves alguna mejora en el rendimiento? Buscamos explorar cómo nuestros usuarios más experimentados aprovechan esta versión de prueba de forma anticipada antes de que se lance como versión oficial.

Para animarte compartir con nosotros los resultados de tus pruebas y tu opinión, ¡hemos creado peluches con el diseño de los elefantes PHP originales para celebrar este nuevo lanzamiento! Regalaremos 5 elefantes de forma aleatoria a 5 de los usuarios que compartáis vuestra opinión sobre PHP8 antes del 26 de noviembre de 2020 en un comentario debajo de este artículo, o haciendo una publicación en Facebook o Twitter, etiquetando a @SiteGround_ES para twitter o a @siteground.esp para Facebook, y usando el hashtag #PHP8 en vuestra publicación.

¡Déjanos tu comentario y mucha suerte!

Posted on

Informe de progreso del cambio de cPanel a Site Tools

Progreso del cambio de cPanel a Site Tools

Ha pasado poco más de un año desde que lanzamos nuestras nuevas interfaces de cliente: el nuevo Área de Cliente y Site Tools, que desarrollamos internamente y con el que reemplazamos cPanel. En agosto de 2019 comenzamos a incorporar a todos los nuevos clientes a las nuevas interfaces y poco después comenzamos a trabajar en la migración de nuestros clientes existentes. Actualmente, todos nuestros clientes ya están utilizando el nuevo Área de Cliente y también hemos migrado con éxito más de 9000 servidores de cPanel a Site Tools.

Mirando hacia atrás en los últimos 12 meses, evaluando la complejidad del proceso de migración y los desafíos no relacionados con ella que 2020 ha puesto frente a nosotros, creo que hemos logrado mantener un buen ritmo de migración. Esto se ha logrado gracias a la enorme cantidad de trabajo que han hecho todos los equipos involucrados en la migración, a pesar de los retrasos ocasionales que se dieron por diversas circunstancias. Aún así, nos quedan todavía muchas más cuentas y servidores por migrar y muchos de vosotros os estaréis preguntando por qué nos está llevando tanto tiempo y cuándo llegará el turno de tu sitio web. Es por eso que hemos decidido hacer un seguimiento y contarte la historia de lo que hemos hecho entre bastidores durante el año pasado y cuál es el pronóstico para los próximos meses.

La complejidad innata de la migración

No es sorprendente que la migración de más de un millón de sitios activos de cPanel a Site Tools sea un proceso tremendamente complejo. Podría decir que es comparable en términos de esfuerzos y recursos necesarios a la creación de las nuevas interfaces y sistemas en sí. Es todo un desafío mover los sitios operativos de una plataforma con una determinada estructura a una nueva plataforma con una completamente diferente, sin afectar la disponibilidad y el funcionamiento de estos sitios web.

En la superficie, parece que solo hay una diferencia simple entre los dos marcos: no hay sitios adicionales bajo un mismo capó. Lo que esto realmente significa es que tenemos que poder “desenredar” los sitios web secundarios de la cuenta principal de cPanel y volver a crearlos como cuentas independientes en nuestra nueva plataforma. Y para ilustrar cuán complejo puede ser este proceso para diferentes configuraciones de sitios web, enumeraré algunos ejemplos a continuación:

Múltiples dominios adicionales usando una misma base de datos

Normalmente, esto no es algo razonable, ya que cada sitio web, incluso los dominios adicionales, deberían utilizar su propia base de datos. Sin embargo, esto era técnicamente posible con cPanel y hay sitios web reales configurados de esta manera por nuestros clientes. Cuando un sitio web de este tipo necesita ser migrado, nuestro script de migración tiene que detectar el caso y crear una base de datos separada para cada sitio y copiar los datos. Después de eso, el script re-configura automáticamente cada sitio web para usar la respectiva base de datos.

Aplicaciones con rutas absolutas en su configuración

Otra cosa que el script de migración debería corregir es que múltiples aplicaciones estén configuradas para usar rutas absolutas en su configuración. El sistema tiene que detectarlos y, una vez que se conviertan en sitios independientes con diferentes usuarios del sistema, re-configurarlos automáticamente para usar las nuevas rutas del sistema.

Opciones de configuración infinitas para dominios adicionales, aparcados y subdominios

El número infinito de formas en que los usuarios pueden configurar y, a veces, estropear sus rutas al directorio raíz para las diferentes aplicaciones cuando usan la función de dominios adicionales, aparcados y subdominios en cPanel es el mayor desafío para nuestro proceso de migración. Hemos logrado identificar más de 30 formas diferentes de casos de rutas al directorio raíz poco ortodoxos. Uno de los ejemplos más comunes es cuando más de un dominio adicional está configurado para usar la misma carpeta. Este es un “truco” común del sistema cPanel que la gente usa para aparcar un segundo dominio en un sitio adicional, una opción que oficialmente no está permitida en cPanel. Entonces, en tales configuraciones, el sistema tiene que decidir automáticamente a qué sitio se dirige cada dominio y en qué rol (principal o aparcado). En algunos casos, la configuración es tan compleja que los dominios no se pueden configurar automáticamente y la migración debe realizarse manualmente.

Una compleja tarea de desarrollo 

Automatizar todos los procesos posibles

Comenzamos nuestras primeras migraciones en septiembre del año pasado con mucha cautela. Los sitios migrados se revisaron manualmente y cada uno de los problemas descritos anteriormente, además de muchos más que aparecieron, se han abordado con nuevas iteraciones del script de migración. No hace falta decir que las comprobaciones manuales de las primeras migraciones llevaron mucho tiempo y no era algo que pudiera ser sostenible a largo plazo, por lo que hemos añadido varias automatizaciones adicionales al script de migración.

Ahora realizamos comprobaciones previas automatizadas de todas las cuentas que se van a migrar. Si hay indicios de un posible problema, lo solucionamos antes de que comience la migración. Después, la cuenta se migra de cPanel a Site Tools. Una vez que finaliza la migración, realizamos otra verificación automática para detectar problemas posteriores a la migración. Si se detecta algún problema, la cuenta se marca para revisión manual. Además, hemos desarrollado un sistema automatizado para comunicar el progreso de este proceso al el cliente cuyas cuentas se están migrando. Con todos estos sistemas en uso, podemos migrar alrededor de 900 cuentas de cPanel por día con una tasa de fallos muy baja.

Cambiar primero al nuevo área de cliente

Al principio planificamos migrar a cada cliente simultáneamente al nuevo Área de Cliente y el nuevo Site Tools. Sin embargo, pronto nos dimos cuenta de que sería mucho mejor desligarlos y pasar a todos los clientes primero al Área de Cliente. Hubo varias razones para esta decisión:

  • En primer lugar, la migración del área del cliente tenía por sí misma menor riesgo, ya que no afectaba directamente la funcionalidad de los sitios web alojados.
  • En segundo lugar, nos dimos cuenta de que proporcionar primero el Área de cliente les daría a todos nuestros clientes algo de tiempo para acostumbrarse a las nuevas interfaces. Apreciamos el esfuerzo necesario para aprender una nueva interfaz, por lo que dando la oportunidad de acostumbrarse primero a nuestra nueva lógica de UX con el nuevo Área de cliente, pretendíamos hacer que la transición a Site Tools, con mayor cantidad de funcionalidades, fuera más fluida para nuestros usuarios.
  • Y tercero, el mantenimiento diario de dos interfaces distintas de Área de Cliente (la antigua y la nueva) le quitaba un tiempo muy valioso a nuestro equipo técnico. Tiempo que se podía invertir en perfeccionar los scripts de migración.

La decisión de desligar la migración de ambas interfaces requirió un cambio temporal de enfoque, ya que supuso invertir algo de tiempo de desarrollo para acomodar las cuentas de cPanel en la nueva interfaz del Área de Cliente, algo que no estaba planeado inicialmente. Sin embargo, a largo plazo creemos que esta decisión agilizó la fecha de finalización de toda la migración. Estamos muy orgullosos de que todos nuestros clientes estén utilizando con éxito el nuevo Área de Cliente desde mayo de 2020.

Los desafíos de 2020

Como todos sabemos, este año ha sido extremadamente impredecible y para perfeccionistas como nuestro equipo directivo, la planificación se ha convertido en un quebradero de cabeza con demasiadas variables y factores dinámicos que inevitablemente ralentizaron las migraciones durante el año.

Migración a la plataforma de Google Cloud

Una de las cosas que nos hizo reorganizar nuestros planes iniciales fue realmente positiva: la finalización de nuestro contrato con Google Cloud. Mover nuestro servicio a una plataforma basada en la nube fue el otro gran proyecto en el que hemos estado trabajando en los últimos años. Sabíamos que pasar a Google Cloud proporcionaría muchos beneficios inmediatos a todos nuestros clientes y completar primero esta migración nos permitiría dedicar todos los recursos al cambio, mucho más complejo, a Site Tools. Por lo tanto, una vez finalizado el contrato con Google, se priorizó la migración a Google Cloud en la cola de nuestros equipos DevOps y SysAdmin. Trabajaron rápido e hicieron un gran trabajo: logramos migrar toda nuestra plataforma a Google Cloud en menos de 4 meses. ¡Y estamos hablando de más de 4 PB de datos! Aunque una gran parte de nuestros recursos se invirtió en la migración de Google durante varios meses, mientras tanto logramos hacer un trabajo considerable para pulir los scripts de migración de Site Tools.

El efecto COVID-19

Por supuesto, no podemos olvidar el efecto COVID-19. Durante abril y mayo, con las cuarentenas que afectaron a muchos de nuestros mercados geográficos, hemos visto un aumento sin precedentes en las consultas de soporte. Era natural, ya que la presencia online de repente se volvió mucho más importante para una gran cantidad de personas y empresas, lo que ha llevado a un mayor nivel de actividad por parte de todos los propietarios de sitios web. Estábamos realmente abrumados y, por primera vez desde que comenzamos nuestra actividad, tuvimos que dedicar literalmente todos nuestros recursos a la atención al cliente. A pesar de contratar a nuevo personal, el volumen de trabajo era tan grande que cada departamento tenía que enfocarse y contribuir de alguna manera a la prestación del servicio y la optimización de cómo se entregaba ese servicio. Una vez más, eso nos estaba alejando el enfoque en las migraciones y, aunque mantuvimos un equipo central trabajando en ellas, la atención directiva y operativa estaba en otra parte y las migraciones fueron más lentas durante este período.

Dicho esto, sigo creyendo que logramos abordar los dos grandes eventos de 2020 bastante bien y logramos mantenernos razonablemente encaminados con nuestro tercer esfuerzo principal: la migración a las nuevas interfaces.

Estado actual de la migración

Por el momento, las cuentas Cloud se están migrando con la máxima prioridad. Nuestro objetivo es completar la migración de la mayoría de las cuentas Cloud a mediados de diciembre. Hay un pequeño porcentaje de cuentas Cloud que no están incluidas en este plan. Estas son cuentas en las que se utilizó la funcionalidad WHM existente para crear planes de cPanel personalizados. Esto significa que el propietario del Cloud estableció límites de recursos personalizados para las cuentas de cPanel separadas en la nube. Como preservar esta configuración es una seria complejidad adicional que debe abordar la secuencia de comandos de migración, tendremos que posponer la migración de dichas cuentas. (En caso de que tengas una cuenta Cloud de este tipo y creas que no necesitas mantener la configuración personalizada de tu cuenta de cPanel, puedes comunicarte con nosotros a través de la categoría “Otros problemas técnicos” que encontrarás en tu Centro de Ayuda y solicitar su inclusión en el programa de migración Cloud actual. )

Mientras tanto, también estamos trabajando duro en las migraciones de servidores compartidos. Debido al mayor volumen de datos en ellos y a las diferentes especificaciones de configuración, su tasa de migración es mucho menor en este momento. Sin embargo, ahora que estamos cerca de finalizar la migración de las cuentas Cloud, hemos concentrado más recursos en optimizar el proceso de migración de servidores compartidos y esperamos ver una mayor cantidad de cuentas compartidas migradas en las próximas semanas.

En nombre de todo el equipo de SiteGround, me gustaría daros las gracias a todos por la paciencia de este año. Somos plenamente conscientes de que hemos creado expectativas de un cambio y que puede llevar más tiempo de lo previsto, pero realmente hacemos todo lo posible para que este cambio tan complejo ocurra lo antes posible y, al mismo tiempo, para que sea  una experiencia segura y fácil para todos nuestros clientes.

Posted on

PHP ultrarrápido para webs hasta un 30% más rápidas

PHP ultrarrápido

La velocidad es uno de los pilares de nuestros servicios de alojamiento y trabajamos constantemente para hacer que nuestra infraestructura sea más rápida y estable. Uno de los elementos esenciales para una velocidad de carga rápida es la configuración del servidor PHP y ahora, con nuestra nueva plataforma Site Tools y sin las limitaciones del sistema anterior, nuestro equipo de DevOps ha tenido la oportunidad de desarrollar un PHP nuevo y mejor: la configuración de PHP ultrarrápido, que es hasta un 30% más rápido y tan seguro como todo lo que hacemos.

Configuración PHP ultrarrápido y súper seguro

Por sí solo, ejecutar un PHP rápido no es una tarea difícil. Sin embargo, si deseas un PHP rápido, estable y seguro, a la vez que sea compatible con Apache y la variedad de reglas .htaccess definidas por los usuarios y las aplicaciones, las cosas se complican. Queríamos resolver estos problemas y, al mismo tiempo, aumentar la velocidad de carga de la página y mejorar la estabilidad del servidor durante los picos de tráfico. Entonces, una vez que lanzamos el nuevo área de cliente y Site Tools y nos deshicimos de las principales limitaciones que nuestra antigua plataforma nos imponía, modificar nuestra configuración de PHP se convirtió en una de las prioridades de nuestro equipo de DevOps.

Después de varios intentos, logramos superar el mayor desafío de “velocidad sobre seguridad” y conseguimos ofrecer un PHP rápido con nuestro WAF y aislamiento de cuenta integrados, obteniendo así mejores resultados de rendimiento sin comprometer la seguridad. La nueva implementación es súper rápida, segura y eficiente.

[subscribe_cta]

PHP ultrarrápido vs PHP estándar

Si bien la configuración de PHP ultrarrápido es más rápida y se recomienda para sitios web con mucho tráfico, la configuración de PHP estándar proporciona cierta flexibilidad adicional para las versiones de PHP y la gestión de variables.

PHP ultrarrápido: recomendado para sitios web con muchas visitas

Los sitios web que se beneficiarán más de PHP ultrarrápido son los que tiene un tráfico sólido y pueden estar experimentando un déficit de recursos en el plan actual que utilizan. Según las estadísticas preliminares que hemos realizado, vemos los siguientes datos:

  • Respuesta de página más rápida: hasta un 50% de reducción en el TTFB (tiempo hasta el primer byte), lo que hará que tus páginas se carguen más rápido que antes;
  • Mayor capacidad del servidor: el nodo host podrá procesar entre un 20 y un 30% más de solicitudes, lo que significa que podrá manejar aún mejor los picos de tráfico;
  • Menor uso de la memoria del servidor: hasta un 15% menos de uso de la memoria, lo que nuevamente deja libres los recursos del servidor para manejar más tráfico y más rápido.
  • Se espera una mejora general de rendimiento: actualmente, el promedio de PHP ultrarrápido es un 30% más rápido que la configuración anterior.

Nota: los números anteriores son promedios basados en nuestras pruebas y los resultados particulares pueden variar según el sitio.

La configuración de PHP ultrarrápido está disponible para sitios web alojados en planes GoGeek y Cloud, ya que estos planes suelen alojar el tipo de sitios con mayor probabilidad de beneficiarse de las mejoras de rendimiento que aporta. También es importante señalar que funciona para sitios que se ejecutan en PHP 7.3 o superior y no es compatible con versiones anteriores. Además, en el momento en que utilices PHP ultrarrápido, todos los subdominios de tu sitio web heredarán la versión de PHP y la configuración de variables del dominio principal.

PHP estándar: permite diferentes configuraciones de PHP para cada subdominio

La configuración estándar de PHP es la que utilizan todas las cuentas basadas en StartUp, GrowBig y cPanel. También está disponible como una alternativa a la configuración de PHP ultrarrápido en cuentas GoGeek y Cloud con Site Tools. Su rendimiento sigue siendo bastante bueno para sitios web pequeños y estándar. Su mayor ventaja es que te permite administrar las versiones y variables de PHP por separado para cada subdominio de tu sitio web.

Como PHP estándar brinda más flexibilidad para experimentar, todos los sitios web de prueba también están configurados con él. Por lo tanto, si necesitas usar una versión de PHP anterior a 7.3 o necesitas una configuración con diferentes versiones de PHP y variables por subdominio, la configuración de PHP estándar es la adecuada para ti.

¿Cómo cambiar a PHP ultrarrápido?

Posted on

Los retos de los sitios web en 2020: ¿estás preparado?

En nuestra encuesta anual, preguntamos a nuestros clientes cuáles fueron los mayores desafíos del sitio web que previeron encontrar en 2020, planteándonos qué podríamos hacer para ayudarles a superarlos. Ahora que estamos casi a mitad de año, es hora de volver a revisar lo que hemos hecho hasta ahora para abordar esos desafíos y compartir algunas ideas sobre cómo te podemos ayudar a abordarlos y qué hacer al respecto.

La ciberseguridad es el mayor desafío

La mayoría de nuestros encuestados (54%) consideraba mantener sus sitios seguros como el mayor desafío técnico en 2020. ¡Y estamos totalmente de acuerdo con vosotros! La ciberseguridad es un proceso continuo que debe estar en la mente de cualquier usuario de Internet, profesional o de otro tipo.

Desde la perspectiva de una empresa de hosting web, aquí en SiteGround, sabemos que mantener seguros nuestros sitios y usuarios es una tarea continua. Los piratas informáticos y todo tipo de delincuentes web se están volviendo más inteligentes cada día y la evolución constante y rápida de la tecnología deja muchas puertas abiertas para las vulnerabilidades de software. Mantener actualizado el software en nuestros servidores (como Apache, Nginx, PHP, MySQL, etc.) es la primera y más básica línea de defensa, pero casi no es suficiente.

Es por eso que contamos con un equipo especial de expertos en seguridad cuya responsabilidad principal es realizar un seguimiento de los informes de seguridad y monitorizar posibles exploits no anunciados. Una vez que obtienen una confirmación de una nueva vulnerabilidad, actúan rápidamente para escribir reglas de firewall personalizadas que la parchean en el día cero y protegen los sitios web que alojamos.

Luego hay que mantenerse al día con las últimas tecnologías que podemos integrar como por ejemplo con los protocolos de cifrado que garantizan una conexión segura entre su navegador y el servidor que entrega el contenido. Nos aseguramos de tener siempre el más reciente disponible para que lo usen nuestros clientes: fuimos los primeros en implementar HTTP/2, QUIC y HTTP/3 y más.

Al mismo tiempo, una de las amenazas más frecuentes contra cualquier sitio web son los ataques DDOS, que se vuelven más feroces y prolongados a medida que los recursos del servidor se vuelven más baratos con el tiempo. Es por eso que nuestros administradores de sistemas monitorean la salud de nuestros servidores 24h y toman medidas inmediatas para desviar el tráfico malicioso a través de dispositivos de software y hardware.

Además, hay ataques de fuerza bruta, una de las formas más comunes de piratear un sitio web adivinando sus detalles de inicio de sesión. Extendemos nuestra protección a nivel de servidor con un software anti-bot interno con tecnología de IA que monitoriza el tráfico malicioso y bloquea de 500.000 a 2 millones de intentos de fuerza bruta al día.

Todo el trabajo de seguridad que hacemos como tu hosting debería darte tranquilidad, pero funcionaría aún mejor si sigues algunas pautas de seguridad:

  • Usa contraseñas complejas y no las compartas con nadie. Se recomienda utilizar una combinación de letras y números, preferiblemente sin sentido, de aproximadamente 8 símbolos de longitud para asegurarse de que adivinar o forzar su contraseña sea extremadamente difícil.
  • Instala un certificado SSL. En caso de una violación de seguridad, el cifrado de la conexión mantendrá tus datos seguros (ofrecemos el certificado Let’s Encrypt gratis).
  • Usa la autenticación de doble factor para iniciar sesión en tus aplicaciones y más específicamente en tu Área de Cliente de SiteGround. Esto hará que sea bastante difícil para cualquiera iniciar sesión, incluso si conocen tu nombre de usuario y contraseña. Lee aquí cómo puedes habilitar la autenticación de doble factor.
  • Asegúrate de ejecutar la última versión estable de PHP y WordPress o cualquier otro CMS que puedas estar utilizando para tu sitio. Muchos clientes posponen las actualizaciones de PHP, e incluso las actualizaciones más simples de WordPress, por temor a que rompan su sitio y tengan que pagarle a un desarrollador para que lo arregle. Pero créenos, cuando decimos esto: es mucho más costoso arreglar un sitio web pirateado que las pocas consultas rotas que potencialmente resultan de una actualización de versión. Además, ofrecemos actualizaciones automáticas de WordPress administrado y un servicio PHP administrado, habilitado de forma predeterminada para todas las cuentas nuevas, y lo que significa que actualizaremos automáticamente tu PHP y WordPress, para que no tengas que hacerlo.
  • También recomendamos instalar un escáner de malware directamente en tu sitio para que puedas recibir una alerta en caso de incumplimiento y actuar rápidamente. Puedes usar un plugin, si es una instalación de WordPress, o usar una función externa como el popular escáner antimalware que ofrecemos (SG SiteScanner).

Para obtener más información sobre las mejores prácticas en seguridad de WordPress, te recomendamos que consultes nuestro libro electrónico 21 trucos para mantener tu WordPress seguro.

Mejorar la velocidad del sitio web es el segundo mayor desafío

Mejorar la velocidad del sitio web es el segundo mayor desafío para los webmasters, ya que el 48% de todos los encuestados lo mencionan. Se pueden hacer muchas cosas para mejorar el rendimiento del sitio web y, al igual que la seguridad, es una tarea continua. Como hosting web, hemos hecho muchas cosas para aumentar la velocidad de los sitios web en nuestros servidores, pero nos centraremos en algunos de los más recientes.

Hemos estado trabajando en una solución completa de rendimiento de WordPress integrada en nuestro plugin SiteGround Optimizer. El plugin se conecta con el servidor host para permitir que los sitios aprovechen la capacidad de almacenamiento en caché y también integra una amplia gama de características de rendimiento front-end, sobre las que puedes leer más aquí.

¡Un paso aún mayor para nuestro aumento de rendimiento este año fue la migración a la infraestructura de Google Cloud, que nos permite usar su red extremadamente rápida, alta redundancia y potentes CPU N2 que ofrecen un rendimiento casi un 40% más rápido!

Además, con el lanzamiento de nuestro nuevo Site Tools, reemplazamos la caché estática con NGINX Direct Delivery. Ya no servimos imágenes, CSS, archivos JS y otro contenido estático desde la memoria del servidor, sino que usamos NGINX para la carga directa de estos archivos desde el SSD. Esto mejora el almacenamiento en caché del navegador para tu sitio y también hace que el uso de CDN sea más fácil y más eficiente. Lo más importante, NGINX Direct Delivery permite que se use más espacio RAM para el almacenamiento en caché de contenido dinámico, sin comprometer la velocidad de carga de contenido estático.

Dado que la velocidad del sitio web es un factor tan crítico, hay algunas cosas adicionales que puede hacer tú mismo para mejorar el rendimiento:

  • Usa el plugin SiteGround Optimizer y activa el almacenamiento en caché dinámico. Por defecto, todos nuestros sitios en todos los planes tienen la caché estándar (NGINX Direct Delivery) activada y ayuda enormemente a la mayoría de los sitios. Pero los sitios más dinámicos también necesitan el almacenamiento en caché dinámico e incluso Memcached activado.
  • Activa las funciones de rendimiento de front-end de SiteGround Optimizer: la compresión de imágenes, el uso del formato WebP y la carga asíncrona, la minimización de CSS y JavaScript pueden tener un impacto menor individualmente, pero cuando se suman, el efecto en la velocidad de carga de la página es espectacular.
  • Usa un CDN (red de entrega de contenido). Las CDN aceleran los sitios inmensamente al almacenar en caché y entregar contenido estático desde la ubicación más cercana al usuario, ahorrando preciosas fracciones de tiempo. Ten en cuenta que un CDN también bloquea el tráfico malicioso e incluso reduce el SPAM, por lo que existen otras ventajas al usar uno.

Si deseas leer consejos adicionales sobre cómo acelerar tu sitio WordPress, asegúrate de consultar el libro electrónico gratuito 21 trucos para tener una web en WordPress ultrarrápida.

Gestionar el crecimiento del sitio también se encuentra entre los 3 desafíos principales

Alrededor del 32% de todos nuestros usuarios dijeron que gestionar el crecimiento de su sitio web era un desafío que esperaban experimentar en 2020. Hay dos tipos de tráfico que debemos considerar: esperado e inesperado. En la era de la viralidad de Internet, nunca se sabe cuándo tu sitio se volverá popular en Reddit u otros medios y será bombardeado con tráfico. Al mismo tiempo, puedes predecir razonablemente bien el crecimiento en Black Friday y otros periodos de compras. Así es como abordamos el problema del crecimiento del sitio:

Monitorizar el crecimiento normal de tu sitio

Cuanto más crezca tu negocio, más tráfico obtendrás, más pedidos se procesarán y, por lo tanto, más ocupado estará tu sitio web. Hay dos indicaciones de que tu sitio está creciendo y necesitas evaluar su rendimiento: carga lenta de páginas y errores en el sitio web (el sitio deja de estar disponible ocasionalmente).

  1. Lo primero que debes hacer es intentar optimizar tu sitio: haz que un desarrollador revise tu código, plugins, consultas de la base de datos y estructura y sugiera mejoras. Comenzando con cosas simples como eliminar plugins antiguos y no utilizados, reducir la cantidad de plugins, activar la memoria caché y pasar a plugins más complejos como volver a escribir parte del código, hay muchas cosas que pueden ayudar en esta etapa, que también son buenas para la salud a largo plazo de tu sitio.
  2. Una vez que estés seguro de haber optimizado todo lo que puedes y si aún así experimentas problemas, considera actualizar tu plataforma de hosting. Si comenzaste con el alojamiento compartido, tal vez sea hora de pasar a la nube y configurar con precisión la RAM, la CPU y el espacio que necesitas.

Estar preparado para lo inesperado

Esto es más complicado ya que obviamente no hay mucho que puedas hacer por cosas que no esperas, pero hay 3 cosas que pueden ayudar:

  1. Activa el almacenamiento en caché: de nuevo el almacenamiento en caché es increíble no solo porque acelera tu sitio, sino también porque ahorra recursos del servidor, especialmente RAM, al usar NGINX para cargar archivos directamente desde el SSD. Ahorrar recursos significa que podrás procesar más visitantes al mismo tiempo.
  2. Activa CDN: actúa de la misma manera que el almacenamiento en caché, porque el CDN almacena en caché tu contenido y lo almacena en muchos servidores en todo el mundo, luego lo entrega desde el servidor más cercano a tu visitante. Por lo tanto, no utiliza los recursos del servidor para entregar la información y nuevamente tu sitio es capaz de procesar muchas más visitas simultáneamente.
  3. Activa el escalado automático en la nube: esta opción aumenta de forma automática e instantánea los recursos de CPU y/o RAM de tu nube en momentos de necesidad, evitando tiempos de inactividad en momentos cruciales, como Black Friday o las compras navideñas.

Esperamos que te hayamos ofrecido un informe sobre lo que nosotros, como hosting de tu sitio web, hacemos para ayudarte con tus 3 desafíos principales del sitio web este año, así como ideas sobre qué más puedes hacer para abordarlos.