Header Ads Widget

Ticker

6/recent/ticker-posts

Su API nunca se lanza por completo

 


El panorama del desarrollo moderno ha cambiado desde que se desarrollaron las API por primera vez. Atrás quedaron los días en que los desarrolladores podían “desarrollar y olvidar”, lanzando API, sistemas o aplicaciones al público para su consumo y uso.

Hoy en día, no existe realmente un lanzamiento en el lenguaje común de antaño. Cuando un desarrollador lanza un producto, simplemente está diciendo que está listo para el consumo, no que esté terminado.

Ingrese al desarrollo continuo. El simple hecho es este: su API nunca se lanza por completo . Comprender este concepto simple y ajustar sus prácticas de desarrollo para lidiar con él no solo puede producir API extensibles y con una capacidad impresionante, sino que también puede aumentar drásticamente el rendimiento del mercado, los ingresos y la concepción pública.

¿Por qué desarrollar continuamente?

Nunca antes la humanidad había estado tan conectada como hoy. En las primeras décadas de comunicación masiva, el correo tenía que ser entregado en mano a lomos de un caballo para su comunicación, y aunque esto ciertamente unía estados, ciudades e incluso países divergentes, de ninguna manera era “rápido”.

Incluso con la invención de las redes, durante un tiempo, la experiencia fue similar a esos primeros días de comunicación. Los sistemas de tablones de anuncios tenían que ser "marcados", los mensajes se descargaban en discos locales y luego se leían y respondían, y se cargaban copias de las respuestas en los mismos sistemas. Durante un tiempo, Internet fue simplemente un tablero de anuncios gigante colgado en la pared del dormitorio de la humanidad.

Sin embargo, las cosas han cambiado. Atrás quedaron los días de esperar 24 horas para descargar una canción; ahora podemos transmitir video 4k HD desde la mitad del mundo, acceder a nuestro correo electrónico mientras volamos en aviones e incluso transmitir comunicaciones desde la Estación Espacial Internacional en tiempo casi real.

Ya no tenemos cientos de usuarios que acceden a los recursos de la red, ahora tenemos cientos de miles de usuarios Sin embargo, con este gran aumento de usuarios y el contenido que consumen, los recursos y sistemas necesarios para apoyarlos también han aumentado. La empresa de análisis de investigación Gartner estima que para finales de 2016, 6.500 millones de "cosas" estarán conectadas a Internet , todos los sistemas interconectados que dependen de API y recursos de red.

El simple hecho es que estos usuarios, sus sistemas y el Internet de las cosas en el que se integran son algunas de las entidades más exigentes del mundo, y estas demandas siempre están cambiando . Por lo tanto, un desarrollador de API debe cambiar con estas demandas, adaptarse a ellas y brindar estos servicios cuando sean necesarios. Si no pueden hacerlo, pierden su ventaja competitiva y se hace la pregunta: ¿un usuario realmente se quedará con un servicio diseñado para Internet de 2016 mientras usa Internet de 2020?

También relevante: Alcance DevOps Zen con estas herramientas de integración continua

Cuatro consejos para el desarrollo continuo

Dado este hecho, ¿cómo puede un desarrollador de API respaldar el desarrollo continuo ? Desafortunadamente, no es tan simple como decir "no dejaremos de desarrollarnos" y continuar con el ciclo de desarrollo normal. Es necesario tener en cuenta algunas cosas para respaldar de manera efectiva su seguimiento de desarrollo continuo y brindar un buen servicio a los usuarios desarrolladores.

Veamos cuatro consejos para el desarrollo continuo que todo proveedor de API debe tener en cuenta.

1: Limite su alcance

Uno de los mayores errores que puede cometer un proveedor de API en el desarrollo tradicional es no limitar su alcance de desarrollo . Sin una definición clara de para qué es exactamente su API y la gama de funciones que se supone que debe admitir, se prepara para un mundo de dolor.

En primer lugar, está configurando su API para el aumento de funciones ; al agregar demasiadas funciones a una API o sistema, la calidad y la velocidad del desarrollo se ven afectadas, al igual que la identidad del servicio. Tener un amplio alcance de desarrollo también significa naturalmente tener una amplia gama de cosas para desarrollar y actualizar continuamente a lo largo del tiempo.

Este aumento en los requisitos de desarrollo encarece la idea del desarrollo continuo y, en algunos casos, resulta prohibitivo. Considere desarrollar una API para codificación de video. Si su API está diseñada para admitir la codificación básica de tal vez dos o tres formatos de archivo, a medida que pase el tiempo, el desarrollo de su API solo requerirá soporte de códec adicional y soporte para llamadas especializadas de otras API y sistemas.

Para cada actualización necesaria de la API, el trabajo se amplía de dos a tres veces. Compare esto con la compatibilidad con 10 o 15 tipos de archivos, y podrá ver los problemas obvios en los que se incurre, y cada nueva actualización debe extenderse entre 10 y 15 puntos adicionales de funcionalidad.

2: Establecer una línea de tiempo

Establecer una línea de tiempo parece extraño cuando hablamos de desarrollo continuo. Sin embargo, el concepto que estamos discutiendo no es establecer una línea de tiempo en términos clásicos, no estamos hablando de programas de lanzamiento, fechas de lanzamiento de desarrollo, etc.

En pocas palabras, establecer un cronograma es establecer un programa de hitos temporal, modificable pero eficaz . Al establecer hitos y establecer un plan para lograrlos, no solo establece de manera efectiva un cronograma de expectativas para otros equipos, como el aseguramiento de la calidad, sino que también disuade naturalmente el aumento de características: si algo no está planeado, no se hace.

Lo mejor de establecer una línea de tiempo para su desarrollo es el beneficio adicional de establecer un ritmo. Con demasiada frecuencia, los desarrolladores de API piensan demasiado en términos de "sprint", desarrollándose tan rápido como pueden para una audiencia tan grande como puedan.

Esta es una mala posición para estar. Un ritmo de sprint significa que los procesos que deben desarrollarse no siempre se les da el tiempo que necesitan, y es posible que las funciones no se prueben completamente antes de implementarse.

Sin embargo, la mejor manera de marcar el ritmo de una línea de tiempo es pensar en " maratón ". Considere sus gastos inmediatos en términos de recursos y tiempo, y averigüe qué debe desarrollarse primero. Más concretamente, considere si su línea de tiempo tiene en cuenta la necesidad de estas cosas que deben hacerse. Mirando la línea de tiempo de manera integral, ese proyecto favorito puede parecer mucho menos importante cuando se enfrenta a la idea de que ha planeado otra característica más importante para su lanzamiento inmediatamente después y con un marco de tiempo más comprimido.

3: prueba de futuro

Es importante tener en cuenta que cuando consideramos la idea de pruebas futuras , no se les pide a los proveedores de API que conozcan el futuro. Lo que queremos decir con pruebas futuras es la idea de que, si se desarrolla correctamente, es posible que una API no tenga todas las funciones que se requerirán en el futuro, pero no se impedirá que implemente esas funciones.

Considere por un momento la API teórica mencionada anteriormente que maneja la codificación de video. A partir del ciclo de desarrollo inicial, la API implementó ciertos atajos de calidad de vida para los usuarios que la convirtieron en una herramienta muy poderosa y fácil de usar.

El problema ahora radica en esos atajos. La API detecta automáticamente el tipo de archivo y lo codifica con determinadas configuraciones. Por ejemplo, cuando el archivo está en 1080p, la API codifica usando h.246 a Mpeg.

Esto suena muy bien, pero hay un problema: ¿qué sucede cuando se lanza un formato de codificación mejor? ¿Qué sucede cuando h.246 tiene una nueva revisión? Todos estos casos futuros significan que el acceso directo que adjunta automáticamente un determinado tipo de archivo a un método de codificación no es efectivo y definitivamente no está preparado para el futuro.

Un gran ejemplo de fracaso en este ámbito en el mundo real es la crisis del año 2000 a finales de la década de 1990 y principios de la de 2000. El problema surgió de la adopción de convenciones de datación para la conservación de bits, lo que provocó que el año 2000 se transfiriera en el código base a 1900.

Se ha convertido en un meme común que el problema del Y2K no era un problema legítimo, pero eso está lejos de ser cierto. Compañías enteras dedicaron un gran personal de TI a corregir el código de los programas que no admitían los estándares de citas adecuados. Incluso entonces, el problema resultó en algunos problemas importantes que iban desde resultados de pruebas médicas incorrectos hasta falsas alarmas en plantas de generación nuclear .

Debido a que los desarrolladores de varias API y programas no tuvieron en cuenta la prueba futura de sus sistemas subyacentes, se lanzaron grandes problemas después del año.

Como desarrollador de API, no puede leer el futuro, pero puede hacer proyecciones . Asegúrese de que los problemas futuros conocidos se rectifiquen fácilmente o, al menos, no adopte atajos si harán que las revisiones futuras sean más difíciles.

Relacionado: Descargue nuestro libro electrónico gratuito sobre estrategias para la implementación continua

4: Evite las dependencias

Las dependencias son excelentes herramientas para los proveedores de API que deseen ampliar la usabilidad de su software. Desafortunadamente, muchos proveedores y desarrolladores de API no los utilizan para la extensibilidad, sino para la funcionalidad básica.

Es muy abrumador considerar el uso de una solución preformada para sus sistemas de gestión de correo o informes de errores, pero tiene un costo. Cuando llegue el futuro y necesite una solución mejor, el grado de integración de una solución de terceros y la cantidad de su código interno que dependa de ella determinará la eficiencia y eficacia con la que puede actualizar la fuente.

Eso no quiere decir que las dependencias deban evitarse; más exactamente, evite usar las dependencias como una muleta y codifique soluciones de conmutación por error para cuando estas dependencias fallan. En redes, existe un concepto llamado " falla de apertura ": cuando una puerta de seguridad de un armario de red está equipada con un escáner biométrico que falla, no se abre en lugar de permanecer bloqueada, de modo que las personas puedan entrar y salir en un emergencia.

Lo mismo es cierto aquí: está perfectamente bien usar una solución de terceros, pero tenga un plan de respaldo para cuando inevitablemente falle. Para su API, incluso algo tan simple como tener una base de código de comentarios con una conmutación por error que responda "lo sentimos, los servidores de comentarios no están disponibles en este momento" cuando su cliente de comentarios externo falla es mucho más efectivo que devolver un error tras otro a su usuario.

Evitar las dependencias de API cuando sea posible e implementar soluciones de respaldo cuando no sea posible, crea una API que hace lo que debe hacer incluso cuando lo que depende no está disponible. Esto crea un sistema perfecto y eficaz para todos los usuarios.

Conclusión

Afortunadamente, gran parte del ciclo de desarrollo continuo de API no es manual, como sugiere el "desarrollo continuo". Si bien es necesario realizar cambios para nuevos formatos, funcionalidades, etc., las estrategias de desarrollo inicial exitosas y la cultura de desarrollo general facilitarán la adaptación para el futuro.

Cualquiera que sea su situación, nunca lo olvide: su API nunca se libera por completo. Tenga esto en cuenta y utilícelo como una cultura de desarrollo, y el éxito se ganará y se mantendrá fácilmente.

Publicar un comentario

0 Comentarios