Header Ads Widget

Ticker

6/recent/ticker-posts

Por qué está bien que su API sea aburrida

 Sin servidor, GraphQL, Go, microservicios… la tecnología disruptiva ofrece grandes beneficios, pero ¿es mejor la tecnología “aburrida” desde un punto de vista pragmático?

Si no está roto, no lo arregles . No es necesario reinventar la rueda . El beso principio (Keep It Simple, Stupid!). Hay muchas expresiones y cosas por el estilo que abogan por abrazar lo probado y probado sobre lo complejo y novedoso, pero a veces el canto de sirena de la tecnología de punta es demasiado para resistir.

En la Cumbre de Plataformas Nordic APIs 2018, Martin Buhr , creador y CEO de Tyk API Management Platform, se puso de pie y mejores prácticas y la tecnología robusta en el espacio de las API, incluso si inicialmente puede parecer obsoleta y aburrida.

Te dejaremos ser el juez de cómo le fue ...

Esta publicación se inspiró en la sesión Tu estrategia de API: por qué lo aburrido es mejor de  Martin Buhr . Míralo completo aquí:

Aburrido es confiable

Martin inició su charla analizando algunas de las razones por las que "aburrido" es a menudo la mejor manera de hacerlo. “Hemos visto muchas mejores prácticas ”, dice. "También hemos visto a mucha gente intentar hacer cosas realmente interesantes ... y algunas cosas realmente malas".

Señala que uno de los problemas de tomar el camino menos transitado, particularmente un camino que es nuevo y parece particularmente emocionante, es el tipo de competencia a la que te enfrenta. Da el ejemplo de la contratación de desarrolladores de Go y de cómo de repente estás compitiendo con empresas como Google, Facebook, etc. por un grupo de talentos muy pequeño. .

Además de poder ofrecer salarios sustanciales , estas empresas cuentan con el respaldo financiero para explorar nuevas tecnologías, tengan o no éxito. Y, si somos honestos, podríamos llenar varias páginas con experimentos de Google y Facebook que no han tenido éxito.

Compare esto con contratar, digamos, un Java o Python . Martin dice que inmediatamente obtienes un montón de ventajas:

  • Gran grupo de talentos
  • Antigüedad bien distribuida
  • Mayor oferta = más asequible
  • Mejores prácticas generalizadas
  • Bueno para la rotación del equipo

Adoptar tecnología desconocida , por otro lado, significa que corre el riesgo de no poder encontrar excelentes contrataciones o (peor aún) gastar demasiado para contratar a alguien que resulta ser un fracaso.

Relacionado: La realidad de las API disruptivas

Los Doc Browns son peligrosos

Doc Brown es un genio, pero probablemente no sea el gerente de producto API más pragmático

Aquellos de ustedes que hayan visto Regreso al futuro y sus secuelas ya sabrán quién es Doc Brown . Para aquellos de ustedes que no lo han hecho, él es una encarnación ambulante del científico loco tropo del . Un eterno optimista y pensador excéntrico, Doc Brown no tiene miedo de pensar fuera de la caja.

"Tener un Doc Brown en su equipo es genial", dice Martin. "Incluso si no tienes un equipo de I + D, estos chicos son los que lo harán por ti". El peligro, dice, surge cuando se toman sus ideas y recomendaciones al pie de la letra .

Proporciona el ejemplo de la arquitectura sin servidor , sobre la cual un Doc Brown diría '¡Simplemente escríbalo una vez y luego puede implementarlo en cualquier lugar!' Excepto, dice Martin, “realmente no es así. Lo está implementando en AWS o Google Cloud Function o el servicio Azure ".

Antes de que se dé cuenta, necesita un marco como Serverless o Apex que realmente le permita implementar en cualquier lugar. Entonces necesitas una base de datos como DynamoDB. Antes de que te des cuenta, estás atrapado. “ Así es como la tecnología sin servidor se convierte en 'comprar más servicios '”, dice Martin.

La nueva tecnología puede ser limitante

Martin también habla de otras tendencias de desarrollo vistas por muchos Doc Browns como "la próxima gran novedad " en sus respectivos espacios, concretamente GraphQL y Microservices .

Cuando habla de GraphQL, Martin parafrasea a Xzibit, rapero y estrella de Pimp My Ride de MTV, en lo que probablemente será el único momento en el que se hará referencia a él en este blog diciendo: "Oye, ponemos SQL en tu SQL para que puedas SQL mientras usted SQL ".

Hemos sido fanáticos de GraphQL para ciertos escenarios y hemos escrito en otra parte sobre el plan maestro de Lee Byron para la ubicuidad de GraphQL. Sin embargo, Martin hace algunos puntos legítimos sobre las limitaciones que plantea:

  • GraphQL presenta un único punto de falla
  • Esquemas de datos duplicados
  • Si un servicio falla, toda la consulta fallará
  • No puedes predecir todas las rutas de código

Dicho esto, probablemente no iríamos tan lejos como su cortante declaración de que “es genial para los desarrolladores de interfaces, pero para nadie más”. También tiene algunas inquietudes mordaces, pero nuevamente válidas, sobre cómo los microservicios pueden aumentar la complejidad de una aplicación y un entorno de ejecución:

  • Ofrecer microservicios con éxito a menudo requiere la capacidad de escalar extremadamente rápido
  • La mayoría de las organizaciones no tienen una disponibilidad lo suficientemente baja como para necesitar microservicios
  • Los microservicios requieren un equipo dedicado para cada servicio, que requiere muchos recursos
  • Intentar navegar por el mundo de los microservicios sin alguien que tenga experiencia en hacerlo es muy difícil

“ Está bien construir un monolito ”, argumenta Martin. “¡No es una mala palabra! ¿Y los dominios que requieren microservicios? Podemos hacerlo más tarde ".

Pensamientos finales

A los desarrolladores de API les gustaría pensar que están por encima de la tentación de la tecnología, pero es algo común en nuestra industria. Considere, por ejemplo, cuántos se subieron al carro de REST sin pensar dos veces en si deshacerse de SOAP fue realmente una decisión inteligente para su servicio en particular.

El problema con esta comparación es que, con el beneficio de la retrospectiva, hacer la transición de SOAP a REST en realidad parece que ha sido un movimiento muy inteligente para muchos desarrolladores de API ... lo que complica el punto de vista de Martin de que "lo aburrido es lo mejor".

Vale la pena señalar, sin embargo, que Martin en realidad todavía aboga por echar un vistazo a las tecnologías emergentes, reconociendo que un Doc Brown es una valiosa adición para cualquier equipo. Lo que realmente está defendiendo es dar un paso atrás y considerar, en profundidad, si los beneficios de saltar a una nueva tecnología superan los riesgos.

Quizás el punto menos controvertido que hace Martin es que "un buen diseño de aplicaciones produce un buen diseño de API ". Además de ser algo en lo que todos podemos estar de acuerdo, este es un buen recordatorio de que la tecnología que utiliza un producto rara vez es tan importante como su funcionamiento.

Siempre que todo funcione como debería, es poco probable que alguien te llame por usar tecnología nueva / vieja o el lenguaje "incorrecto" ... a menos que tengan demasiado tiempo en sus manos.

Publicar un comentario

0 Comentarios