Atraer, Convertir, Sostener Claves para la rentabilidad de un E-commerce

-2-

Atraer, Convertir, Sostener

El Impacto del Rendimiento en

la Web

Sebastián RodríguezService Design de nexica

-3-

Impacto del Rendimiento en 3 áreas

SEO Experiencia de Usuario Disponibilidad

-4-

Impacto en 3 áreas: SEO SEO Experiencia de Usuario Disponibilidad

• Google tiene en cuenta el tiempo de carga de la página en el posicionamiento orgánico (Google > 95% búsquedas en España)

• Nuestra calificación se establece de forma relativa, por comparación al rendimiento de las demás Webs analizadas por Google (según la fórmula y = 122.32e-0.31x)

• Podemos conocer nuestra puntuación a través de Google Webmaster Tools.

• Nos interesa compararnos con nuestra competencia, con quien compite en resultados por nuestras posiciones.

• No es un factor determinante, pero sí un factor más.

-5-

Impacto en 3 áreas: SEO SEO Experiencia de Usuario Disponibilidad

“While site speed is a new signal, it doesn't carry as much weight as the relevance of a page. Currently, fewer than 1% of search queries are affected by the site speed signal”

http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html

• SEOmoz llevó a cabo un experimento para determinar le impacto que el rendimiento tiene sobre el TOP10.

• El experimento reveló que no tiene una afectación significativa para los primeros resultados (que tienen altos índices de relevancia por otras métricas), pero que sí puede contar en el “Long Tail”.

• Las conclusiones apuntan a que la velocidad de carga puede actuar más como un factor de penalización que como una mejora (páginas mucho más lentas que la competencia pueden verse penalizadas, mientras que un buen rendimiento queda fácilmente superado por otros criterios de relevancia)

http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html

-6-

Impacto en 3 áreas: Experiencia SEO Experiencia de Usuario Disponibilidad

Even small changes in response times can have significant effects. Google found that moving from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20%.When the home page of Google Maps was reduced from 100 KB to 70–80 KB, traffic went up 10% in the first week and an additional 25% in the following three weeks.5 Tests at Amazon revealed similar results: every 100 ms increase in load time of Amazon.com decreased sales by 1%

Website Optimization, Andrew B. King, Ed. O’Reilly

0,1 segundos Respuesta instantánea Necesario para interfaces de manipulación directa (GUI)

1 segundo Experiencia fluida Recomendable para navegación

10 segundos Límite de atención Máximo tolerable para no perder la atención del usuario

Jakob Nielsen Alertbox, http://www.useit.com/alertbox/response-times.html

http://www.useit.com/alertbox/response-times.html

-7-


Bounce Rate

Reducción del tiempo de carga

(-200 Kb)

Modificaciones a la Web (imágenes)

http://www.paperstreet.com/blog/2094

http://www.webperformancetoday.com/2010/07/01/the-best-graphs-of-velocity/

http://www.paperstreet.com/blog/2094

http://www.webperformancetoday.com/2010/07/01/the-best-graphs-of-velocity/

-8-


http://www.apdex.org/

• Un grupo de empresas (especializadas en medir la experiencia de usuario) han desarrollado un índice de satisfacción de usuario basado en el tiempo de respuesta: APDEX

• Representa el porcentaje de usuarios satisfechos según unos umbrales de rendimiento preestablecidos.

• Partimos del hecho de que no todos nuestros usuarios tendrán el mismo rendimiento (realista en entornos Web)

• Es una buena herramienta para establecer objetivos de rendimiento en relación a la experiencia de nuestros usuarios.

• Existen herramientas que y servicios que nos permiten medir el rendimiento en términos de Apdex.

http://www.apdex.org/

-9-


Cloud Computing, Arquitecturas

Elásticas y Aceleradores


-10-

¿Qué es Cloud Computing?• Es un nuevo paradigma en la prestación de servicios

tecnológicos (una nueva forma de vender y consumir estos servicios)

• No es una tecnología sino un concepto de negocio. Esto hace que cada proveedor emplee diferentes tecnologías (y puntos de vista) en la materialización de este tipo de servicios.

• Las características fundamentales y definitorias de este paradigma son:

• Agilidad en la provisión• Pago por uso• Elasticidad

-11-

Tipos de Cloud

-12-

Beneficios del CloudAgilidad en la Provisión

A través de la virtualización (de servidores, redes, almacenamiento) y combinado con paneles de control Self-Service, se reduce la provisión de días a minutos.

Pago por Uso

Pagar por lo que se consume en cada momento (por horas) elimina la infrautilización de recursos que se daba con el tradicional sobredimensionamiento de las plataformas. Se sustituye CAPEX por OPEX.

Elasticidad

La capacidad de la plataforma para redimensionar sus recursos en función de la demanda y de la calidad de servicio. Construir plataformas elásticas es mucho más fácil en el Cloud (virtualización, estandarización de servicios, API’s, etc.)

Economías de Escala

El acceso a recursos compartidos del proveedor nos permite aprovechar economías de escala y acceder a innovaciones a bajo coste.

-13-

Beneficios del Cloud Hosting

Diseño Instalación Operación Ampliación Operación

Diseño Instalación OperaciónAmpliación / Reducción (Elasticidad)

(t)

(t)

Hos

ting

Tra

dici

onal

Clo

ud H

ostin

g

Coste

Capacidad

Demanda

-14-

¿Me conviene el Cloud?

¿Cuál es el patrón de demanda?

Variaciones predecibles y periódicas.Ejemplo: Diurno / Nocturo

Variaciones puntuales Ejemplo: Presencia en medios

Crecimiento sostenido Demanda constante

¿Cuál es el tiempo de vida de los servidores?

Horas Días Meses Años

Beneficios Cloud

-15-

¿Me conviene el Cloud?

Capacidad de Autogestión de Servidores y Componentes

Calidad de la Arquitectura

Beneficios Cloud

Administradores de sistemas

Desarrolladores Departamentos TI Sin especialización tecnológica

Elasticidad

Shared Nothing

Stateless Computing

Caching

SOA

Puntos únicos de Fallo

Provisión manual

Silos

Crecimiento Vertical

Automatización

Crecimiento desordenado

-16-

Casos de Uso del Cloud

• Laboratorio de pruebas

• Servidores temporales para demostraciones comerciales

• Entornos de desarrollo, test y validación

• Aulas de formación (e-learning)

Servidores con un ciclo de vida corto

• Incremento temporal de la capacidad para servir página Web (elasticidad)

• Procesos muy intensivos en cálculo (procesamiento de la imagen, cálculos científicos, etc.)

Aumento temporal de la capacidad (Cloud Bursting)

¿Qué busca en el Cloud?

• Agilidad en la provisión y desprovisión

• Pago por uso

• Self-Service

• Construir arquitecturas elásticas

• Pago por uso

• Transparencia en los costes


-17-

Casos de Uso del Cloud

• Ofrecer soluciones SaaS basadas en nuestro IaaS

• Replicación de entornos PaaS definidos por el ISV (por cliente, por región, etc.)

• Integración con plataformas de cliente

Vendedores de Software Independientes (ISV)

• Agilidad en la provisión (de arquitecturas prediseñadas)

• Pago por uso

• Self- Service

• Interoperabilidad


• Virtualización de Datacenters

• Agilidad en la provisión de nuevas plataformas

• Separación de costes de TI por departamento

• Delegación selectiva de la gestión (capas más bajas)

Departamentos internos de TI

• Agilidad en la provisión (de arquitecturas prediseñadas)

• Pago por uso

• Self- Service o diferentes modalidades de gestión delegada.


-18-


Introducción a Arquitecturas

Elásticas


-19-

ElasticidadDistinguimos Elasticidad de Escalabilidad porque:

• La escalabilidad es intrínseca a la elasticidad

• La elasticidad, además, es instantánea y automática

• La elasticidad va en ambas direcciones: ampliar y disminuir la capacidad.

Además…

• La elasticidad no es una tecnología o un componente, sino una propiedad de los sistemas.

• Existen grados de elasticidad dentro de una plataforma. Por lo general, la elasticidad se consigue por capas (servidores web, bases de datos, balanceadores, etc.)

• La elasticidad no es exclusiva del Cloud, pero es más fácil conseguir arquitecturas elásticas a partir de las herramientas que proporciona el Cloud.

-20-

El Camino a la ElasticidadServidor Único

• No es elástica.

• Sólo escala verticalmente

• Sólo para aplicaciones no críticas. Solución de bajo coste.

• Viable como entorno de desarrollo

• Típica instalación LAMP

-21-

El Camino a la ElasticidadAislamos la base de datos


• Sólo escala verticalmente

• Solución de bajo coste.

• Viable como entorno de desarrollo

• Viable como entorno de producción para aplicaciones poco críticas.

• Es más fácil detectar el cuello de botella (servidor web o base de datos)

-22-

El Camino a la ElasticidadIntroducimos balanceo de carga


• Puede escalar horizontalmente en la capa de servidores (manual)

• Sólo escala verticalmente en la capa de base de datos.

• Es la arquitectura más comúnmente utilizada en entornos de hosting tradicional.

• El problema es que todos los servidores deben ser idénticos. La sincronización de los datos (código y configuración) es manual.

-23-

Servidores Stateless

El Camino a la Elasticidad

• Es elástica en la capa de servidores

• Al introducir el almacenamiento compartido, podemos configurar los servidores para que carezcan de estado (toda la información de configuración, estado y código se almacena en el volumen compartido)

• De este modo, el despliegue de un nuevo servidor puede ser automático a partir de plantillas estables.

• Necesitamos un “orquestador” que dimensione los recursos según diferentes inputs (puede ser el propio balanceador o un componente externo)

• Es transparente para el desarrollador.

-24-

Elasticidad de Base de Datos

El Camino a la Elasticidad

• Es elástica en la capa de servidores y base de datos

• La elasticidad de las bases de datos sólo es habitual en las tecnologías de gama alta (Oracle, SQL Server).

• Es difícil conseguir este tipo de elasticidad en MySQL. Existen técnicas que reparten la carga, pero no son transparentes para el desarrollador y no escalan linealmente (Master / Slave, Shardening)

• Existen tecnologías de terceros que permiten conseguir elasticidad en MySQL (Clustrix, ScaleDB, etc.)

-25-

Beneficios de la Elasticidad1. Mantener la calidad de servicio ante los usuarios

independientemente del número de solicitudes

2. Disminuir los tiempos de indisponibilidad (son arquitecturas redundadas)

3. Cuando se produce una indisponibilidad, se disminuye el tiempo hasta la recuperación (los nodos no tiene estado, existen plantillas de todo). Es más fácil sustituir que arreglar

4. Con un modelo de pago por uso, ahorramos los costes de sobredimensionamiento que conllevan las arquitecturas no elásticas.

-26-

Beneficios Adicionales en HA1. Nuevas estrategias de HA.

• Tradicionalmente buscamos maximizar el MTTF (Mean Time To Failure).

• Una arquitectura elástica donde los nodos carecen de estado y pueden desplegarse rápidamente nos permite basar nuestra estrategia de HA en minimizar el MTTR (Mean Time To Recover)

2. Servidores “Siempre en forma”

• Fallos en el software pueden hacer que los servidores se “degraden” con el paso del tiempo.

• Podemos renovar constantemente nuestros servidores en cuanto detectamos que se han degradado su rendimiento

Mean Time To Failure (MTTF)

Queremos pasar el máximo tiempo posible sin pérdida de dientes

Mean Time To Recover (MTTR)

Queremos tardar lo menos posible en regenerar el diente que hemos perdido.

-27-

Cloud ComputingSelf-Service

-28-

Self-Service• El factor que más pesa en la decisión de migrar hacia el Cloud es la agilidad

en el negocio.

• El Self-Service cumple un doble papel en este sentido:

• Reduce los costes del servicio para el proveedor (no necesariamente para el cliente, que debe dedicar un tiempo adicional a la configuración y gestión de su plataforma).

• Reduce los tiempos de provisión y puesta en marcha para el cliente.

• Existen grandes diferencias en el grado de implementación del self-service entre los distintos proveedores. Amazon es el ejemplo de una implementación total, mientras que otros proveedores como Telefonica, Terremark o Arsys lo han hecho en menor grado.

• Existen 2 herramientas fundamentales para ofrecer el Self-Service: Panel de control y API.

-29-

Self-Service

Puntos a Favor Puntos en ContraTengo un control total de mi plataforma, por lo que puedo obtener nuevos servicios en muy poco tiempo.

Aunque el coste de infraestructura pueda sea menor, el TCO de mi plataforma no lo es. El tiempo que el proveedor no dedica a gestionar las capas más altas de mi plataforma debo dedicarlo yo.

No tengo que explicar mis necesidades a nadie, simplemente configuro lo que quiero en cada momento.

Tengo que invertir tiempo en aprender a utilizar las herramientas y conceptos de un proveedor específico, y mantenerme al día con los cambios que va introduciendo en el servicio.

No pago por tareas que puedo hacer yo mismo. Yo soy responsable de mantener el servicio 24x7 (el proveedor me da la infraestructura base, pero no monitoriza ni mantiene mis servidores, aplicaciones, etc.)

Los costes son predecibles y transparentes, no tengo que pedir y negociar presupuestos, aprobar pedidos, etc.

La creación de arquitecturas elásticas es compleja y cualquier error puede suponer pagar altos consumos o sufrir cortes de servicio.

Puedo comparar diferentes proveedores de forma muy rápida, sin riesgo.

Los desarrollos que haga sobre la API de un proveedor no servirán para otro proveedor, lo que a la práctica es una barrera de salida.

Puedo automatizar tareas de gestión y control de la plataforma a través de las API.

Desde el punto de vista del cliente, un modelo de Self-Service total:

-30-

Self-Service – Por tipo de Cliente

Self Service

Total

Self Service Limitado

Gestionado

Empresas TI Sin personal TIDesarrolladores Departamentos TI

-31-


Aceleradores


-32-

AceleradoresQue nuestra plataforma de alojamiento sea elástica no quiere decir que los servidores sean gratis.

¿Cuántos usuarios puedo servir con cada servidor que pongo en producción? ¿Cuántos de esos usuarios acaban generando ingresos?

Con la elasticidad, ahora resulta que un bajo ratio de conversión ya no sólo impacta en mis costes de publicidad, sino también en los de infraestructura!

Tengo que maximizar el número de solicitudes (usuarios) que puede atender cada servidor para reducir la necesidad de crecer en servidores.

Corolario: Debería invertir más en la infraestructura de los usuarios que genera ingresos que en los que aún no lo han hecho y tienen pocas probabilidades de hacerlo?

-33-

AceleradoresTengo que maximizar el número de solicitudes (usuarios) que puede atender cada servidor para reducir la necesidad de crecer en servidores.

Pruebas de Stress• Diseño y ejecución de Pruebas

Base y Delta• Optimización de configuraciones• Ingenieros especializados

Monitorización de Aplicaciones

• Simulación de transacciones de usuario desde más de 50 países

• Atención de alarmas 24x7• Informes semanales / mensuales

Balanceo

• Balanceo inteligente. Escalabilidad horizontal.

• Caching de contenidos• Aceleración SSL

Firewall de Aplicaciones

• Prevención de ataques• Filtrado de solicitudes maliciosas• Mejor uso de los recursos

disponibles

Content Delivery Networks

• Partners CDNetworks• Asesoramiento, instalación y

monitorización

Profiling de Aplicaciones

• Actualmente disponible para plataformas J2EE y PHP

• Instalación, configuración y análisis.

Medir, Analizar, Optimizar Especialización y Descentralización

-34-

Caching

HTML, Imágenes, Objetos

Ej: Nexica ZXTM

Código precompiladoEj: APC

SQL Query’sEj: Memcached

-35-

Balanceo• No es en sí un acelerador, pero hace posibles arquitecturas horizontales

• Permite repartir la carga en función de diferentes políticas (por ejemplo, en función del tiempo de respuesta de cada nodo)

• Los servicios más avanzados permiten funciones adicionales:

• Asignar un pool de recursos para un perfil determinado de usuario (por ejemplo, los usuarios registrados que hayan realizado compras en el pasado o cualquiera que se encuentre en los pasos finales del funnel de conversión)

• Monitorizar los tiempos de respuestas de cada nodo y sacar de producción durante cierto tiempo aquellos que no respondan dentro de un tiempo razonable (liberar carga)

• Está situado en una posición estratégica dentro de la arquitectura para ofrecer servicios de aceleración: Aceleración SSL, Caching.

S1 S2 S3 S..

Balanceador

-36-

Firewall de AplicacionesProtección a nivel de Red

• IP Black/White List

• Fail-to-Ban

Protección a Nivel de Aplicación• OWASP Top10

• Flash Flooding: Gran volumen de tráfico en poco tiempo

• Cookie Tampering: Modificación de cookies (info de user)

• Forceful Browsing: Ataque a recursos no delimitados por la aplicación

• SQL injection: Vulnerabilidad en el codigo para entrar en BD.

• Cross-site scripting: Modificación cabeceras y código HTML

Protección anti DDoS• Control del volumen de conexiones por site.

-37-

Red de Contenidos• Servicio ofrecido por grandes empresas que disponen de cientos de servidores

distribuidos geográficamente

• Crean redes de contenido que se sincronizan con los servidores del cliente y actúan como una caché intermedia desde servidores más próximos al usuario final.

• Son una medida muy efectiva para webs con grandes volúmenes de tráfico y alcance global. Sus beneficios crecen a medida que lo hace el alcance geográfico del cliente (y viceversa)

• Existen varios niveles de integración (de menor a mayor complejidad)

• Servir el contenido estático puro (imágenes, textos, archivos flv, etc.)

• Servir contenido mixto (páginas estáticas con secciones dinámicas marcadas en el código)

• Servir contenido dinámico no personalizado.

• Las diferencias de precio son muy grandes. Akamai domina el mercado de “gama alta”, aunque hay otros actores con una calidad similar y mejores precios.

• Es importante monitorizar los resultados.

-38-

Atraer, Convertir, SostenerResumen


-39-

Para un E-commerce Sostenible• Elija el servicio que mejor se adapte a sus necesidades. No compre “Cloud”

por el nombre, sino por los beneficios de negocio que pueda aportarle frente a otras modalidades de servicio.

• Confíe en especialistas para diseñar su arquitectura. Implique desde el primer día a los desarrolladores en el diseño de la arquitectura y asegure una buena comunicación entre quien operaciones y desarrollo (google:DevOps).

• La estrategia de caching es uno de los factores más cruciales de la arquitectura y el que requiere más implicación de los desarrolladores (puede no ser transparente)

• Optimice el rendimiento de sus servidores (web, base de datos) optimizando su código y utilizando aceleradores (muchos son transparentes, plug&play)

• Monitorice constantemente el rendimiento de sus aplicaciones. Es posible perder todo el trabajo de optimización si nadie controla el rendimiento de las aplicaciones a lo largo de su evolución.

• Evite el sobredimensionamiento y las barreras de salida de cualquier plataforma.

-40-

Gracias por tu atenció[email protected]

¿Alguna pregunta?

Atraer, Convertir, Sostener Claves para la rentabilidad de un E-commerce

Business

Transcript of Atraer, Convertir, Sostener Claves para la rentabilidad de un E-commerce