Header Ads Widget

Ticker

6/recent/ticker-posts

4 mantras para diseñar API escalables


 La escalabilidad puede ser una palabra de moda, pero hay una razón para ello: puede definir tanto la adopción temprana como el éxito futuro, así como una variedad de puntos y enfoques a lo largo de la vida útil de un producto. Dicho esto, a menudo también se implementa de manera deficiente.

Abordar adecuadamente la escalabilidad es importante no solo para las soluciones incipientes en la industria, sino también para la industria misma. A medida que las aplicaciones crezcan y sean más exigentes, procesando cantidades cada vez mayores de datos, la escalabilidad se volverá mucho más importante de lo que ya es.

Hoy vamos a discutir la escalabilidad y lo que realmente significa. Analizaremos por qué la escalabilidad es tan increíblemente importante para diseñar API y microservicios robustos , y consideraremos las implicaciones de una escalabilidad adecuada en la industria web en su conjunto. Finalmente, proporcionaremos cuatro mantras ; cuatro conceptos básicos y repetibles que ayudarán a cualquier proveedor a adoptar la escalabilidad y cosechar sus recompensas.

¿Qué significa escalable ?

Se ha hablado mucho de la idea de escalabilidad y, a menudo, viene con un punto de venta. "Haga que su API sea escalable vinculándola a nuestra API simple" o "usted también puede hacer que su servicio sea escalable al otorgar una licencia a nuestro sistema de recopilación de terminales" son argumentos de venta comunes, pero desafortunadamente son engañosos.

Si se está vinculando a un servicio mágico para lograr la escalabilidad, es probable que no sea escalable; no hay una solución milagrosa y la adopción de una solución rápida no aborda las deficiencias arquitectónicas subyacentes . La escalabilidad en sí debería ocurrir en el nivel básico de la aplicación, y es más una ética de diseño que cualquier tipo de arquitectura o solución establecida.

En términos generales, la escalabilidad se puede definir así:

  • Extensible : el software escalable es extensible al nivel más básico. El diseño en sí no limita la funcionalidad y, en cambio, permite que múltiples vías se unan a los servicios y sistemas subyacentes para habilitar extensiones y otros servicios. Un ejemplo es API Gateway de Amazon .
  • Integrado en la arquitectura : la escalabilidad debe estar imbuida en las etapas fundamentales de la propia API. En pocas palabras, no compile y luego adopte la escalabilidad más adelante, cree la escalabilidad desde el principio . Las soluciones de terceros pueden ser valiosas para aumentar la escalabilidad, especialmente cuando ayudan a un enfoque construido a escala.
  • Implica el equilibrio de la demanda : tan importante como la extensibilidad es responder a la demanda. La escalabilidad implica que el manejo del tráfico se realiza tan bien con cien solicitudes como con un millón; está en el nombre, "escala". La implicación seria es que la escalabilidad exige naturalmente un rendimiento eficiente, independientemente de la técnica o metodología, tanto con tráfico extremadamente alto como con tráfico extremadamente bajo.

Cuatro mantras para la escalabilidad

Ahora que tenemos una mejor comprensión de lo que significa escalabilidad, aquí hay cuatro mantras que debemos seguir al diseñar API escalables.

1: Diseño para un día de lanzamiento repetido

El día en que se lanza un producto es quizás uno de los días más estresantes en la vida útil del desarrollo por una variedad de razones. Una de estas razones es el hecho de que no importa cuán buena sea su planificación de mercado, cuán efectivo sea su alcance, simplemente no puede conocer los requisitos que su sistema podría ver.

Al lanzar un servicio, ¿qué tipo de tráfico podemos esperar? Digamos que estamos lanzando una nueva plataforma social que se vincula a una API para unir perfiles sociales en un solo "centro". Hasta aquí todo bien. Hemos diseñado esta API para manejar un cierto volumen de llamadas; por simplicidad, digamos que 200 mil llamadas por hora es lo máximo que nuestro servidor puede manejar.

El problema es que no sabemos exactamente con qué tendrá que lidiar nuestro sistema. Nuestro centro podría aparecer en una publicación de Reddit, compartido en Facebook, mencionado en un video de YouTube y, antes de que se dé cuenta, nuestra tasa de llamadas de 200 mil por hora se ha disparado a varios millones de llamadas.

Solicitud

¿Qué significa esto para la escalabilidad? Debe abordar la base de su API como si siempre estuviera al borde del lanzamiento . Asegurarse de que está utilizando un equilibrador de carga adecuado es muy importante y, en muchos casos, puede ser la diferencia entre el éxito y el fracaso. Asegurarse de que su API tenga rutas de conmutación por error y funciones secundarias puede marcar una gran diferencia no solo en la usabilidad de su API, sino también en la experiencia general del usuario.

De hecho, en algunos casos, los problemas del servidor se pueden omitir por completo. Si estamos realmente preocupados por la escalabilidad y anticipamos que nuestro servicio tendrá fluctuaciones extremas en el tráfico, podemos decidir simplemente optar por una solución sin servidor como Amazon Web Services . Al conectarnos a un sistema extensible y permitir que nuestro tráfico se descargue a través de rutas codificadas en la arquitectura API, podemos escalar dinámicamente para satisfacer casi cualquier demanda; en esencia, podemos esperar lo inesperado.

Por último, una de las mejores formas de planificar el lanzamiento es integrar la analítica en su sistema. El día del lanzamiento es un misterio, y nunca habrá una predicción perfecta de lo que significará para un producto; dicho esto, esencialmente estás jugando un juego de información. Y como tal, cualquier ventaja que pueda darse a sí mismo es valiosa. Ser capaz de ver las tendencias que se desarrollan en tiempo real puede ayudarlo a desarrollarse de manera ágil y abordar las deficiencias a medida que surgen orgánicamente, mientras predice más fallas en el futuro.

2: anticipar el éxito

Hablando de "esperar lo inesperado", nunca se sabe realmente qué tan exitoso será en realidad. Esto tampoco es una simple consideración del tráfico: el tráfico puede ser alto incluso si usted es la segunda o tercera opción más popular.

El hecho es que un servicio podría fácilmente ser el número uno en cuestión de días, independientemente de cuáles sean las expectativas. Las instancias del "Reddit Hug of Death", que anteriormente se llamaba "Slashdot Effect", pueden inundar instantáneamente los sitios con cantidades dramáticas de tráfico, provocando que se bloqueen y se quemen. Es este "colapso y quemado" lo que puede acabar prematuramente con el argumento de costo-beneficio de un servicio y puede causar directamente la pérdida de retención.

En pocas palabras, un proveedor no puede saber cuánto tráfico puede esperar y, por lo tanto, al planificar en términos de escalabilidad, los proveedores deben planificar el caso más extremo posible dentro de sus posibilidades para permitir el manejo de estos extremos. Otra forma de enmarcar esto sería anticipar el éxito .

Solicitud

Un proveedor de API que no se construye correctamente podría retrasar drásticamente el crecimiento potencial. Asegurarse de que una API tenga la capacidad adecuada para enrutar el tráfico es una cosa, pero construir la arquitectura subyacente hasta tal punto que el éxito sea auto-restringido es otra cosa completamente distinta.

¿Cómo podemos evitar que esto sea un problema? En primer lugar, crear soporte para formatos de datos alternativos y adoptar implementaciones de lenguaje adicionales es increíblemente útil. No todo el mundo va a un fan de JSON, y no todo el mundo va a querer usar Ruby. Facilitar las implementaciones en lenguajes comunes y esotéricos abre su sistema a un mayor desarrollo e iteración para adaptarse a una industria en constante evolución.

3: Non-Extensible es un Unitasker

La gestión del tráfico y la mentalidad escalable no sirven de nada si la aplicación en sí no es extensible . Si bien la extensibilidad es de hecho su propio concepto, con sus propias consideraciones e implicaciones, si un servicio es extensible o no, puede tener un impacto directo sobre si es escalable o no.

Si bien es una buena práctica desarrollar con escalabilidad desde el principio, no hay forma de que un proveedor pueda conocer literalmente todos los usos y aplicaciones futuros posibles de su servicio.

Solicitud

Afortunadamente, los desarrolladores no necesitan ser clarividentes. Cuando un sistema se diseña adecuadamente teniendo en cuenta la escalabilidad, las funciones deben estar interrelacionadas tanto como interconectadas e interconectadas. Eso suena como un montón de palabras de moda, pero podemos ver este tipo exacto de solución en algo como GraphQL .

En GraphQL, obtiene previsibilidad al permitir a los usuarios definir lo que quieren y obtener exactamente eso. Si bien eso es útil, es solo la punta del iceberg en términos de extensibilidad. Debido a que GraphQL se vincula con la estructura subyacente de la API y sus recursos, se pueden llamar a muchos recursos de diversas formas con una sola llamada. Lo que esto significa es que un sistema como GraphQL, en comparación con una API tradicional, es más capaz de manejar una variedad de solicitudes que el desarrollador nunca pudo haber anticipado.

Adoptar la extensibilidad agrega valor a su servicio. Si bien muchos servicios web de nicho derivan su poder de la especialización, hacer una aplicación verdaderamente extensible, con el beneficio adicional de ser escalable para arrancar, es sumamente valioso y otorga un poder de permanencia increíble.

4: La eficiencia es el rey

No siempre puede disminuir la complejidad del problema; su tráfico siempre será su tráfico y los casos de uso seguirán siendo los mismos. Sin embargo, lo que puede hacer es simplificar la arquitectura de su API y así simplificar la solución resultante aplicada al problema. Al aumentar la eficiencia , puede reducir drásticamente los recursos reales que necesita una aplicación.

El problema con la escalabilidad es que, en la concepción clásica, un aumento en el poder requiere un aumento en la metodología. En el mundo físico, para transportar más personas, se necesitan más autobuses, más taxis, etc. En Internet, para transportar más datos y hacer más cálculos, se necesitan protocolos más avanzados .

Solicitud

Un gran ejemplo de esto es el rechazo de las encuestas a favor de algo como REST Hooks . Según los desarrolladores de REST Hooks, Zapier, "En promedio, el 98,5% de las encuestas se desperdician". Todo este sondeo es simplemente potencia de procesamiento desperdiciada y puede contribuir drásticamente a aumentar la sobrecarga de la API, limitando así el procesamiento disponible para la funcionalidad real de su API.

¿Por qué es importante la escalabilidad?

Por último, es importante contextualizar exactamente por qué es importante la escalabilidad. Suena bien en forma de analogía, pero ¿es realmente un problema lo suficientemente importante como para exigir las mejores prácticas? Bueno, considere estos datos proporcionados por HighScalability.com :

  • Netflix tiene 100 millones de suscriptores;
  • El 25% de los ciudadanos estadounidenses no se suscribirá al cable tradicional, favoreciendo las soluciones de transmisión;
  • El trabajo más grande de Google Computer Engine utilizó 220.000 núcleos de alto rendimiento;
  • Sling TV tiene 1,3 millones de suscriptores; y
  • Hay 10 5 centros de datos en todo el mundo necesarios para la computación en nube.

¿Por qué son importantes estos datos? Todos estos puntos de datos provienen de servicios que comenzaron siendo pequeños y crecieron exponencialmente . Netflix comenzó como un servicio relativamente pequeño y creció extremadamente rápido. Google comenzó esencialmente como un pequeño experimento y se convirtió en una de las organizaciones más grandes del mundo. Sling TV tenía una pequeña base de suscriptores y ha crecido de manera considerable y constante.

Que la solución más pequeña y de un solo propósito no permanecerá así para siempre. Diseñar para el tráfico y la función que maneja actualmente está bien, pero limita intrínsecamente el crecimiento futuro de la plataforma.

Conclusión: la escalabilidad es fundamental para el crecimiento de la plataforma API

Con suerte, estos mantras han ayudado a establecer un espíritu sólido a largo plazo para el diseño de API escalable. Debería ser evidente que la escalabilidad es casi un requisito para las aplicaciones modernas, especialmente en el clima actual, donde una aplicación puede pasar de un uso relativamente desconocido a un uso intensivo en cuestión de horas. No cumplir con los estándares modernos significa la muerte, e incluso los planes mejor diseñados son esencialmente inútiles si el sistema subyacente en sí no es escalable.

 

Publicar un comentario

0 Comentarios