Aprender a programar - Recomendaciones

[Tim]

Diré lo que dijo una ponente en las charlas Agile del año pasado en Coruña: o es un cambio cultural o no es. DevOps significa cambiar muchas cosas. Pero no se trata de cambiar en muchas ocasiones, sino de que empresas migran a la nube o rehacen toda su arquitectura y se aprovecha para hacer el cambio.

DevOps en Azure bien implementado es bestial. Si la infraestructura además se gestiona con Terraform, el pack es perfecto. La automatización y aumento de la productividad es enorme. La gestión de entornos, todos iguales, aprobaciones, etc. es una virgueria. Que un desarrollador haga un cambio en una determinada rama, quiera aplicarlo a un entorno, necesite aprobación, se analice el código… se puede hacer de todo. Eso implica muchas cosas, pero por encima de todo, que la gente de la empresa cambie. Que la gente de IT de repente haga todo por Terraform y entiendan las ventajas, es complicado. Antes cada área tenía su cortijo y ahora implica más coordinación. Y en esas estoy yo. Una de las cosas más importantes que me toca hacer es gestión de conflictos, jeje.

 

[TheReeler]

Por ahí no paso. Es la guerra que tengo con el manager de IT, que quiere que justamente hagamos eso. Cuando le pregunté cómo demonios iba a poner todo ahí y adaptar toda mi arquitectura a un sistema que "mañana" MS puede decidir subir brutalmente los precios.... estas de coña,.no?

Ahora mismo no soy dependiente de ningún data center, puedo desplegar mis productos donde me salga de las narices sin estar atado de pies y manos. Jamás cambiaré ni haré mi proyecto dependiente de algo así.

Cuando ahora MS ha decidido subir una barbaridad los precios de Office 365, todos hemos sido rehenes, no ha habido más remedio que pasar por el aro aunque la subida haya sido de más o menos un 20%,

¿Tú imaginas lo que podría pasar si "mañana" hicieran lo mismo con servicios de AZ que me hubiera adaptado a ellos y de repente costara un 20% más? A mi me parece de locos

 

[Miguel_Angel]

Voy a poner un ejemplo que conozco de primera mano. Una de las apps que hacemos estaba escrita para framework Cordova. Teníamos que integrar un componente de un fabricante que lo hacía en Dart, así que el Director Técnico, en contra de mi criterio inicial, propone reescribir toda la app a Dart.

Al final, no quiero discutir (bastantes guerras tengo ya) y le digo que OK, que la reescribimos al completo en Dart, pero que lo haga otra delegación.

Nos reunimos con la delegación que lo va a hacer y explicamos en diversas reuniones que queremos conseguir. Facilitamos incluso el código fuente de la actual App para Cordova y nos dicen que ellos trabajan todo con Azure DevOps, nos venden las ventajas que tiene, blablabla, y que en dos, máximo tres meses, tendremos el producto acabo y libre de errores.

Para hacer la historia corta. Esto fue en Mayo de 2022.... y han entregado finalmente una app que puede distribuirse en Octubre de este año.

La pila de errores y mierdas hechas sin sentido que iban más lentas que el gancho de un paralítico han sido enormes. ¿Que mierda de ventaja ha aportado en el resultado final? A la práctica, ninguna ventaja, ya te lo digo yo.

Y ojo, que no eran tampoco unos becarios los que lo han hecho, que tienen la debida certificación oficial de Microsoft para toda esa mierda.

Lo que tengo claro, como pollavieja que soy, es que este tipo de entornos sirven para que la gente cada vez programe peor y piense menos. Consiguieron un producto que es MUCHO más lento que lo que ya teníamos nosotros y que no aporta nada mejor, cero improve. Si ni siquiera han sido más rápidos desarrollando ni testeando nada, ¿para qué demonios sirve todo ese tinglado? En serio que sigo sin entenderlo.

Hace falta un buen Jefe de producto ahi!

 

[TheReeler]

No, no es ese el fallo, lo es el creer que cuando tienes un martillo, todo lo que ves son clavos.

 

[Miguel_Angel]

Eso tambien .

Yo estoy comenzando a explorar Azure ahora en clase.

 

[Tim]

Eso tambien .

Yo estoy comenzando a explorar Azure ahora en clase.

Azure, igual que AWS o Google Cloud es un compendio de todo lo que era IT. Un mundo.

Estudia qué es DevOps. No la herramienta de Azure, sino lo que es DevOps. Es un cambio cultural muy bestia en empresas que transforman su IT para llevarlo a la nube. Lo comentaba con un chaval que tenemos de becario, que empezar de cero no está mal. Pero es muy interesante el cambio, la gestión de conflictos…

 

[Miguel_Angel]

Azure, igual que AWS o Google Cloud es un compendio de todo lo que era IT. Un mundo.

Estudia qué es DevOps. No la herramienta de Azure, sino lo que es DevOps. Es un cambio cultural muy bestia en empresas que transforman su IT para llevarlo a la nube. Lo comentaba con un chaval que tenemos de becario, que empezar de cero no está mal. Pero es muy interesante el cambio, la gestión de conflictos…

La empresa que deje hace dos meses tiene DevOps como metodologia de desarrollo de software, de hecho, yo estaba integrado en ese departamento .

Como es pequeña, los desarrolladores trabajan a traves de "Mob sessions".. y ya no puedo ver el desarrollo de software de ninguna otra manera

¡Me parece fascinante y sorprendente que las empresas no se adapten a esto!

 

[Tim]

DevOps NO es una metodología de desarrollo de software. Es un error habitual y muy grave, crítico de cara a una empresa. Esto tiene su explicación. Quienes se encargan de montar una empresa de cero o bien transformarla suelen estar más cerca de la parte de desarrollo. Como es tu caso. Por desconocimiento, se os suele olvidar un pequeño detalle.

Como suelo decir, DevOps se compone de dos palabras y NADIE se acuerda de la segunda, Ops.

Como las plataformas Cloud son tan “fáciles” de administrar, porque en la consola haces unos clicks y tienes desplegado lo que quieras, ¿para qué la gente de IT? Eso bien pueden hacerlo los de desarrollo. Si es una empresa de nueva creación esto se eleva a su máxima potencia, bien puede crearse la empresa con lo que puedan manejar el Cloud los desarrolladores.

Y ahora la realidad: un desarrollador no tiene NI IDEA de la parte de Ops. Lo que siempre se ha llamado IT. Hablaba el otro día con un responsable de una empresa energética española sobre esto. Me preguntaba si sabía de AWS, porque yo controlo mucho de Azure. Mi respuesta fue clara: llevo 20 años trabajando. Desde el día 1 en la parte de Sistemas. No he programado una línea de código en mi vida. He sido consultor, administrador, arquitecto… me da igual que me pongan Azure, AWS o la que sea. El Cloud es una abstracción de lo de siempre. Un balanceador de carga lo es en físico o en la nube. El networking exactamente igual. Y así con todo. Es habitual que la gente que empieza se enfoque en un Cloud, por lo que pasar a otro les cuesta más. Pero si realmente sabes lo que estás manejando, te da lo mismo.

Los desarrolladores no saben ni de la parte antigua ni de la nueva. Ni van a saber. He tenido discusiones acerca de cómo ciertos servicios están desplegados y publicados y juro que me pareció estar volviendo a conversaciones de hace 20 años, cuando las empresas tenían “cuatro” servidores. Normal, un desarrollador no sabe los conceptos y por tanto no puede ni entenderlos.

Así que llegamos al momento de DevOps. De cada 100 que salen de la facultad, FP, etc. 99 son desarrolladores. Encontrar a esa persona que quiere dedicarse al otro lado es un milagro. Lo vivo a diario. Estoy trabajando con dos chavales que aún no presentaron proyecto en la facultad y al mes le dijimos a los jefes que no los dejen escapar.

Alguien estará pensando: ¿y cuál es el problema de que no haya gente de IT? Si se despliega todo fácilmente y funciona, ¿qué inconveniente hay? El debate se puede alargar hasta el infinito, así que lo resumiré en una palabra: SEGURIDAD.

Lo veo todos los días. Empresas preocupadas porque su código pase análisis de vulnerabilidades. Empresas que luego no saben si el entorno donde se despliega ese código está securizado. La respuesta ya la doy yo: no lo está.

En mi anterior empresa esto empezó igual. Hasta al CEO llegaron a decirle que no iba a hacer falta IT. Cuando entré al proyecto activé la herramienta de Azure de seguridad (Defender for Cloud). Más de 500 agujeros de seguridad, cientos gravísimos. Una arquitectura de red imposible de corregir a corto plazo. Un auténtico desastre. El código impoluto. Luego entrabas desde internet a los servicios publicados en entornos de desarrollo sin autenticarte.

Total, que ya puestos a aprender de cero qué es DevOps, lo tenéis fácil, leed la palabra. Si no tenéis un equipo de especialistas de la segunda parte, SUERTE

 

[TheReeler]

Coincido @Tim, pero ahora vamos a la realidad.

Te pongo un ejemplo muy rápido de algo que me sucedió hace no demasiados meses y que solicité a los expertos en estos temas: "Necesito disponer en Azure de un *servicio* de MQTT con conexiones NB-IoT

Ahora imagínate la respuesta

 

[TheReeler]

Otro caso, este mucho peor. Tenemos unos servicios de comunicaciones a los cuales se conectan equipos de diversa índole y envían/reciben información. La mayoría, sensónica. El software que controla y gestiona todos los equipos (heterogéneos) necesita conocer la IP real de cada uno de los equipos que tiene.

Hacemos una instalación desde cero en Azure con todas las medidas de seguridad "jandermil" que consideran los expertos en Azure y que son lo que aportan valor de verdad y por lo que quieren que migre este sistema allí. Una vez puesto a funcionar todo, vemos que en el servicio vemos todos los dispositivos con la misma IP.

Les digo que eso no sirve, que la IP no puede ser la misma. Me dicen que la IP que "ve" el servicio es la del firewall, y que eso ha de ser así para poder tener todos los sistemas de seguridad que se necesitan, que el simple hecho de que quiera ver la IP real pasa por una solución que... ahora mismo no tienen.

Tócate los cojones chaval, y llegaron a decirnos que cambiáramos el SW para que esto no fuera así y no se necesitara conocer la IP real en cada caso. ¿Pero tú lo ves normal?. Igual que tú te quejas (con razón) de lo que dices, yo me quejo que muchos del otro lado no tienen ni la más mínima idea de como funcionan las cosas y has de adaptar todos hacia como ellos quieren, cuando en ocasiones es imposible y no tiene razón alguna de ser.

Pues ahí llevamos más de un año, donde los expertos de AZ llevan nosecuantas reuniones con gente de MS y no dan con la clave... salvo que quiten las capas extra de seguridad que precisamente dicen que es su valor añadido. ¿No es para reirse?

 

[Tim]

Hazte esta pregunta: ¿si tuvieses todo en tu datacenter esa gente sabría montar eso que les pides? Apuesto a que no. No iban a saber montar ese servicio MQTT (seguramente no sepan ni qué es Mosquitto) ni lo de la red. Y en cuanto te abstraes, más difícil todavía, porque encontrar estas cosas en Cloud a veces es realmente complejo.

Ahora viene la segunda parte: no hay gente. Y que sepan, menos. No había gente para Sistemas y con las empresas queriendo ir a la nube, muchas de ellas que antes igual ni tenían más IT que gente que administra la red y cosas así, directamente es imposible encontrar. Hay cientos de ofertas en LinkedIn. No se cubren. En mi empresa se dan 1500€ de subida de sueldo por sacar ciertas certificaciones para intentar que los cuatro que hay no nos vayamos.

Está complicado el tema. Si juntas que de un lado no hay gente y del otro quieren meter DevOps, el resultado es el comentado: se lo guisa y se lo come desarrollo.

 

[Magneto]

Hablo como desarrollador web y os doy la razón, yo te hago la página web y necesito a alguien que implemente la seguridad, para que no jodan mi código, porque no sé. No sé hacer de todo, tengo limitaciones.
Soy un pobrecito desarrollador web junior que lleva apenas un año, no soy el puto Mago de Oz ( hago cosillas mi cuenta y riesgo personal, no estoy en una consultora o empresa de este sector).

 

[TheReeler]

Hazte esta pregunta: ¿si tuvieses todo en tu datacenter esa gente sabría montar eso que les pides? Apuesto a que no. No iban a saber montar ese servicio MQTT (seguramente no sepan ni qué es Mosquitto) ni lo de la red. Y en cuanto te abstraes, más difícil todavía, porque encontrar estas cosas en Cloud a veces es realmente complejo.

Ahora viene la segunda parte: no hay gente. Y que sepan, menos. No había gente para Sistemas y con las empresas queriendo ir a la nube, muchas de ellas que antes igual ni tenían más IT que gente que administra la red y cosas así, directamente es imposible encontrar. Hay cientos de ofertas en LinkedIn. No se cubren. En mi empresa se dan 1500€ de subida de sueldo por sacar ciertas certificaciones para intentar que los cuatro que hay no nos vayamos.

Está complicado el tema. Si juntas que de un lado no hay gente y del otro quieren meter DevOps, el resultado es el comentado: se lo guisa y se lo come desarrollo.

No me he explicado. A mi me dicen que AZ dispone de SERVICIO MQTT, no con una máquina virtual, no, como SERVICIO, de tal forma que da igual si conecto un sensor o diez millones, y que se me factura dependiendo de los sensores que haya. Genial!!! "pues montadlo".
Y ahí empiezan los "peros". Que lo pueden montar pero que no vale que sea NB-IoT, que lo cambiemos.

Pero vamos a ver pedazo de melón, que estás hablando de hardware que trabaja con NBIoT, ¿cómo vas a cambiar algo así? ¿No entiendes que no estás dando solución a la necesidad que hay?

E insisto, que aquí cogen el teléfono y hablan directamente con AZ, saben a que colegio van sus hijos, se "conocen" (como nosotros en el foro), y aún así ni los unos ni los otros. ¿Y me pides que me vaya a un entorno que gestionas tú (ellos) y no sabes resolver los problemas que tú mismo creas?.

En serio, es acojonante. Hay tal desconexión con la realidad que a uno le deja perplejo. Y estoy convencido que los de IT estarán a su vez convencidos que el resto del mundo son inútiles.... con la diferencia de que nosotros tenemos nuestro propio departamento local de IT y hablan cada día entre ellos y los otros siguen sin enterarse de la misa la mitad.

En la última reunión que tuve al respecto, con el manager de IT a nivel mundial, le explicaba los pormenores de todo el sistema y el tío entendió perfectamente el porqué eran así las cosas... pero él a lo suyo, a día de hoy seguimos sin soluciones. Y es que, en mi opinión, él está asumiendo un riesgo enorme al haber puesto todos los huevos en la misma cesta, para mi es un error mayúsculo y que le puede acabar pasando factura (puede que el cargo, quien sabe).

 

[Miguel_Angel]

DevOps NO es una metodología de desarrollo de software. Es un error habitual y muy grave, crítico de cara a una empresa. Esto tiene su explicación. Quienes se encargan de montar una empresa de cero o bien transformarla suelen estar más cerca de la parte de desarrollo. Como es tu caso. Por desconocimiento, se os suele olvidar un pequeño detalle.

Como suelo decir, DevOps se compone de dos palabras y NADIE se acuerda de la segunda, Ops.

Como las plataformas Cloud son tan “fáciles” de administrar, porque en la consola haces unos clicks y tienes desplegado lo que quieras, ¿para qué la gente de IT? Eso bien pueden hacerlo los de desarrollo. Si es una empresa de nueva creación esto se eleva a su máxima potencia, bien puede crearse la empresa con lo que puedan manejar el Cloud los desarrolladores.

Y ahora la realidad: un desarrollador no tiene NI IDEA de la parte de Ops. Lo que siempre se ha llamado IT. Hablaba el otro día con un responsable de una empresa energética española sobre esto. Me preguntaba si sabía de AWS, porque yo controlo mucho de Azure. Mi respuesta fue clara: llevo 20 años trabajando. Desde el día 1 en la parte de Sistemas. No he programado una línea de código en mi vida. He sido consultor, administrador, arquitecto… me da igual que me pongan Azure, AWS o la que sea. El Cloud es una abstracción de lo de siempre. Un balanceador de carga lo es en físico o en la nube. El networking exactamente igual. Y así con todo. Es habitual que la gente que empieza se enfoque en un Cloud, por lo que pasar a otro les cuesta más. Pero si realmente sabes lo que estás manejando, te da lo mismo.

Los desarrolladores no saben ni de la parte antigua ni de la nueva. Ni van a saber. He tenido discusiones acerca de cómo ciertos servicios están desplegados y publicados y juro que me pareció estar volviendo a conversaciones de hace 20 años, cuando las empresas tenían “cuatro” servidores. Normal, un desarrollador no sabe los conceptos y por tanto no puede ni entenderlos.

Así que llegamos al momento de DevOps. De cada 100 que salen de la facultad, FP, etc. 99 son desarrolladores. Encontrar a esa persona que quiere dedicarse al otro lado es un milagro. Lo vivo a diario. Estoy trabajando con dos chavales que aún no presentaron proyecto en la facultad y al mes le dijimos a los jefes que no los dejen escapar.

Alguien estará pensando: ¿y cuál es el problema de que no haya gente de IT? Si se despliega todo fácilmente y funciona, ¿qué inconveniente hay? El debate se puede alargar hasta el infinito, así que lo resumiré en una palabra: SEGURIDAD.

Lo veo todos los días. Empresas preocupadas porque su código pase análisis de vulnerabilidades. Empresas que luego no saben si el entorno donde se despliega ese código está securizado. La respuesta ya la doy yo: no lo está.

En mi anterior empresa esto empezó igual. Hasta al CEO llegaron a decirle que no iba a hacer falta IT. Cuando entré al proyecto activé la herramienta de Azure de seguridad (Defender for Cloud). Más de 500 agujeros de seguridad, cientos gravísimos. Una arquitectura de red imposible de corregir a corto plazo. Un auténtico desastre. El código impoluto. Luego entrabas desde internet a los servicios publicados en entornos de desarrollo sin autenticarte.

Total, que ya puestos a aprender de cero qué es DevOps, lo tenéis fácil, leed la palabra. Si no tenéis un equipo de especialistas de la segunda parte, SUERTE

Bueno, llamalo como quieras para mi, de momento, es una metodologia / sistema de trabajo.. que lo dicen los mismos que lo inventaron, "software engineering methodology".

En cualquier caso y para aprender, desde tu punto de vista, ¿que engloba la parte de IT Ops?

 

[Tim]

Tú haces una web. ¿Donde funciona esa web? Pues eso. Todo ese mundo que hay ahí “debajo”.

Cuando accedes al foro, a Gmail… hay una infraestructura haciendo que el software funcione. Que si inicias sesión en Gmail y luego vas YouTube ya estés con ese usuario. Que haya alta disponibilidad, que no haya agujeros de seguridad. Que no te puedan atacar tus sistemas. Podemos echar aquí el día enumerando.

Y precisamente como la gente de desarrollo no sabe qué hay, difícilmente pueden gestionarlo. Luego pasa lo que pasa.

Pero no, no es una metodología de desarrollo de software. Esa es la parte del nombre que pone Dev. Os falta la otra. No me sorprende porque me dedico a esto, pero es curioso el desconocimiento que tiene la gente de desarrollo de cómo funciona luego su código. Es como si el que diseña el cambio de marchas de un coche no supiese lo que es un motor. No que no sepa cómo funciona, peor, que no sabe ni lo que es. Este es el resumen del estado de la transición al Cloud en las empresas.

 

[Tim]

Ya que hablamos de Azure, un ejemplo sencillo. Desarrollo y Sistemas han de trabajar, en parte, en equipo. Es donde se cruzan las flechas.

Los desarrolladores solamente conocen la parte de la izquierda. Los de Sistemas los de la derecha. Un buen coordinador (poned aquí el nombre en inglés más rimbombante que se os ocurra) ha de estar en el punto intermedio. Sabiendo de ambos mundos y poniendo cordura. ¿Cuál es el primer problema? Que el 99,99% de la gente no sabe de Sistemas. Eso es algo histórico. Y sigue igual, como ya comenté de la gente que sale de la facultad. Así que normalmente ese rol lo hace alguien de desarrollo. Y, por tanto, obvian todo lo que hay a la derecha. Directamente no se gestiona. Error gravísimo de cara a la seguridad de la empresa, entre otras cosas.

DevOps es construir una casa. Los que hacen la estructura no saben de fontanería. Los fontaneros no saben de electricidad. Y así con todo. Pero hay una gente en medio haciendo que ese flujo funcione. No se ha inventado la rueda con DevOps, hay muchas otras disciplinas del ser humano que ya trabajan así. Se llama coordinar. Se llama ser jefe de obra, por ejemplo. Un jefe de obra coge los planos del arquitecto y hace que la casa se construya. Coordina a todos, para que cuando un lado necesite una cosa del otro, sea ágil.

Jefes de obra hay muchos. Porque albañiles que sepan de todo hay muchos. Así que encontrar a especialistas que sepan asumir esa tarea es más fácil. Pero en informática, y a la pregunta de qué es la otra parte me ciño, no. La gente de desarrollo no sabe qué es lo otro. No lo han visto delante jamás. Por tanto es imposible que sepan coordinar. Lo que se hace es quedarse con una parte, Dev, y la otra asumir que el Cloud funcione solo.

 

[TheReeler]

¿Cuál es el primer problema? Que el 99,99% de la gente no sabe de Sistemas. Eso es algo histórico.

Dale la vuelta. ¿Cuántos de sistemas saben (de verdad) de programación? Y algo de esto sé.... llevo ambos departamentos (IT y Desarrollo).
Las mismas "quejas" de un lado las hay al contrario. A mi también me toca estar en el medio de todo y soy algo así como el que sabe tanto lo de un lado como lo del otro.

 

[Tim]

Dale la vuelta. ¿Cuántos de sistemas saben (de verdad) de programación? Y algo de esto sé.... llevo ambos departamentos (IT y Desarrollo).
Las mismas "quejas" de un lado las hay al contrario. A mi también me toca estar en el medio de todo y soy algo así como el que sabe tanto lo de un lado como lo del otro.

Sí y no.

Estudies lo que estudies de informática, te van a enseñar a programar. Algo, así sea como yo que llevo 20 años sin picar una línea, has aprendido en un momento.

Pero da igual. Hasta ahora, desarrollo hacía su software e IT lo implantaba siguiendo las instrucciones que les decían. IT ya se encargaría de la seguridad, redes, alta disponibilidad... Una parte no sabía lo que hacía la otra, aunque en IT siempre es más fácil entender a los desarrolladores, porque todos hemos estudiado lo mismo aunque luego los caminos fuesen en sentidos distintos.

Era una forma de trabajar que funcionaba. DevOps coge y mezcla ambos mundos. Porque el desarrollo de software se orienta a contenedores, a módulos más pequeños y un despliegue constante. Ya no son las actualizaciones gigantes de software. Por narices en medio tiene que haber una coordinación.

Llegado este punto entran AWS, Azure... y desde el punto de vista de los desarrolladores, también para muchos otros roles de la empresa, la parte de IT se simplifica. Con un wizard donde hay que elegir diez cosas tienes un cluster de Kubernetes. ¿Qué misterio tiene esto entonces? ¿Para qué necesitamos a los de sistemas?

DevOps suele aparecer desde la parte de desarrollo, para poder ser más ágiles. Como son los primeros en investigar el tema en una empresa en funcionamiento, son los que ven que todo puede ser más fácil. Error mayúsculo. La palabra tiene "Ops" por algo.

Cuando entré en mi nueva empresa, muchos hacen análisis de código para detectar vulnerabilidades. Y un día se lo dije a uno de mis jefazos: ¿De qué vale que el código esté impoluto si donde lo ejecutas está todo mal? ¿Quién mira que donde se ejecuta esté perfecto? Trabajamos con clientes gordos, como tantas otras consultoras, y no hay respuesta a eso. Hasta Inditex lleva meses buscando este perfil porque no hay quien haga ese análisis. Que Azure te dice lo que está mal, el problema es arreglarlo. Como si alguien te detecta una fuga de gas en un edificio, ahora falta saber solucionarlo y sin que afecte en nada a los que ahí viven. No es trivial. Hace falta gente con conocimientos de sistemas, networking, seguridad... Pero somos los mismos desde hace siglos y poca gente se incorpora a esto. Por ese motivo me contrataron en mi nueva empresa, porque ni mi propia empresa tiene un perfil de este estilo.

 

[Tim]

Adjunto un informe de 2023 que ha hecho SUSE.

Un coladero. Lo de container firewall, Kubernetes network policies y todo lo relacionado con esa parte, me hace muchísima gracia. Los desarrolladores lo flipan con sus microservicios, qué agilidad de cara al cliente. Luego...
- La imagen que usan para crear el contenedor está obsoleta y tiene agujeros de seguridad.
- Los servidores donde se ejecutan Kubernetes están sin actualizar.
- No se aplican políticas de seguridad a Kubernetes.
- Los pods (contenedores) lo mismo cogen una IP de un rango que les hemos asignado y esa red está abierta a todo hijo de vecino dentro del cloud.
- Porque ni dios pone seguridad en la red en Cloud, se piensan que por defecto todo es seguro. En mi anterior empresa los de desarrollo no había desplegado ni un firewall en Azure.

Pagas por una herramienta y te dice todos los problemas. ¿Pero quién sabe gestionar la seguridad en Kubernetes?
De la publicación a internet, configuración de WAF y demás mejor no hablo porque es chino.

Lo dicho: suerte con DevOps y suerte con el Cloud. Antes tenías todo en tu sitio y con suerte había un par de frikis que controlaban a muerte y bueno, malo sería que no hubiese unas cuantas medidas de seguridad implementadas. Ahora esa gente queda a un lado, que seguramente supiesen administrar la seguridad de Kubernetes porque es todo por comandos y extremadamente técnico, y a rezar. Luego pasa lo que pasa. Y como comentó alguna vez un forero, disculpad que no recuerde el nombre, cuando te enteras que te entraron, ya llevaban ahí fácil un año, analizándote, sabiendo lo que podrías pagar... Pero eh, a tope con la metodología ágil, olvidemos el resto. Los datacenters de Amazon, Microsoft, Google, Oracle se gestionan solitos, claro que sí.

Ojo, yo no me quejo, gracias a esto uno puede estar el verano de vacaciones que en algún momento encuentras trabajo sin demasiado problema, porque para los que somos... El otro día me decía el CISO de una empresa del copón en España, porque un compañero mío dejaba de trabajar en el proyecto, que él nunca se despedía definitivamente de la gente. No somos muchos, en algún momento nos seguiremos encontrando, ya sea trabajando o en eventos.

 

[WRC]

Lo que veo es que trabajáis poco. Independientemente de las siglas...

 

[Tim]

Lo que veo es que trabajáis poco. Independientemente de las siglas...

Somos foreros, trabajamos por hobby.

 

[TheReeler]

Estudies lo que estudies de informática, te van a enseñar a programar. Algo, así sea como yo que llevo 20 años sin picar una línea, has aprendido en un momento.

Pero da igual. Hasta ahora, desarrollo hacía su software e IT lo implantaba siguiendo las instrucciones que les decían. IT ya se encargaría de la seguridad, redes, alta disponibilidad... Una parte no sabía lo que hacía la otra, aunque en IT siempre es más fácil entender a los desarrolladores, porque todos hemos estudiado lo mismo aunque luego los caminos fuesen en sentidos distintos.

No te lo crees ni tú. Un desarrollador está tan lejos de conocer los detalles que tú manejas al día a día en IT como tú de saber bien lo que hace y el cómo un desarrollador. En serio, ya sé que piensas que no es así, pero es así.

He tenido en mi equipo de Desarrollo a gente que venía de IT y se han dado semejante hostia que se le ha visto hasta el hueso. E insisto, parte de lo que dices es así, pero pasa en ambas direcciones.

Sea como fuere, sigo sin que me solucionen (solucionéis) los problemas para que pueda pueda funcionar un sistema que proporciona un servicio. La infraestructura será la leche en vinagre... ya lo puede ser, que mientras no funcione lo básico, es tan inútil como no tener nada.

Claro que cuando empiezas algo en la actualidad desde cero quizá lo diseñes de forma distinta, pero vuelvo a la base de que cuando trabajas también con elementos IoT, lo que no puedes hacer es dejarlos sin servicio porque ahora AZ trabaja de otra forma.

Me deja alucinado como un entorno de servicios tan potente y puntero, siga sin tener un servicio MQTT para NBIoT... lo que para mí dice ya mucho, eh? "Móntate una máquina virtual con Mosquitto" me dijeron una vez... santos cojones, eso ya lo tengo en otro cloud, para eso no necesito migrar absolutamente nada, porque no me ofreces ventaja alguna, cero.

 

[Miguel_Angel]

Ver el archivo adjunto 51963

Ya que hablamos de Azure, un ejemplo sencillo. Desarrollo y Sistemas han de trabajar, en parte, en equipo. Es donde se cruzan las flechas.

Los desarrolladores solamente conocen la parte de la izquierda. Los de Sistemas los de la derecha. Un buen coordinador (poned aquí el nombre en inglés más rimbombante que se os ocurra) ha de estar en el punto intermedio. Sabiendo de ambos mundos y poniendo cordura. ¿Cuál es el primer problema? Que el 99,99% de la gente no sabe de Sistemas. Eso es algo histórico. Y sigue igual, como ya comenté de la gente que sale de la facultad. Así que normalmente ese rol lo hace alguien de desarrollo. Y, por tanto, obvian todo lo que hay a la derecha. Directamente no se gestiona. Error gravísimo de cara a la seguridad de la empresa, entre otras cosas.

DevOps es construir una casa. Los que hacen la estructura no saben de fontanería. Los fontaneros no saben de electricidad. Y así con todo. Pero hay una gente en medio haciendo que ese flujo funcione. No se ha inventado la rueda con DevOps, hay muchas otras disciplinas del ser humano que ya trabajan así. Se llama coordinar. Se llama ser jefe de obra, por ejemplo. Un jefe de obra coge los planos del arquitecto y hace que la casa se construya. Coordina a todos, para que cuando un lado necesite una cosa del otro, sea ágil.

Jefes de obra hay muchos. Porque albañiles que sepan de todo hay muchos. Así que encontrar a especialistas que sepan asumir esa tarea es más fácil. Pero en informática, y a la pregunta de qué es la otra parte me ciño, no. La gente de desarrollo no sabe qué es lo otro. No lo han visto delante jamás. Por tanto es imposible que sepan coordinar. Lo que se hace es quedarse con una parte, Dev, y la otra asumir que el Cloud funcione solo.

Este grafico que has puesto es mas o menos parte de lo que hacen los desarrolladores en la empresa en la que trabajaba. De hecho, crearon todas las partes de Integracion y Seguridad tambien.

Me da la sensacion que "Sistemas" es lo que estoy estudiando ahora en dos de las asignaturas, que se llaman: "Computer Architecture Operating Systems and Networks" y "Distributed Systems"

 

[Tim]

No te lo crees ni tú. Un desarrollador está tan lejos de conocer los detalles que tú manejas al día a día en IT como tú de saber bien lo que hace y el cómo un desarrollador. En serio, ya sé que piensas que no es así, pero es así.

He tenido en mi equipo de Desarrollo a gente que venía de IT y se han dado semejante hostia que se le ha visto hasta el hueso. E insisto, parte de lo que dices es así, pero pasa en ambas direcciones.

Me expresé mal. Yo tengo cero idea de programación. Pero... en algún momento supe. Porque todos damos programación al estudiar. Para luego estar en medio de unos y otros, lo tengo más fácil que el que solamente desarrolló, porque la otra parte le suena a chino.

Ahora, lo de Azure y el problema que tienes... la culpa no es de Azure, es de quien decidió mover las cosas a un sitio sin haber mirado si se podía hacer todo
¿Has propuesto a tu empresa coger el puesto del jefazo ese que tomó la decisión y cobra mucho más sin tener puñetera idea?

 

[Tim]

Este grafico que has puesto es mas o menos parte de lo que hacen los desarrolladores en la empresa en la que trabajaba. De hecho, crearon todas las partes de Integracion y Seguridad tambien.

Me da la sensacion que "Sistemas" es lo que estoy estudiando ahora en dos de las asignaturas, que se llaman: "Computer Architecture Operating Systems and Networks" y "Distributed Systems"

Para que te hagas una idea, Kubernetes saca actualizaciones más o menos cada 2 ó 3 meses. Y solamente dan soporte a las x últimas. Montas algo y en un año está fuera de soporte. Para esto hace falta gente, que no hay. Es complicado el tema.