Header Ads Widget

Ticker

6/recent/ticker-posts

6 consejos para convertirse en un jardinero experto en microservicios


El arte de proporcionar una API es extremadamente interesante, en gran parte debido a la dicotomía de requisitos opuestos. Por un lado, una API debe ser innovadora, rápida de cambiar y en constante evolución. Por otro lado, los consumidores exigen estabilidad y, con ella, la seguridad que viene con las soluciones probadas.

La batalla constante entre lo antiguo y lo nuevo , lo centralizado y lo distribuido, ha dado lugar a una gama única de soluciones y enfoques para resolver el dilema. Una de esas soluciones es el concepto de jardinería de microservicios , la idea de ser un " paisajista " para una plataforma o conjunto de microservicios de primera API. Los jardineros de microservicios deben utilizar técnicas innovadoras que adopten una arquitectura distribuida, evitando el monolito kafkiano a toda costa.

En este artículo, analizaremos lo que significa ser un "jardinero de microservicios" y presentaremos seis formas en que los proveedores de API pueden sobresalir como maestros.

Esta publicación se inspiró en una charla que dio Eric Wilde en la Cumbre de la Plataforma 2016. Mira aquí:

¿Qué es una API Gardner?

“Las empresas se están reestructurando cada vez más en algo que tiene límites organizacionales que tienen alineaciones técnicas ... lo que estás haciendo también está alineado con cómo lo estás haciendo. Entonces le resultará más fácil reestructurarse y reconstruirse cuando sea necesario ".

Imagina un jardín, una variedad de flores, cada una con sus propias necesidades y propósitos. Este es el panorama de microservicios de API . Así como cada flor o verdura necesita una fertilización específica y un cuidado especializado, el papel del proveedor es brindar una atención atenta a los consumidores de microservicios API como un jardinero API .

Como administrador del paisaje, es su deber controlar y aumentar el medio ambiente para permitir el mayor crecimiento y prosperidad. Dentro de un panorama de API, no brindar soporte a los usuarios donde se encuentran puede ahogar su sistema y cualquier base de usuarios potencial que aún no haya desarrollado. No hacerlo no solo daña el medio ambiente, sino que posiblemente lo destruye.

Estos problemas surgen de un cambio fundamental en cómo se producen y administran las API. Mientras que las API solían ser monolíticas y estar encadenadas a sistemas más grandes, ahora estamos en una era de microservicios , todos diseñados para hacer cosas específicas en concierto con otras soluciones, lo que fuerza una contenedorización y descentralización del modelo API.

6 formas de convertirse en un jardinero experto en microservicios

Ahora que sabemos qué es la jardinería de microservicios, veamos algunas técnicas que podemos aplicar para dominar este arte.

1) Utilice TI bimodal para evitar el estancamiento

“Imagina que tienes el castillo, que es tu sistema heredado. Ahora tienes estas cosas nuevas en camino donde la gente dice 'oh, deberíamos hacer microservicios, y será rápido, y podemos hacer cosas interesantes'. Están muy entusiasmados con lo que están haciendo, pero también necesitan orientación ".

La TI bimodal es el concepto de tratar con estilos de trabajo dispares que, sin embargo, funcionan perfectamente bien separados entre sí. "Bimodal" significa dos modos y, en este caso, el término coincide con la función: uno se centra directamente en la previsibilidad y el otro en la exploración .

El tipo exploratorio se centra en soluciones únicas e innovadoras que resultan en un requisito para explorar en lugar de depender de una funcionalidad constante conocida. La segunda vía de desarrollo es la inversa, una base de código confiable que es conocida, probada y bien documentada, lo que da como resultado resultados predecibles.

Si bien un proveedor de API podría simplemente dirigir su API para que solo admita uno de estos tipos de contenido y los usuarios resultantes mediante el efecto de evitar soluciones innovadoras y no probadas, los desarrolladores eliminarían una gran parte de su poder potencial y base de usuarios al hacerlo. Los enfoques de TI bimodal están diseñados para admitir conceptos y enfoques. Al combinar la evolución y la documentación predecibles del producto con las herramientas de exploración e innovación, los desarrolladores pueden aprovechar "lo mejor de ambos mundos".

Lea también: Desacople la identidad de usuario del diseño de API para crear microservicios escalables

2) Evita el monolito kafkiano

Erik proporciona un muy buen ejemplo de lo que resulta un monolito centralizado con el ejemplo de El castillo , una novela de Franz Kafka. A lo largo de los acontecimientos de El castillo , el protagonista, conocido sólo como K., sufre las tribulaciones de la burocracia de un gobierno que erróneamente lo llamó a su aldea por un trabajo que no existía.

Para Wilde, la arquitectura monolítica es similar a la burocracia de pesadilla de El castillo de Franz Kafka.

Redirigido de un contacto a otro, ignorado por los superiores con la simple instrucción de hablar con sus subordinados, y sin dar ninguna explicación de ninguna acción de los funcionarios, K. expone las tonterías burocráticas de la aldea que rodea el castillo, mucho a los aldeanos. disgusto.

Las API mal diseñadas e implementadas (e incluso las bien diseñadas e implementadas) a veces dan como resultado este tipo de comportamiento. El usuario, al intentar utilizar la API para cualquier función que considere, se pierde en la estructura de subordinación y redirección. La metodología de diseño de API utilizada puede aumentar de alguna manera esto, pero darle a las API demasiada estructura podría terminar en un resultado burocrático.

No tiene por qué ser así, por supuesto. Las API necesitan estructura, pero tan importante como la estructura es la necesidad de orientación . Diseñar una API no solo para hacer el trabajo, sino para hacerlo de una manera comprensible al tiempo que permite la innovación y la explorabilidad es un inquilino clave de la TI bimodal. Básicamente, te estás uniendo a lo viejo, es decir, lo burocrático, con lo nuevo.

3) Diseño de una manera que promueva una mayor iteración

En primer lugar, tenga en cuenta que todas estas cuestiones, incluso las de El castillo , se derivan de los cimientos principales sobre los que se construye el sistema. Ningún enfoque de especificación , documentación y diseño de API es perfecto y, como tal, evitar la dependencia de una única solución monolítica hará mucho para resolver esto.

Al desarrollar una API, tenga en cuenta no solo la funcionalidad prevista, sino también la capacidad de ampliar esa funcionalidad. Si una API está diseñada para ajustarse perfectamente solo a los requisitos actuales, será una API perfecta, pero solo por un momento.

Este es un concepto mucho más de "nivel superior", pero es uno que debe ser adoptado como un mantra para cualquier proveedor de API. Al considerar una API, no piense en lo que el usuario quiere hoy, o incluso en lo que querrá el usuario dentro de un año; la prueba de futuro es difícil porque la tecnología fluctúa tan rápidamente. Por el contrario, Wilde recomienda que la mejor solución no es codificar las funciones que espera necesitar en el futuro, sino permitir la fácil incorporación de esas funciones a una base de código extensible. Permitir una mayor funcionalidad a través de clases extensibles y ganchos para combinar funciones crea soluciones poderosas impulsadas por la longevidad.

4) Cosechar conceptos e incorporar

La recolección e introducción de nuevos conceptos debería ser fácil. En El castillo , K. no solo se confunde, sino que también encuentra personas que se resisten activamente a sus intentos de resolver la confusión. Tu API no debería hacer esto.

Parte de una solución es simplemente permitir que su API sea explorable . No bloquee todo a través de la ofuscación y capas de neblina; explique cómo una API hace lo que hace, cómo se puede extender y cómo llamar a esta funcionalidad.

Esencialmente, debería ser fácil identificar lo que hace una API y usarla para nuevos propósitos; no proporcionar un sistema para hacer esto mata cualquier innovación. Esto se ha visto una y otra vez, y es una de las principales razones por las que el código abierto ha tenido tanto éxito como lo ha sido. Un ecosistema bloqueado funciona perfectamente, pero solo si todo se mantiene interno.

5) Distribuya las semillas: adopte el acuerdo de verdaderos microservicios

La mejor manera de convertirse en un jardinero experto en microservicios es alejarse de la centralización. Brinde a los equipos de desarrolladores más autonomía en la forma en que se desarrollan e implementan las soluciones, y permite un mayor descubrimiento de servicios por parte del usuario. Esencialmente, aléjese de un enfoque de API centralizado y más hacia una verdadera disposición de microservicios .

Los desarrolladores tienden a pensar en sí mismos como la "autoridad central". El desarrollador ha creado el código, lo ha restringido, lo ha documentado y, mediante este proceso, tiene el control total. Si bien esto está bien para las API de un solo uso o los equipos pequeños, no es así como debería funcionar una plataforma de API interactiva. Cuando un proveedor funciona de esta manera, está siendo despótico, y con el despotismo viene la ineficiencia y la burocracia.

En su lugar, aborde el desarrollo de API como un líder democrático benevolente . Permita un uso más personal y haga todo lo posible para apoyar el crecimiento y la comprensión. Si un jardinero corta demasiado cerca de la raíz, puede matar una flor; si un proveedor no brinda ninguna cantidad de soporte para nada que no sea su caso de usuario específico, hará lo mismo con la API.

Aprenda a manejar la identidad dentro de los microservicios

6) Pode la superficie de servicio

Cuando se trata de eso, lo que realmente le importa al consumidor de microservicios es la superficie del servicio. La superficie es única para cada oferta, pero puede constar de distintos grados de portales públicos para desarrolladores, metadatos de API, documentación u otros resúmenes funcionales y metodologías de integración.

Si bien es tentador seguir el consejo aquí y revelar la totalidad de su API, eso es demasiado en la dirección equivocada. Considere la simplicidad de ofrecer una superficie de servicio y hacer conceptos bien definidos que son fundamentalmente superficiales en su funcionalidad. Al hacer esto, está creando una solución extensible al tiempo que mitiga el daño potencial de la innovación por el bien de la innovación.

Fomentar el crecimiento del ecosistema API

"En lugar de tener un proceso de arriba hacia abajo para diseñar, documentar y describir las API, utilice un enfoque más parecido al de un ecosistema ... Trate de construir cosas de tal manera que cree las condiciones bajo las cuales sucederán las cosas buenas".

A medida que los proveedores y desarrolladores crean ecosistemas de API, necesitan un cambio radical en el concepto. Para hacerlo, los proveedores de API deben evitar la centralización en favor de la innovación y los nuevos desarrollos.

Lo mejor que puede esperar un desarrollador es esto: crear un sistema en el que la API sea comprensible y extensible y, a partir de ahí, cree las condiciones para el éxito. Incluso si ese éxito no se produce de inmediato, la preparación debería mitigar esos posibles problemas y, al mismo tiempo, magnificar el potencial de éxito.

 

Publicar un comentario

0 Comentarios