Header Ads Widget

Ticker

6/recent/ticker-posts

3 estrategias para desarrollar microservicios

 

3 estrategias para desarrollar microservicios-01

En nuestro primer Enfrentamiento de microservicios , abordamos las opciones de diseño arquitectónico detrás de las API más populares: cubrimos las fortalezas y debilidades inherentes a cada una, y discutimos exactamente por qué es importante tomar esa decisión. En este artículo, la segunda parte de la serie Microservice Showdown, abordaremos un tema más complejo: el enfoque de desarrollo general . Describiremos los efectos de estas opciones y exploraremos ejemplos del mundo real de su implementación efectiva.

¿Qué enfoque de desarrollo es el mejor?

¿Por qué importa cómo se desarrolla una API? La arquitectura es claramente importante; después de todo, cuando se construye un rascacielos, el elemento más importante es la base, la base que soportará todo ese peso para las generaciones venideras. Un buen rascacielos tiene que soportar los vientos más fuertes, las lluvias más fuertes y los movimientos más fuertes de la Tierra.

Cualquier buen trabajador de la construcción le dirá que la forma en que construye es tan importante como lo que construye . Tomemos, por ejemplo, el vertido de hormigón. Cuando se vierte una losa de hormigón, entran en juego una gran cantidad de variables: el calor del exterior, la carga de peso esperada, la dureza del agua y el tamaño de las barras de refuerzo estratificadas influyen en la composición de la base . Cualquier debilidad inherente al proceso hará que la base sea mucho más débil de lo que es seguro. Asimismo, la velocidad a la que se vierte, endurece y fragua el hormigón es tan importante como su composición química y estructural.

Lo que es cierto en la construcción es igualmente cierto en el desarrollo de API. Si bien la naturaleza del desarrollo de software es importante, también lo es el ritmo , la naturaleza y la velocidad del desarrollo. Hay muchas escuelas de pensamiento sobre qué tipo de programa de desarrollo es más eficaz, pero se pueden cubrir en general en tres clasificaciones generales:

  • Estrategia ajustada
  • Desarrollo detallado
  • TI de dos velocidades

Estrategia ajustada = una cosa hecha de manera experta

Una estrategia ajustada es aquella que limita los recursos y centra el desarrollo en un objetivo actual bien documentado, simple y alcanzable. Cuando Lego se propuso crear su API, tenían un plan muy específico y detallado . Esta estrategia incluía necesariamente un conjunto de características específicas y un cronograma para el desarrollo que limitaría las extensiones más allá del formato original descrito.

Si bien algunos verían esto como algo negativo, un modelo que carece de cualquier desarrollo fuera de las limitaciones estrictas, de muchas maneras, una metodología lean puede ser extremadamente positiva. La API de Lego ha demostrado ser lo suficientemente potente como para impulsar sistemas creativos e innovadores. Tome la API de Brickset, por ejemplo, una API que se vincula con la funcionalidad oficial de la API de Lego para recopilar y presentar datos sobre combinaciones de bloques, disponibilidad y usos. O mire la API de Cubiculus , un sistema que crea números de conjuntos de bloques, números de modelo, instrucciones de conjuntos y más.

¿Cómo puede una API tan limitada resultar más flexible y poderosa que una que es deliberadamente diversa? Al limitar el alcance de su API y prevenir el siempre temido síndrome de creep de características , no solo ahorra tiempo y recursos, sino que concentra sus esfuerzos en probar y probar su API en cada iteración. Una máquina simple funciona mejor: menos piezas móviles significa menos posibilidades de fallas y rondas de prueba más rápidas.

La pregunta principal es esta: ¿cuáles son los resultados realistas que se pueden esperar? Volviendo a nuestra analogía de la construcción, al crear una base debe considerar las cargas máximas teóricas de futuros ocupantes y elementos como mesas, sillas, ventanas, etc. Los arquitectos deben diseñar para el futuro: ¿esperamos que la ocupación del edificio se duplique en cinco ¿años? ¿Esperamos que las necesidades de ocupación se tripliquen antes de que la necesidad de construir un nuevo edificio sea demasiado grande? Si lo hacemos, entonces la base debe reforzarse para permitir el desarrollo futuro. Sin embargo, si no anticipamos el crecimiento, expandir la base es un desperdicio de recursos y espacio.

Lo mismo ocurre con el desarrollo de API. Al desarrollar una API, ya sea privada, de socio o pública , debemos considerar las necesidades futuras de lo que una API podría convertirse de manera realista. Si su API está destinada a hacer una cosa, y hacerlo extremadamente bien, entonces desarrollar una API ómnibus con funcionalidad inflada es un desperdicio de recursos.

Singular es el concepto central de una estrategia ajustada. Al desarrollar una metodología de este tipo, los recursos se concentran y las características extrañas se dejan de lado en beneficio de un sistema singular. Para la API de Lego, esto resultó en una API única y unificada que manejaba una cosa (características y usos de los ladrillos) y manejaba esa cosa extremadamente bien . Considere cuáles son realmente los requisitos fundamentales de su API y diseñe específicamente para ellos .

Relacionado: ¿Qué significa 'ágil' para los desarrolladores de API?

Desarrollo detallado = mucho sistema, mucho esfuerzo

¿Qué pasa si sabemos que nuestra base será superada rápidamente, superada rápidamente? El análisis de resultados realistas puede iniciar una consideración seria de los requisitos futuros, lo que resulta en una necesidad demostrable de expansión a corto plazo.

El simple hecho es que en el mundo de la construcción, siempre es más caro agregar algo después del hecho que construir desde el principio. Se deben hacer nuevas consideraciones para plomería, marcos, soportes de cimientos y más. Lo mismo ocurre con el desarrollo de API. Al agregar funciones a una API, deben tenerse en cuenta para garantizar que las llamadas no se superpongan, que las funcionalidades funcionen en conjunto y que la documentación esté completa.

El desarrollo detallado , entonces, es el polo opuesto de la estrategia ajustada. Mientras que Lean Strategy se enfoca en una característica singular o un conjunto de características, simplificando el enfoque para el beneficio del producto más grande, Verbose Development se enfoca en un grupo de conjuntos de características para una amplia flexibilidad y utilidad .

Un gran ejemplo de esto es el conjunto de API de Google , que en realidad es una única API dividida entre varios servicios de API diferentes para mayor claridad y facilidad de uso. Funcionalmente, estas API se vinculan entre sí como un solo servicio; Google Maps se vincula con las API de GPS, que se vinculan con las API de búsqueda para ubicaciones y servicios comerciales, etc. Esto representa un sistema de API extremadamente detallado: el poder de la colección de API de Google es tan extensible como potente y se extiende a varios funcionalidades.

Sin embargo, tenga en cuenta que Verbose Development no es necesariamente el desarrollo de una única API con capacidades monolíticas. Volviendo a la analogía de la construcción, podemos ver que la construcción detallada no crea necesariamente dos edificios separados y distintos desde el principio. Lo que en realidad estamos discutiendo es la expansión de los cimientos: reforzar el concreto, agregar más conexiones eléctricas y de plomería, etc. La construcción de dos edificios no es rentable y podría terminar arrastrando toda la producción. Lo mismo ocurre con Verbose Development cuando se trata de API: la metodología no aboga por la creación de una API multipropósito monolítica, sino más bien aboga por la creación de una API que evolucione.

La API de Lego fue diseñada con necesidades y aplicaciones muy específicas, y para Lego, eso estuvo bien. Sin embargo, para una empresa como Google, ese no es un gran punto de venta: Google quiere expandirse, crear, evolucionar y no puede hacerlo con un sistema simple.

La respuesta entonces es desarrollar lo que necesita ahora mientras considera lo que podría necesitar en el futuro . En un maravilloso documento sobre la evolución de las API desarrolladas en Java , el arquitecto de IBM Eclipse Jim des Rivières defiende la evolución manteniendo (aproximadamente) varias reglas básicas:

  • Nunca permita que el código invalide el código anterior utilizado por los clientes de la API.
  • Asegúrese de que las nuevas bibliotecas y sistemas sean compatibles con los sistemas que ya están en uso.
  • Suponga que toda la funcionalidad de la API es importante para alguien.

Al tener en cuenta estas facetas, podemos comenzar a abordar el desarrollo de una manera detallada, es decir, desarrollándonos para lo que pensamos que vendrá mientras mantenemos las necesidades de hoy.

Esto, por supuesto, tiene un costo . Mientras que Lean Strategy es simple con ciclos de desarrollo rápidos, Verbose Development es solo eso: detallado. Las pruebas se realizan en todos los niveles con cada característica nueva para garantizar la compatibilidad cruzada y con versiones anteriores. Esto significa tiempo , y mucho.

TI de dos velocidades = dos carriles para dos propósitos

El mundo de la construcción es una aplicación mitad teórica y mitad física: los diseñadores se enfrentan a un conjunto siempre variable de condiciones del sitio, deseos de los clientes y limitaciones de materiales a lo largo del curso del desarrollo. Para combatir esto, los arquitectos a menudo recurren a simulaciones para probar diseños estructurales e identificar variables desconocidas a partir de planos en papel.

Esto es exactamente de lo que se trata la tecnología de dos velocidades . Una tecnología probada puede ser aplicable a un proyecto, pero mientras los desarrolladores se apeguen a un solo enfoque, no se avanzará hacia la creación de sistemas innovadores. En el enfoque de TI de dos velocidades, la necesidad de un resultado estable se equilibra con la necesidad de experimentación; se reserva una vía de desarrollo para tecnologías estables y se proporciona una segunda vía rápida para el desarrollo, implementación y prueba de materiales experimentales.

Este tipo de desarrollo tiene una gran fortaleza en el hecho de que estos dos carriles se complementan . Una vía rápida para conjuntos de características experimentales puede ayudar a impulsar su producto a la vanguardia del espacio de TI, todo mientras permite un seguimiento de tecnologías probadas para crear un producto utilizable. Este es el núcleo de la TI de dos velocidades : una vía única para un desarrollo rápido, con una vía prolongada para proyectos complejos .

Los sistemas y aplicaciones empresariales cruciales se verifican necesariamente de forma rutinaria y se “someten a prueba” de Verbose Development. Estos sistemas son el verdadero elemento vital de su empresa. ¿Por qué no deberían supervisarse cuidadosamente a largo plazo? Estos sistemas son tan importantes que el tema de asegurarlos es un tema completamente separado e igualmente importante por derecho propio .

Sin embargo, hay una advertencia: el manejo de proyectos experimentales a menudo se ve obstaculizado directamente por el estilo de desarrollo detallado. Si se tarda uno o tres meses completos en implementar un código teórico o una nueva metodología, puede ser obsoleto o incluso reemplazado en el momento de su implementación. Aquí es donde entran en juego los "dos" en "TI de dos velocidades": mientras que los sistemas centrales se desarrollan de una manera altamente controlada y segura, se proporciona un canal secundario para que prospere el desarrollo de sistemas teóricos o experimentales .

Esto nos brinda lo mejor de ambos mundos: un sistema seguro de desarrollo detallado junto con una caja de resonancia experimental, lo que permite una API probada a largo plazo y la presencia de varias funcionalidades que aún no se han probado. Grandes ejemplos son las derivaciones de la API de desarrollo para Sony XperiaSi bien existe una API estable y segura para la implementación de servicios y sistemas en el teléfono insignia, hay una API de canal separada que se vincula con la funcionalidad principal con el único propósito de usar la barra de iluminación en la parte inferior del teléfono. Si bien esto parece una característica pequeña, el uso de la barra de iluminación puede proporcionar aplicaciones de "linterna", notificaciones de mensajes, alertas de tráfico y mucho más. Sabiendo muy bien que proporcionar acceso a todas las funciones del teléfono podría ser peligroso, Sony implementó un canal donde la experimentación puede florecer.

Asimismo, podemos ver un ejemplo más amplio con las APIs chrome.experimental. * , Que permiten el etiquetado y desarrollo de funciones experimentales para el navegador Chrome. Debido a que la ejecución de código de forma nativa en el navegador Chrome puede ser extremadamente peligrosa, creando enormes problemas de seguridad en la API general., la segregación de la funcionalidad experimental en "sub-API" contribuye en gran medida a permitir la innovación y la experimentación mientras se mantiene la funcionalidad de misión crítica. Este tipo de segregación de experimentación es una gran herramienta tanto para las grandes empresas como para las nuevas empresas: al garantizar que la funcionalidad de su sistema principal sea segura y efectiva al tiempo que permite el desarrollo de nuevas funciones, cualquier ciclo de desarrollo del proyecto puede acelerarse, lo que da como resultado un resultado del proyecto mayor que la suma de sus partes.

Más sobre innovación de API: proyectos y campañas creativos fusionados con API

La forma en que construye es tan importante como lo que construye

La industria de las API se está volviendo más compleja y orientada a la especialidad día a día. Elegir cómo construir su API es tan importante como averiguar su mentalidad y propósito general. Quizás sea más importante cuando el costo o el tiempo es un elemento que debe controlarse, como suele suceder con las startups y las empresas más pequeñas. En consecuencia, decidir entre uno de los tres enfoques detallados anteriormente es extremadamente importante y podría significar toda la diferencia del mundo. Elegir sabiamente.

Publicar un comentario

0 Comentarios