Panel de discusión de Red Hat Summit: los desarrolladores deben aprender rápido, centrarse en las pruebas y aprovechar las herramientas comunes para tener éxito
El grupo de desarrollo de aplicaciones convocado en la Red Hat Summit en Boston el 2 de mayo estaba formado por los siguientes actores clave:
Mark Little, vicepresidente de ingeniería, JBoss Middleware, Red Hat
Harry Mower, director sénior, Programas para desarrolladores
Stephanos Bacon, director sénior, estrategia de cartera, plataformas de aplicaciones
Los ejecutivos respondieron preguntas de la audiencia sobre hacia dónde se dirige el desarrollo de aplicaciones en el espacio de Red Hat.
«¿Cómo ve la evolución del espacio de desarrollo de aplicaciones empresariales en los últimos años?»
pequeño: «El mayor impulso aquí es nuestra necesidad de entregar más cosas más rápido. Como profesionales del desarrollo de software, hemos podido salirnos con la nuestra con muchas cosas, en lugar de perder tiempo automatizando implementaciones y demás, simplemente no se puede salirse con la suya nunca más».
Cortacésped: «En los últimos años, hemos visto un cambio de los desarrolladores a los equipos de desarrollo. No se trata de escribir código, sino de aportar valor al negocio. No es discutible decir que todas las empresas son empresas de software en estos días. En medio de la año, vimos un cambio hacia la escritura de código rápido y confiable que crea valor para la empresa. Todos piensan en los contenedores como unidades atómicas de ejecución, ya sea que estén en las instalaciones, en la nube, sin sistema operativo, etc. Políticas de desarrollo de todos tener contenedores, pero el enfoque y la arquitectura aún están abiertos a debate.
Little agregó: «No es solo un cambio en el código, es un cambio en la forma en que pensamos sobre el código. Para ayudar con esto, los desarrolladores están buscando conjuntos de herramientas más completos para ayudar a hacer el trabajo más rápido. Las herramientas para el lanzamiento ágil o rápido de aplicaciones se están volviendo tan importante como las propias aplicaciones».
VER: OpenShift.io de Red Hat tiene como objetivo proporcionar una plataforma de desarrollo de código abierto completa
«¿Existe una tendencia hacia los microservicios que se alejan de las aplicaciones monolíticas?»
Cortacésped: «Hay un movimiento definitivo, que puede considerarse racional o una moda pasajera o algo intermedio, para descomponer una aplicación en microservicios. Antes teníamos una arquitectura de servicio. Estamos tratando de hacerlo y de diferentes maneras, y mira cómo hacer que los equipos funcionen mejor para que diferentes equipos puedan trabajar en diferentes partes.
En teoría, esta es una gran práctica, como el modelo de Netflix o Etsy, pero presenta desafíos. La complejidad adicional conduce a un nuevo conjunto de problemas. Advertimos a las personas que no salten directamente a los microservicios. Hay muchas razones viables para hacer las cosas de manera holística. No te metas con algo bueno si la aplicación ya se está ejecutando y funcionando. Hay un conjunto completamente nuevo de pensamiento en torno a estas cosas. Queremos servir a todos de manera constructiva. «
pequeño: «Mencioné antes la agilidad: una de las razones por las que vemos que las personas se pasan a los microservicios es para lanzar aplicaciones en 18 días en lugar de 18 meses. Al dividir el monolito en servicios independientes, puede publicarlos. Un ciclo de 18 días podría ser bueno para Netflix, pero no para BP o BT. Tal vez podrían lanzar cada 3 meses en lugar de los 18 meses actuales, que es una mejor cadencia. Sí Mejores prácticas y herramientas arquitectónicas. La arquitectura orientada a servicios puede ser otro enfoque.
Los microservicios no son para todos. Realmente impulsa los sistemas distribuidos. Durante los últimos 20 años, el desarrollo de la potencia de la CPU, máquinas más baratas y lenguajes de subprocesos ha llevado a un alojamiento de servicios más independiente. La generación actual de desarrolladores realmente no está acostumbrada a los sistemas distribuidos. La gente fuera de la universidad probablemente use sus navegadores y servidores web y eso es todo. De hecho, usábamos sistemas distribuidos hace 30 años, pero en ese momento estábamos llevando estos principios a la práctica del desarrollo. Ahora se trata de microservicios arquitectónicos, y si salta a ellos sin saberlo, terminará en un mundo de dolor. Tendrá fallas parciales, problemas de recuperación: debe comprender lo positivo y lo negativo. «
«Estás hablando de desarrollo de aplicaciones, ¿qué atributos necesitan los desarrolladores?»
tocino: «Si sigue la ruta de los microservicios, entonces los sistemas distribuidos son definitivamente importantes. Mi punto es que si quiere ser desarrollador, debe comprender la informática cuando está creando algo más grande que una aplicación de juguete». que si observa la cantidad de lenguajes de programación y marcos, encontrará que hay muchas opciones y sistemas para construir componentes en cualquier aplicación que tenga más sentido. Los desarrolladores deben ser multilingües. Necesitan aprender nuevos cada día El poder de las cosas. Todos los días en Red Hat, escucho cosas de las que no sé nada. Tengo que aprender. La colaboración es mucho más importante que hace 10 años».
pequeño: «Cambiamos a una mentalidad de DevOps en todos los ámbitos. Los desarrolladores deben comprender que si lo construyen, es mejor que lo prueben y estén activos cuando se rompa. Los clientes no deberían probar el código. Si no lo prueba, probablemente esté atascado Llame al solucionador de problemas. Ya sea que recién haya terminado la universidad o esté en capacitación, concéntrese en las pruebas unitarias y comprenda cómo se diferencian del control de calidad. Las pruebas unitarias en todos los lenguajes de programación tienen mucho en común. Los desarrolladores pueden Supongo que hay un equipo de control de calidad para probar esto por ellos».
Cortacésped: «Mi punto es que los desarrolladores no necesitan saber mucho. Un gran problema es nuestra falta de capacidad para escribir código; algo de magia arcana que solo un doctorado puede hacer. Muchos de los mejores desarrolladores no comienzan a desarrollar. We One de los mejores evangelistas es un gerente de teatro. Tenemos todas estas reglas para los trabajos de desarrollador, y no le está haciendo ningún favor a la industria. Necesitan poder aprender y comenzar temprano. Requerir un título de cuatro años no está ayudando a nuestra industria. los programas serían mejores: la capacitación como una carrera en lugar de una ciencia. Esto cambia demasiado. Después de la universidad, debe conocer algunos conocimientos básicos: sistemas distribuidos, informática, pero debe estar en Aprender en el trabajo «.
VER: Informe: el 80 % de las empresas que contrataron a graduados de bootcamp de codificación dijeron que lo volverían a hacer
pequeño: «Hay algunas cosas básicas que debes saber. Mi hijo tiene 14 años, y desde que le compramos una licencia de Minecraft, ha sido desarrollador de Java a los 10. Si le digo cómo programar, se callará y pasará a algo». más. Literalmente aprendió por sí mismo cómo escribir Java, crear mods, distribuirlos a sus amigos, ejecutarlos en la nube. A veces, los mods no funcionan y uno de sus amigos se lo notifica, él los arreglaría. Entonces, aprendió por sí mismo cómo probarlos antes de dárselos a sus amigos. Ni siquiera fue a la universidad, pero sabía cómo modificar Minecraft.
«¿Cómo reconcilia Red Hat en su ‘información pública’ su posición en el negocio de productos que no se tratan de opciones sino que encajan con el caso de negocios?
Cortacésped: Nuestra visión para OpenShift.io es múltiple. Los clientes nos dicen cuánto tiempo y dinero gastan en integrar todas sus herramientas. Queremos que tengan la opción de no gastar tiempo y dinero y, en su lugar, centrarse en desarrollar software para mejorar su negocio. Con OpenShift.io, tiene la opción de comenzar sin configurar nada. Sabemos que a algunos clientes no les gustará esto.
Proporcionaremos un modelo de escalabilidad para integrar los mejores productos, como herramientas en la cadena de herramientas, que son el núcleo del negocio. La gente querrá ejecutarlo localmente, no solo en la nube. Dicho esto, creemos que con el tiempo la gente se cansará de hacerlo. Los clientes con los que he hablado a lo largo de los años me han dicho «preferimos que lo haga por nosotros». El proceso de desarrollo cambiará, lo que integres hoy será menos común en el futuro.
pequeño: «Esto no es algo específico de OpenShift.io. Los clientes nos piden que seamos más disciplinados. Las opciones son buenas, pero demasiadas opciones pueden abrumarlos y no saber qué hacer. Concéntrese en uno o dos enfoques recomendados. 15 -El 20 % de las personas querrían usar la otra forma y aún así poder hacerlo, pero no es algo que recomendamos. A veces eliminamos cosas de un proyecto cuando simplemente creamos un producto».
«El elefante en la sala de desarrollo es hacer las cosas más rápido y mejor, pero la gente no está pensando en la seguridad. ¿Qué puede hacer la comunidad de desarrollo para construir la seguridad a nivel del suelo?»
tocino: «Puedo comenzar con algunas cosas. Por supuesto, una violación de datos puede dañar a una empresa, por lo que el desarrollador tiene cierta responsabilidad. Si adopta una plataforma como OpenShift, entonces tiene algún tipo de similitud y más control sobre lo que sucede». Qué diablos, es más probable que TI tenga el control a nivel de plataforma y se lo quite a los desarrolladores.
pequeño: «Cualquiera que se haya preocupado por la seguridad desde el principio no es ajeno a DevOps o microservicios. Crear seguridad después del hecho siempre es algo que se hace. Múltiples estudios muestran que el software de código abierto es más seguro que el software de código cerrado». Mitre Corporation en 2006 Se llevó a cabo un estudio que comparó Microsoft SQL Server frente a MySQL y descubrió que MySQL tenía 1000 veces menos errores en bases de código similares. Otro estudio similar se centró en Windows frente a Linux. Se centró más en el código abierto para que las personas pudieran trabajar en la búsqueda de vulnerabilidades y aplicar arreglos antes de que sean explotados. No es una varita mágica, pero tenemos la capacidad de aprovechar esto”.
Cortacésped: «Estamos trabajando en esto y otros están trabajando en ello. Estamos introduciendo capacidades bayesianas y centrándonos en paquetes de código abierto para escanearlos en la naturaleza. Si hay vulnerabilidades conocidas, podemos sugerir alternativas». hasta lo que podemos hacer con esta tecnología. Podemos analizar el código en busca de vulnerabilidades y anomalías y proporcionar recomendaciones a los desarrolladores en tiempo real».
Ver también:
