Helm plantillas para los recursos de kubernetes

Ya de por sí tener kubernetes si se usa con archivos que nos definan los recursos de infraestructura es un gran ventaja por que tenemos una forma replicable, usualmente versionada de la infraestructura que nos permite rastrear errores con facilidad. 

Los desarrolladores en general van y siguen automatizando/generalizando más para ganar velocidad y evitar que con la réplica de copiar/pegar se generen errores inesperados en este caso en la definición de recursos de kubernetes.

Es que un problema que puede ser frecuente es tener un recurso desplegado en algún proveedor de nube que debemos definir para un ambiente de desarrollo y para un ambiente de producción, usualmente con pequeñas diferencias como:

• en uno se puede estar usando una url diferente
• tener habilitado un mecanismos de seguridad adicional en producción
• usar un espacio de nombres diferentes
  

Al final es como si tuviéramos un plano del recurso y en puntos específicos quisiéramos definir valores dependendiendo de lo que necesitamos del recurso y esto es lo que permite hacer helm

Una forma de definir plantillas para los recursos de kubernetes que podemos aplicar con diferentes valores usualmente una para cada ambiente pero también una sola plantilla se puede estar usando múltiples veces para un recurso del mismo tipo en el mismo ambiente por ejemplo si un equipo realiza spring-boot.

para definir un recurso de esta manera lo primero es definir un chart que nos permite colocar entre otras cosas un nombre,una descripción, quienes mantienen esta plantilla etc
(Chart.yaml)

apiVersion: v2

name: <the-name>

description: <the description>

version: 1.0.0 # chart version

Luego creamos una carpeta templates y dentro definimos nuestro recurso o recursos de kubernetes con la ubicación de los valores que vamos a definir en otros archivos. incluso podemos colocar condiciones if para que dado que un valor se defina una configuración o no
templates/<uno o muchos archivos>.yaml

{{ .Values.host }} # para obtener valores de la definicion de values que

 tengamos

{{- if .Values.tls.enabled }}

{{- end }} # hay que tener cuidado respetando la indentacion 

nos permite poner definiciones dinamicas solo si es true el 

codigo en el medio entre if y end se agrega 

 

finalmente definimos un archivo de valores que se van a aplicar a nuestros templates
(values-xxx.yaml)

host: dev.example.com

tls:

enabled: false

para instalar esta definición con nuestra plantilla podemos usar el comando(previo a estar conectado a nuestro cluster sea el proveedor de nube o un cluster corriendo en la maquina propia como minikube)

$ helm install -f <whatever-name> values-xxx.yaml .

instalar el nombre que le pongamos el archivo values qué le vamos a aplicar a la plantilla con el . osea chart en el directorio actual
y si realizamos algún cambio sea en las plantillas o en los valores después de haberlo instalado podemos actualizarlo con 

$ helm upgrade -f <whatever-name> values-xxx.yaml .

Otra herramienta en la misma línea de helm es kustomize. helm se recomienda para aplicaciones propias en las que buscamos definir todo mientras kustomize se recomienda cuando vamos a definir despliegue de aplicaciones de terceros a las que solo queremos sobrescribir pequeños detalles con la configuración propia(por ejemplo una url).

Pruebas en el software

Notas del capítulo 11 Testing overview del libro Software Engineering at Google.

Las pruebas hacen parte del desarrollo de software de calida y generan varias ventajas

• Encontrar errores en el código : debido a que no todo sale como se planea siempre
• La refactorización del código : después de hacer el refactor si la funcionalidad no cambia las pruebas deberían seguir pasando
• Abrazar el cambio : hacer cambios sabiendo que no dañamos algo previo
• Generar tiempos de mercado más rápidos : aunque hacer pruebas toma tiempo, este tiempo en proporción a la longitud del proyecto lo hace más robusto
• Generan conocimiento colectivo : el conocimiento de la persona que realizó el codigo sirve como conocimiento colectivo para los futuros desarrolladores, de cómo debe funcionar una parte del sistema e incluso como documentación en algunos casos
  

Especialmente las pruebas automatizadas tiene muchísimo valor por que sin necesidad de que una persona ponga tiempo extra cada vez que se realiza un cambio estas pueden ser recorridas con facilidad , se comenta que en Google en el pasado se le tenía mucha fe a las mente brillantes que hacían las cosas funcionar hasta que los resultados de hacer muchas pruebas y el cambio cultural que se generó en la compañía los llevó a darle una importancia más alta a la pruebas.

El resultado más importante que se comenta de datos en el capítulo es que tienen un sistema llamado GWS encargado de las búsquedas que cada vez que hacían un cambio el 80% de las veces les tocaba devolverlo porque rompían algo, pero luego de una años con una política de pruebas más estricta esta cifra fue reducida a la mitad (esto más relevante aun por que este sistema sufrió cambios importantes y constantes)

Por el cambio cultural se generaron varios escenarios para impulsar a los ingenieros a realizar pruebas entre ellos una inducción a las personas nuevas sobre las virtudes de las pruebas, panfletos sobre pruebas en los baños y competencias entre los equipos en relación a la madurez de estos en el tema de pruebas.

En google es interesante que dividen las pruebas basadas en dos clasificaciones una de estas son las clásicas pruebas unitarias, pruebas de integración y pruebas funcionales. pero la otra hace relación al tamaño de las pruebas vinculado a los recursos que consume esto lo hacen por que es mucho mejor tener pruebas pequeñas que consuman pocos recursos(en tiempo de ejecución, llamados de red, I/O, hilos) que permiten ser recorridas a menudo y rápidamente.

Es tanto así que recomiendan a los equipos tener 80% pruebas unitarias, 15% pruebas de integración y 5% pruebas funcionales, esto es por que las pruebas unitarias pueden ser corridas más a menudo,más rápido y es más fácil corregir los errores si se daña una de estas disminuyendo así el tiempo que los ingenieros deben pasar debugeando código. Por otro lado, tener muchas pruebas de integración puede llevar fácilmente a que el tiempo que toman las pruebas en correr sea demasiado alto y que se deba pasar una mayor cantidad de tiempo debugeando para corregir los errores que se generen en esta pruebas.

hay dos tipos de test problemáticos que google a encontrado los flaky test que son test no deterministas que de repente sin motivo se rompen y/o aveces funcionan al final google cree que estos deben ser arreglados por que afectan negativamente la confianza del equipo en la colección de pruebas y; los brittle test que son test que se rompen con facilidad incluso cuando se toca algo que no debería estar relacionado para estos recomiendan evitar el uso de mocks, probar solamente interfaces públicas que varios equipos usan y validar las entradas y las salidas de los sistemas no cómo estos interaccionan para corregirlos.

Una suite de test robusta puede indicar un diseño robusto del sistema y lo contrario también es cierto al final los test solo deberían cambiar cuando se genera un cambio en una funcionalidad, nuevas funcionalidades y/o bugs deberían crear nuevos test.

El sìndrome de impostor

apuntes del articulo https://dl.acm.org/doi/pdf/10.1145/3437255.

El síndrome de impostor es un tipo de enfermedad que toma relevancia en personas que son capaces profesionalmente pero se perciben a si mismo como que no son lo suficientemente buenos. 

Creo que hasta cierto punto puede ser necesario se entienda que nos falta mucho por aprender mas en la tecnología que puede llegar a ser tan amplia donde se vuelve muy cierto el dicho que entre mas sabemos mas nos damos cuenta que nos falta mucho por saber. 

Pero esto tiene un limite cuando esa duda en las capacidades propias se convierte en un obstáculo para hacer las cosas que se esta en capacidad de hacer, este es precisamente uno de los síntomas del síndrome de impostor una sensación de estar jugando tonto  

Al final tenerlo afecta negativamente nuestra capacidad para realizar una actividad y no tenerlo o superarlo puede aumentar nuestro desempeño por eso creo que es importante reconocer que puede volver peor el síndrome de impostor pero también que alternativas hay para superarlo personalmente o generar cambios organizacionales que permitan a los miembros del equipo a no tenerlo

Puede incrementar y/o empeorar el síndrome de impostor no sentirse valorado por el esfuerzo y el trabajo que se hace

 Puede ayudar a superarlo  dos tipos de cambios unos que se hacen desde lo personal y otros organizacionales(esto implica en algunos casos cambiar ese ambiente o irse a otra organización) :

•  hablar de como se siente con otras personas
•  sentirse necesitado en el trabajo que se hace 
• celebrar los éxitos que se consiguen
• dejar pasar algunas cosas
• tener un entorno que escuche y sea inclusivo (las grandes mentes no piensan igual)

resaltar en este tema del entorno que puede estar relacionado con el acoso sexual y que las organizaciones que quieran evitarlo deben atacar la tolerancia a las acciones de acoso sexual pues este es el mayor elemento predictivo del acoso sexual

 

 

Kubernetes

Kubernetes viene siendo una forma de gestionar la infraestructura de una o varias aplicaciones en varios proveedores de nube como amazon web services, azure o google cloud

Por infrastructura se quiere decir los servicios(aplicaciones stateless o no), trabajos que se repitan cada x tiempo, bases de datos etc. usualmente se invita a gestionar esta infraestructura en kubernetes como código esto por que tiene algunas ventajas entre ellas:

• que el codigo se puede replicar con increible facilidad, si la infra esta como codigo entonces esta puede ser replicada con extremada facilidad.
• que al código se le puede aplicar un sistema de versionamiento como git que permite controlar los cambios que se hacen y retornar a una versión funcional previa si algo se daña

 kubernetes viene a ser parte de un ecosistema mas grande para manipular desde cierto alto nivel aplicaciones que corren en docker o otro(podman etc)

 

Que busca  desde maquinas virtuales(o parecidos como docker) disminuir la incertidumbre en las aplicaciones al darle un ambiente para ejecutarse que se puede replicar y escalar con mayor facilidad.

conozco que kubernetes se usa con archivos de configuracion .yaml del estilo 

apiVersion: v1

kind: Pod

metadata:

name: web-declarative

labels:

site: blog

spec:

containers:

- name: web

image: nginx:1.18.0

 

lo que buscan estos archivos es definir como va ser ejecutada una aplicación en el cluster(el cluster es el nombre que se le da a donde se ejecuta por ejemplo en amazon la torre) de kubernetes. estos archivos se aplican en el cluster con un comando como 

kubectl apply -f <nombre-archivo>

 y apartir de hay kubernetes va mantener una instancia de la aplicacion corriendo(incluso iniciando otra si la primera se cae).

en kubernetes se pueden correr muchos tipos de recursos por ejemplo un recurso Deployment permite que se corran al mismo tiempo varias instancias una aplicacion, aumentando asi posiblemente la disponibilidad. es decir si una aplicacion con los recursos que se le dan solo soporta 500 usos por segundo y llegan 700 usos por segundo se requerirían almeno dos aplicaciones corriendo para que el servicio se pueda seguir entregando.

antes de acabar solo comentar que manejar una aplicacion o ambiente por kubernetes puede ser mas complejo que manejarlo sin kubernetes, hay que evaluar pros y contras en cualquier caso, por ejemplo si se requiere alta disponibilidad, escalamiento, solucionar problemas comunes por ambiente. e incluso con un si evaluar soluciones mas sencillas

kubernetes tiene muchísimas mas cosas, me parece una herramienta muy robusta y de la que toca aprender mucho para sacarle todo el jugo.