Header Ads Widget

Ticker

6/recent/ticker-posts

El mandato de la API de Bezos: Manifiesto de Amazon para la externalización

 


En 2002, según la leyenda tecnológica, el fundador de Amazon, Jeff Bezos, emitió un mandato. Este mandato serviría para formar la columna vertebral de Amazon en el espacio web moderno, informando tanto el paradigma de desarrollo de API en la mentalidad corporativa como un enfoque general mejorado para externalizar las funciones de API.

A continuación, hablaremos sobre el mandato y discutiremos por qué se ha vuelto tan legendario en el espacio API. Nos sumergiremos en los detalles de cada punto y veremos cómo el mandato formó gran parte del pensamiento moderno en torno a las API y los microservicios.

El mandato

El mandato en cuestión fue emitido en 2002 a Amazon por el fundador Jeff Bezos. Por muchas razones, se ha convertido en algo legendario en el espacio de API / microservicios, ya que formó la base de gran parte del paradigma moderno de diseño de API dentro de la visión corporativa. Por leyenda, el mandato es el siguiente:

1. Todos los equipos expondrán en adelante sus datos y funcionalidad a través de interfaces de servicio.
2. Los equipos deben comunicarse entre sí a través de estas interfaces.
3. No se permitirá ninguna otra forma de comunicación entre procesos: ningún enlace directo, ninguna lectura directa del almacén de datos de otro equipo, ningún modelo de memoria compartida, ninguna puerta trasera de ningún tipo. La única comunicación permitida es a través de llamadas de interfaz de servicio a través de la red.
4. No importa qué tecnología utilicen. HTTP, Corba, Pubsub, protocolos personalizados, no importa.
5. Todas las interfaces de servicio, sin excepción, deben diseñarse desde cero para ser externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores del mundo exterior. Sin excepciones.
6. Cualquiera que no haga esto será despedido.
7. Gracias; ¡que tengas un buen día!

Este mandato ayudó a alentar gran parte del pensamiento de Amazon sobre AWS, la infraestructura externalizada y la funcionalidad de empresa a empresa. Profundicemos en cada uno de estos puntos (con la excepción del 6 y el 7, que son más descarados que los de API) y veamos por qué pueden ser importantes, en términos generales.

Antes de hacerlo, es importante mencionar que este memo a menudo no se atribuye: la fuente original parece haberse perdido en el tiempo debido al cierre de Google+ (para una referencia temprana, consulte esta publicación de API Evangelist ). No obstante, las lecciones impartidas son esenciales y, como tal, las discutiremos con el supuesto de que el memo existió en la forma comúnmente compartida.

Exposición de datos y funcionalidad

“1. De ahora en adelante, todos los equipos expondrán sus datos y funcionalidad a través de interfaces de servicio ".

El acuerdo fundamental para un proveedor de API es proporcionar acceso a una función a través de una interfaz. Entonces, no es de extrañar que la primera parte de este mandato sea una demanda para proporcionar esta funcionalidad a través de una interfaz de servicio. Las interfaces permiten la transmutabilidad, la interacción bidireccional y el aprovechamiento dentro de otros sistemas, sin mencionar una mayor capacidad de descubrimiento. Si bien esto parece una obviedad para los desarrolladores de API, hubo un momento en el que esto no era la norma.

La funcionalidad empresarial es una bestia interesante. Por un lado, proporcionar funcionalidad empresarial a través de una interfaz parece una victoria bastante clara. Los usuarios pueden aprovechar la interfaz y sus funciones internas para hacer más con menos agarre. Sin embargo, en un momento, la cultura empresarial veía este tipo de exposición como "regalar la granja". ¿Por qué expondría una función empresarial crítica que genera ingresos en forma pública? ¿No es mejor que los agentes manejen estos datos caso por caso para extraer el máximo valor?

La realidad es que, en la mayoría de los casos, existe un argumento comercial mucho más sólido para proporcionar estos datos en un formato de autoservicio medido. Para muchos, la facilidad de uso es casi más importante que la función real. Cuando este uso se combina con una API maravillosamente poderosa, ha creado una máquina generadora de ingresos.

Para una empresa como Amazon, el concepto de proporcionar sus datos y funcionalidad a través de interfaces de servicio tanto internas como externas no solo es un importante generador de ingresos para los usuarios externos; también es un "destructor de silos". Al forzar el uso de interfaces, casi está imponiendo la colaboración.

Esta sencilla práctica abre un vasto mundo de posibilidades externas e internas. Es la razón por la que Amazon pudo escalar de manera tan dramática en un corto período de tiempo.

Hacer cumplir la comunicación a través de interfaces y estandarizar las interacciones de datos

“2. Los equipos deben comunicarse entre sí a través de estas interfaces ".

“3. No se permitirá ninguna otra forma de comunicación entre procesos: ningún enlace directo, ninguna lectura directa del almacén de datos de otro equipo, ningún modelo de memoria compartida, ninguna puerta trasera. La única comunicación permitida es a través de llamadas de interfaz de servicio a través de la red ".

Muchas cosas definen la interoperabilidad y el aprovechamiento exitosos, pero quizás la principal de ellas sea la coherencia. Cuando algo existe en el mismo lugar independientemente de su forma, función o propósito, se puede iterar y usar de manera efectiva. En el mundo de las API corporativas, donde el Mandato de Bezos tiene quizás el mayor reclamo de legitimidad, esto es más claro.

Por ejemplo, supongamos que tenemos una corporación masiva formada por múltiples divisiones, cada una de las cuales debe solicitar los datos de las demás para funcionar de manera efectiva. Se ha creado una nueva división para proporcionar datos personalizados sobre los usuarios registrados para llegar a los antiguos clientes que probablemente regresen a la organización después de irse a la competencia. Esta es una función crítica para el negocio que puede ser impulsada por los datos disponibles y se estima que recuperará millones de dólares al año en ingresos para la organización. ¿Cómo se ve el desarrollo de esta función a través de dos enfoques distintos?

En un enfoque no estandarizado, encontramos una complejidad infinita. En primer lugar, debemos averiguar dónde ha decidido el equipo de experiencia del usuario almacenar los comentarios de los usuarios. Esta retroalimentación puede informar sustancialmente a la división sobre si es probable que un cliente regrese o no. Una vez que se descubre que el equipo proporciona estos datos a través de una base de datos compartida, la nueva división asume que el resto de los datos del usuario probablemente también se almacenan de esta manera. Sin embargo, se descubre que el espacio de memoria compartida solo almacena los comentarios de los usuarios y que los datos reales del usuario se comparten a través de un sistema interno y propietario con una API abierta que carece de mecanismo de respuesta, documentación o puntos finales bien definidos. Una vez que el equipo descubre la API, comienzan a crear su interfaz para unir estos datos. Pero encuentran dificultades para localizar la información de contacto.

En un enfoque estandarizado, nada de esto sería un problema. Cada aspecto de los datos deseados existiría en una API bien definida, bien documentada y fácilmente aprovechable. Además, cada vez que se generan datos de usuario, estos datos se almacenarían en un esquema conocido con formatos de respuesta que les permiten a los nuevos desarrolladores saber si una llamada fue exitosa o no.

Con estas dos posibilidades, podemos ver claramente que una opción da como resultado un desarrollo dramáticamente más simple y, por lo tanto, probablemente más barato, más efectivo y más eficiente. La otra posibilidad solo da como resultado una complejidad adicional y obliga a cualquier solución desarrollada a llevar esta complejidad al futuro.

Agnosticismo tecnológico

“4. No importa qué tecnología utilicen. HTTP, Corba, Pubsub, protocolos personalizados, no importa ".

El agnosticismo tecnológico es un concepto simple: se desarrolla para la forma y la función, no para la tecnología en sí. La tecnología API va y viene. El diseño de una API que dependa de la tecnología de jure tiene muchas desventajas potenciales.

La primera de estas desventajas es que la tecnología del mañana puede ser fundamentalmente incompatible con la tecnología actual. Sin tener ganchos adicionales, implementaciones de lenguaje / marco o opciones multiplataforma, su API pasará a la obsolescencia como lo hace su tecnología actual. Las API reflejan funciones comerciales y, como tales, deben evolucionar con los requisitos del negocio existente y los sistemas técnicos que los habilitan. No tenerlo en cuenta significa que las funciones de su negocio que se reflejan en la API ya no serán aprovechables, lo que perjudicará al negocio principal a medida que su API se vuelva obsoleta.

Además, no todas las organizaciones van a utilizar la misma pila de tecnología. Cuando se elige una única solución ómnibus y no se proporciona ninguna funcionalidad adicional, la interoperabilidad se ve perjudicada, lo que impide la utilización externa y la conexión de empresa a empresa . Esto puede tener un efecto marcado no solo en el aspecto técnico de su negocio, sino también en el lado de los ingresos directos. Cuando un socio tiene que implementar una pila de código desconocido y un conjunto de tecnologías no aprendidas, elegirá un socio que satisfaga sus necesidades en lugar de absorber este gasto adicional.

Por último, la tecnología no es simplemente una herramienta habilitadora; dependiendo de la implementación, también puede limitar. Las soluciones tecnológicas solo pueden hacer lo que están diseñadas para hacer. Cuando se desarrolla en torno a la tecnología en lugar del propósito, se asegura de que la coherencia del diseño no esté en torno a su función, sino a sus restricciones. Por ejemplo, si su API permite a los usuarios solicitar un conjunto específico de datos en su propia forma definida, pero solo si el paradigma GraphQL forma la solicitud, los clientes pequeños sin almacenamiento en caché local y sin la capacidad de admitir solicitudes complejas pueden sufrir mucho.

La externalización como paradigma

“5. Todas las interfaces de servicio, sin excepción, deben diseñarse desde cero para ser externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores del mundo exterior. Sin excepciones."

Uno de los problemas centrales de cualquier paradigma de desarrollo es identificar a la audiencia principal; dirigirse a la audiencia adecuada con las herramientas adecuadas puede cambiar fundamentalmente tanto la elección del marco de desarrollo como el modelo de participación general. En consecuencia, en el Mandato de Bezos, todas las interfaces de servicio debían enfrentarse a un tipo de usuario externo. Veamos algunas razones por las que esto puede haber sido un requisito.

En primer lugar, el desarrollo para una base de desarrolladores externos permite una mayor extensibilidad. Cuando se diseña una API, toma una forma y función específicas dictadas por las necesidades del desarrollador y las elecciones del grupo de desarrollo. Necesariamente, esto significa que la API está diseñada para un propósito particular. Cuando se requiere transformar y aprovechar una API interna, esto debe hacerse como un proceso (o subproceso) único y discreto. Cada nueva API funcional debe reducirse con sus propias demandas de recursos.

Cuando se crea una API para la interacción externa, esta carga se traslada a los desarrolladores externos que exigen la funcionalidad. Supongamos que alguien quiere usar una API de una manera novedosa. En ese caso, este desarrollo debe estar respaldado por los recursos del solicitante; esto reduce la demanda general de recursos en los grupos de desarrolladores internos.

Además, al mover el enfoque de desarrollo a desarrolladores externos que solicitan la expansión funcional, se logra una mayor precisión de las necesidades establecidas. Si un desarrollador solicita una función pero no tiene el control de la respuesta a esa solicitud, el producto casi siempre será imperfecto. Incluso si la API desarrollada cumple con el 99% de las demandas establecidas, siempre habrá algún elemento, ya sea la interfaz de usuario, la función y la forma, o de otro modo, que no cumpla con las "especificaciones". Esto no es tan cierto cuando el desarrollador solicitante puede desarrollar sus propias solicitudes: el producto estará más cerca de su solicitud y será más adecuado para la función y el propósito.

Conclusiones del mandato de la API de Bezos

Independientemente de si el memorando existió o no en la forma descrita, sí nota algunos valores importantes para el desarrollo y el consumo de API modernas en el espacio corporativo. Las lecciones impartidas son importantes en una amplia gama de situaciones, e incluso para instancias no corporativas, el mandato API de Bezos podría servir para estructurar organizaciones API de manera efectiva.

¿Qué opinas del mandato? ¿Refleja adecuadamente las opiniones tanto corporativas como no corporativas? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios