El abismo de tux

Del sitio web de Jakarta EE se puede extraer la siguiente definición:

Jakarta EE brinda a los desarrolladores un conjunto integral de especificaciones abiertas y neutrales para el proveedor que se utilizan para desarrollar aplicaciones Java modernas y nativas de la nube desde cero.Con Jakarta EE, los desarrolladores y consumidores de tecnología pueden estar seguros de que cuentan con las mejores tecnologías para desarrollar aplicaciones de misión crítica nativas en la nube.Y pueden basarse en décadas de experiencia de los desarrolladores de Java para trasladar las cargas de trabajo existentes a la nube.

¿Qué significa esto realmente para los desarrolladores?

Uno de los puntos más fuertes de ser un desarrollador de Java es el ecosistema . En principio, el desarrollador Java puede elegir entre diferentes proveedores de JVM, frameworks, bibliotecas y entornos de ejecución. Esta ha sido la situación desde la era de Sun Microsystems y hay diferentes frameworks para diferentes necesidades, por ejemplo, si queremos crear una API REST con Java, la primera selección debe ser entre:

• Microframeworks que proporcionan un modelo de programación imperativo y comunicaciones HTTP como SparkJava o Javalin
• Frameworks «opinionated» integrales con su propia mentalidad y forma de hacer las cosas como Armeria o Akka
• Frameworks generalistas de extremo a extremo basados ​​en programación declarativa (anotaciones) y convenciones sobre configuración, como Spring Boot o Dropwizard

Con esto en mente, un desarrollador de Java normal no puede conocer todos los aspectos particulares de cada framework, por lo tanto y en muchas situaciones, su conocimiento sobre una solución no es transferible en absoluto a otras soluciones a pesar de que ambas soluciones son Java .

Esto último no es necesariamente bueno o malo, pero sin la existencia de especificaciones la programación en Java seria el viejo oeste, donde cada creador de frameworks y entornos de ejecución tendría una forma única y diferente de hacer su producto.

Siendo así, en 1998, Sun Microsystems creó el Java Community Process, una organización de estándares cuyo objetivo es proporcionar un conjunto común de especificaciones técnicas para Java Core (J2SE), Java Micro (J2ME) y Java Enterprise (J2EE). Trasladandonos al día de hoy J2EE se convirtió en Java EE, y algunos años más tarde el proceso de Java EE fue donado a la Fundación Eclipse , donde nació Jakarta EE.

Dentro de Eclipse, los proveedores de software (comunidades o empresas) podrían tomar (o proponer) una especificación, con el objetivo de tener bases técnicas comunes para definir una «forma empresarial Java» de hacer las cosas.

Un «producto» de especificación es principalmente (pero no exclusivamente) cuatro cosas: 1. Un subproyecto a cargo de la especificación, básicamente una comunidad compuesta por partes interesadas, 2. La definición de la especificación (documentación al respecto), 3. Un conjunto de Java APIs y 4. Un conjunto de pruebas de compatibilidad para validar eventuales implementaciones (TCK).

Cómo se ve Jakarta EE en la vida real

Tomemos una de las especificaciones Jakarta EE más populares, la especificación para la persistencia de objetos Java -es decir, Jakarta Persistence o JPA- .

La definición textual es:

Jakarta Persistence define un estándar para la gestión de la persistencia y el mapeo de objetos/relaciones en entornos Java®.

Como probablemente estén adivinando, esta especificación tiene (al menos) los cuatro elementos descritos anteriormente, siendo:

1. Una comunidad que dirige la especificación
2. La definición de especificación
3. Un conjunto de API de Java
4. Un TCK

Posteriormente o durante la creación de la especificación, las comunidades y empresas crean bibliotecas y/o productos Java compatibles con esta especificación, en este momento Jakarta Persistence 3.1 tiene dos implementaciones:

1. EclipseLink (Eclipse)
2. Hibernate (Red Hat)

En términos prácticos, esto significa que tanto EclipseLink como Hibernate son bibliotecas que proporcionan el código fuente para satisfacer el objetivo de Jakarta Persistence, se prueban contra TCK y tienen un comportamiento predecible donde su conocimiento sobre Jakarta Persistence funciona en ambas bibliotecas. Si el desarrollador Java decide permanecer en la especificación, su código será portátil entre implementaciones porque se utilizan igual, con las mismas anotaciones, las mismas interfaces Java y el mismo estilo de programación.

Al mismo tiempo, cada proyecto proporciona capacidades adicionales, como ser compatible con algún caché en particular, por ejemplo, Infinispan e Hibernate , o tener funciones adicionales para algunas bases de datos en particular, por ejemplo, EclipseLink y Oracle . Si se decide utilizar las capacidades adicionales, es probable que el código Java no sea portátil entre las implementaciones, pero aún así tendrá la forma y el estilo empresarial de hacer las cosas.

Colecciones de especificaciones y entornos de ejecución certificados

Algunas especificaciones de Jakarta son más populares que otras y, lo que es más importante , no todas las comunidades o empresas de Java adoptarán todas las especificaciones.

Por ejemplo, tanto Spring Boot como Micronaut ofrecen capas de datos de abstracción sobre Jakarta Persistence, pero cada uno tiene su propia forma de definir APIs REST ( Spring , Micronaut ).

Por otro lado, si una empresa o comunidad determinada decide adoptar completamente Jakarta EE, puede crear productos certificados con los perfiles de Jakarta EE, siendo estos :

• Jakarta EE Core: ofrece un conjunto minimalista de especificaciones para la creación de servicios REST
• Jakarta EE Web: Ofreciendo un conjunto de especificaciones para crear aplicaciones Web
• Jakarta EE Full: Ofreciendo un conjunto completo de especificaciones para productos que necesitan ofrecer un conjunto sólido de características para cualquier tipo de aplicaciones Java Enterprise

Una vez más, un producto dado podría apuntar al mínimo para cumplir con Jakarta EE Core, pero aún así ofrecer muchos extras con su propia mentalidad y no necesariamente compatible con Jakarta EE Full, como Quarkus que probablemente va a certificarse contra Jakarta EE 10 core.

Así mismo, no todos los entornos de ejecución son iguales, si damos un vistazo rápido a implementaciones compatibles vamos a encontrar diferentes categorías, como:

Entornos para la creación de microservicios modulares sobre FastJars, Docker o Kubernetes:

• OpenLiberty (JakartaEE 10 Core)
• Wildfly Bootable Jar (Jakarta EE 10 Full)

Entornos para la creación de UberJars independientes sobre Docker o Kubernetes:

• Payara Micro (JakartaEE 10 Web)
• Apache TomEE (Jakarta EE 9.1 Web)

Servidores de aplicaciones completos

• Oracle WebLogic (Jakarta EE 8 Full)
• Eclipse Glassfish (Jakarta EE 10 Full)
• JBoss EAP (Jakarta EE 8 Full)

¿Cuál es mejor?

Como todo en TI, esto depende de la necesidad.

Personalmente tiendo a preferir Payara si necesito un servidor independiente, principalmente porque tengo considerable experiencia en Glassfish. Además, si necesito distribuir una aplicación simple en un fatjar, tiendo a usar Payara Micro o Apache TomEE .

Si necesito una arquitectura de microservicios, probablemente usaré Quarkus o Helidon .

Si necesito una función lambda, Quarkus seguramente.

Las pruebas unitarias y de integración son la base de una buena cultura TDD para la implementación de automation testing, las cuales no son siempre utilizadas por su relativa dificultad en configuración de las herramientas.

En esta serie exploramos la creación de pruebas utilizando Java (11) como lenguaje de programación y Jakarta EE (9) sobre Payara para explorar su correcta implementación.

Como primer capitulo discutimos que es la gestión de calidad del software:

Y posteriormente discutimos que tipos de pruebas de software existen:

Adentrados en Java, discutimos como implementar correctamente pruebas unitarias con JUnit 5 y Java 11:

Y discutimos la importancia o utilidad de los mocks via Mockito:

Iniciamos la cuesta final creando tests de integración con Arquillian, Jakarta EE 9 y JUnit 5:

Incrementamos la dificultad creando una API REST (CRUD) sobre MySQL:

La cual probamos posteriormente en tres tipos de bases de datos: 1- Real, 2- En memoria (H2), 3- Real sobre Docker via Testcontainers (MySQL):

Recientemente alguien me hizo esta pregunta via Twitter. Y la verdad es que me la han hecho varias veces y me di cuenta que no está documentado el proceso, al menos no en español.

¿Que es un Java Champion?

Primero debemos establecer que es un Java Champion. De acuerdo a una traducción liberal desde el sitio oficial de Java, un Java Champion es:

El programa Java Champions consta de un grupo único de expertos en tecnología Java y líderes comunitarios patrocinados por Oracle. Los Campeones de Java provienen de una amplia muestra representativa de la comunidad de Java. Son líderes, personas influyentes y habilitadores que ayudan a aumentar el tamaño de la comunidad Java. Los campeones de Java están activos de muchas maneras, como participar activamente en proyectos de Java, interactuar con las comunidades de grupos de usuarios de Java, hablar en conferencias, crear contenido, enseñar a otros desarrolladores, fomentar la participación inclusiva y mucho más.

Son luminarias técnicas y comunitarias; algunos son ingenieros o arquitectos de Java que son relativamente hábiles y tienen mucha experiencia, o son constructores de comunidades que se toman el tiempo para construir relaciones personales duraderas que van más allá de la programación. Los campeones de Java tienen una mentalidad independiente y son creíbles, y encarnan las mejores virtudes de la comunidad de Java, incluida la honestidad, la dedicación y la sinceridad.

Los Java Champions también pueden defender o influir en otros desarrolladores a través de sus propias actividades profesionales (a través de consultoría, enseñanza, redacción, oratoria, etc.). Tienen la oportunidad de proporcionar comentarios e ideas independientes y constructivos sin una agenda competitiva que ayudarán a Oracle a seguir impulsando Java. Este intercambio puede ser en forma de discusiones técnicas y / o actividades de construcción de comunidad con el Equipo Java de Oracle.

Oracle

De este párrafo podemos extraer al menos cinco criterios que son evaluados:

1. Los Java Champions tienen experiencia en Java y liderazgo en comunidades Java
2. Los Java Champions crean proyectos importantes y/o contribuyen a proyectos Open Source
3. Los Java Champions son independientes y NO pueden trabajar para Oracle
4. Los Java Champions enseñan a otros Java
5. Los Java Champions deben ser buenas personas

Segun me han comentado «los fundadores» el programa originalmente pertenencia a Sun Microsystems, fue creado con el objetivo de establecer una mejor comunicación entre Sun y la comunidad Java, con esto Sun pretendia conocer mejor las necesidades de los desarrolladores y sobre todo hacerlo de forma más transparente.

El programa funciona como un premio al cual accedes luego de demostrar esos criterios, es decir, una vez dado solo lo puedes perder por tres razones:

1. Decides retirarte voluntariamente
2. Vas a trabajar para Oracle
3. Hiciste algo muy malo

Al ser un premio y luego de ver varios procesos de selección, puedo decir que el programa es bastante estricto en los criterios.

¿Que NO es un Java Champion?

Un Java Champion no es lo siguiente:

• Una certificación: Para esto Oracle tiene sus propios programas de certificación Java
• Una prueba de que eres el mejor en Java: Probablemente la mayoría de los Java Champions sean buenos en Java pero no necesariamente «el mejor»
• Un trabajo: El programa es 100% comunitario y a excepción de algunos regalos que recibes, no tienes una asignación monetaria de Oracle

¿Como alguien se convierte en Java Champion?

Por lo general y con el pasar de los años, la actividad que un desarrollador Java tenga en pro de la comunidad se nota y este es el primer paso para convertirse en JC, contribuir genuinamente con la comunidad Java.

El programa Java Champion funciona a través de sponsors, un JC existente puede proponerte como Java Champion si te considera apto para participar y tu trabajo ha impactado lo suficiente a la comunidad global Java. A lo interno cualquier JC puede crear una nominación incluyendo evidencia en los cinco criterios anteriormente descritos y puede ser apoyada por más de un sponsor. Luego la nominación es sometida a una votación donde la nominación se acepta o rechaza.

¿Que beneficios trae ser Java Champion y porqué alguien quiere participar del programa?

Como mencioné anteriormente, ser Java Champion es un premio y no un trabajo, por lo que básicamente ganas prestigio y también una nueva responsabilidad.

Personalmente el ser Java Champion me ha dado cinco beneficios directos:

1. Tener un mejor contacto con las personas que hacen Java y contribuir con opiniones independientes a las plataformas que me han dado de comer por tantos años
2. Oportunidades laborales diversas
3. De tanto en tanto Oracle envía algunos «perks» como ropa personalizada con el logo de Java
4. Hay empresas como JetBrains, Pluralsight, Packt que tienen programas de apoyo a la comunidad de desarrolladores. Por lo que entre otras cosas he recibido licencias de IntelliJ, libros para revisión, cursos gratis, créditos en Oracle Cloud
5. Conocer el mundo mediante mi trabajo o participando en conferencias como expositor (muchas veces con gastos pagados) y hacer nuevos amigos

En el lado «negativo», me di cuenta que necesitaba ser más prudente con mis opiniones y actuar en Internet porque de pronto mucha más gente te sigue por el contenido técnico y sabe quien eres. Es parte de crecer supongo.

¿Como me convertí en Java Champion?

En su momento varios amigos que conocí en la comunidad de Java en Español se acercaron a mi para preguntarme si tenia interes en participar, sinceramente nunca fue mi intención convertirme en Java Champion porque yo ya creaba contenido comunitario por diversión desde el inicio de este blog.

Sin embargo algunos criterios que creo que pesaron en el programa fueron las siguientes:

• Contribuir a mantener activo GuateJUG y JConf
• Escribir periódicamente tutoriales aca y en otros sitios como DZone
• Contribuir código en diversos proyectos Open Source
• Participar como ponente en diversas conferencias grandes como Java One, TDC, Devnexus
• Tener más de 10 años de experiencia en Java y estar certificado
• Participar como tutor en varios MOOC de Java
• Haber participado en un proyecto ganador del Duke’s Choice Award (el Oscar de Java)

En resumen, me gusta Java y siempre difundia lo que voy conociendo de la plataforma para que otros aprendan.

Va a sonar tonto pero en el principio de los tiempos, yo aprendí Java gracias a un bootcamp que se dio en la Universidad de San Carlos de Guatemala, y empecé a promover Java porque en ese entonces estaba en la onda Linuxera y no queria trabajar en .net/Windows (el más popular en mi país en ese entonces).

¿Vale la pena dedicar tanto trabajo para ser Java Champion?

La verdad es que depende de cada quien, yo conozco bastantes profesionales que son excelentes en Java y probablemente nunca expongan su trabajo al exterior o simplemente no les interese la comunidad Java, es algo común y sobre todo respetable.

En mi caso el ser Java Champion no fue algo que busqué sino una consecuencia de algo que yo ya hacia, crear contenido técnico en la plataforma que más me gusta trabajar y lo hago con gusto porque es uno de mis pasatiempos. Probablemente haria lo mismo aunque nunca me hubieran nombrado Java Champion.

Quiero ser Java Champion pero estoy en <<X>> país y siento que es para gringos

Yo estoy en Guatemala, al fondo de la tabla en todo, si yo pude cualquiera puede.

Continuando con una tradición que he ejecutado en 2020 y 2021, iniciare el año con mis predicciones acerca del ecosistema de la Java Virtual Machine. He visto que los post de años anteriores fueron bastante certeros entonces espero que este año no sea la excepción.

Spring impulsara a GraalVM Native

Como lo mencioné el año pasado, Spring presentó en 2021 su versión enfocada en compilación AOT (de la cual he hablado a detalle en un vídeo). Aunque Quarkus, Micronaut y Helidon ya destacaban en el frente AOT, debemos recordar que Spring sigue al día de hoy como el #1 en lo que respecta a frameworks Java.

El hecho que Spring impulse a GraalVM Native también debiera acelerar la aparición de bibliotecas reflectionless para que sean compatibles de forma «fácil» con la compilación nativa proveida por GraalVM Native, esto es genial para el ecosistema ya que no todos usamos Spring pero nos beneficiamos :).

Si aún no han experimentado con GraalVM Native, seguramente lo haran con Spring.

El fiasco de log4j se convertirá en FUD a Java

A menos que vivan bajo una piedra, si viven dentro del ecosistema de Java ya saben que hubo un gran agujero de seguridad en la biblioteca log4j, la cual permitió entre otras cosas ejecución remota de código, obteniendo así la mayor calificación de riesgo.

No fueron pocos los medios que reportaron su descubrimiento, incluso medios no enfocados en programación. De este episodio saco dos cosas:

• Me parece impresionante como la gente declara a Java muerto, cuando al mismo tiempo un error en una biblioteca afectó a medio mundo. Incluyendo lugares donde uno no lo imagina como en el hardware de Cisco, básicamente la carretera de Internet.

• Este error pudo pasar (y ya pasó) en otros ecosistemas, pero por lo extendido que está el uso de Java ha servido para propagar FUD al respecto de la plataforma y el lenguaje, sorprendente si se considera que el error fue parchado en tiempo record.

Debo resaltar que aunque el parche fue lanzado de forma inmediata, el origen de la mala reputación van a ser aquellos despliegues desatendidos y sin actualizaciones, aplicaciones con malas prácticas y poco control de dependencias. Una pena pero es lo que hay. Esto también lo resaltó el director de la NSA, pero es más fácil decir «me hackearon por usar Java vamonos a Elixir».

The log4j vulnerability is a significant threat for exploitation due to the widespread inclusion in software frameworks, even NSA’s GHIDRA. This is a case study in why the software bill of material (SBOM) concepts are so important to understand exposure. https://t.co/GMkEozKdmD

— Rob Joyce (@NSA_CSDirector) December 10, 2021

El ecosistema DevOps Java girara alrededor de Testcontainers, Docker y extensiones basadas en JUnit

Hemos recorrido un largo camino y sin miedo a equivocarme Java (junto a Maven) tienen uno de los mejores ecosistemas para flujos de trabajo DevOps.

Muchos de los conceptos inventados por JUnit (y TestNG) ahora son ubicuos en varios ecosistemas de software. Si han estado lo suficiente en Java probablemente han visto la siguiente evolución

• Cactus
• Embedded EJB
• Arquillian (Mi favorito)

Arquillian a mi punto de vista fue el último gran intento de estandarizar las practicas de integration test en Java Empresarial. Aunque sigue bastante vivo, he empezado a notar que cada framework también incluye su propio entorno de ejecución de tests basado en extensiones JUnit, lo vemos ya en:

• Spring Testing
• Quarkus Testing
• Micronaut Test
• Helidon Testing

¿Porqué JUnit?. JUnit es un estandar de facto para la creación de tests en Java y lo más importante, casi todos los entornos DevOps o CI/CD -e.g. Gihub, Gitlab, CircleCI, Jenkins- utilizan el formato de reportes de JUnit para flujos de trabajo basados en Java.

Uno de los temas pendientes en todos estos frameworks y bibliotecas siempre han sido las bases de datos, a principios de la decada pasada se popularizó el uso de bases de datos en memoria como H2 o Apache Derby, al punto de que en JakartaEE aún es requerido que se incluya una base de datos en memoria en los servidores de aplicaciones.

Aunque en principio los tests sobre H2/Derby son los suficientemente buenos para software creado con JPA, los problemas empiezan cuando queremos validar particularidades de cada base de datos, por ejemplo:

• SQL Nativo
• Índices (o la falta de)
• Diferencias entre mayúsculas y minusculas
• Comportamiento de pool de conexiones
• Reactividad y drivers reactivos (o pseudo-reactivos)

Esto ha impulsado la adopción de Testcontainers (mi biblioteca favorita de 2021), que a grandes rasgos nos permite (de nuevo mediante JUnit) ejecutar contenedores Docker para desplegar o complementar nuestra aplicación, aprovisionar bases de datos de pruebas, o lanzar cualquier otro servicio que esté disponible como contenedor Docker.

Esta revolución a mi parecer inició con Arquillian Cube, pero Testcontainers ejecutó de forma más simple y funciona en cualquier entorno, no solo entornos basados en CDI.

Se detendrá la proliferación de Java Virtual Machines

Con el lanzamiento de Java 17, Oracle cambió nuevamente la licencia de SU JVM (aka HotSpot) la que de acuerdo a estadísticas propias, es la que la mayoría de la gente sigue usando.

Aunque siempre vale la pena leer la letra pequeña, lo cierto es que Oracle brinda más opciones para utilizar HotSpot de forma gratuita y para mucha gente esto es suficientemente bueno como para ya no plantearse una alternativa, siendo así deberíamos ver la muerte de algunas «distros Java».

¿No sabias que existen otras distros Java?, siempre es buena idea consultar la tabla de foojay, a mi parecer la más completa

MicroProfile se alineara más a CNCF

La «otra» gran alternativa a Spring es MicroProfile, aunque su adopción seguramente es menor, ha sido fuertemente impulsado por la popularidad de Quarkus.

Dicho esto, recordemos que el paso del espacio Cloud Native lo marca la Cloud Native Computing Foundation, y aunque existen esfuerzos para tener un punto central Cloud Native en el ecosistemas de Java, el ecosistema CNCF ya es lo suficientemente grande y maduro como para aceptar que las herramientas Java se tienen que alinear si quieren sobrevivir en un mundo cada vez más serverless y Kubernetico.

Esto la verdad no es necesariamente malo y en esta línea vemos como la apuesta de Jakarta EE es cada vez más Cloud Native y cada vez menos a lo que estábamos acostumbrados (app servers tradicionales, instalaciones on premise).

Por cierto no se pierdan mi curso gratuito de MicroProfile, directamente en el sitio del proyecto :).

Las «emociones» de la JVM se centraran en Loom, Panama y un poco menos en Valhalla

El cambio a Java modular fue por decirlo de una forma amable «doloroso», pero los que seguimos el carrito de lanzamientos hemos visto como las innovaciones llegan de forma más rápida a Java.

Luego de superar la velocidad de lanzamiento, migraciones de Java 8 a 11 y de 11 a 17 en algunos casos, lo que nos queda a los desarrolladores Java es aprovechar este flujo constante de actualizaciones, en esta línea veo que lo más emocionante viene de tres frentes:

• Los virtual threads con Project Loom
• La ejecución nativa de código vía Project Panama
• La reducción y simplificación de memoria vía Project Valhalla

Project Amber (mejoras en el lenguaje) ha presentado bastantes innovaciones y nos na tenido «tranquilos», pero lo realmente impresionante serán las posibles mejoras en escalabilidad proveidas por estos tres proyectos, desde mi trinchera les deseo muchos éxitos a los arquitectos de Java

Bienvenido 2022

Si llegaron hasta acá les deseo un 2022 lleno de Java, no tan lleno de pausas en el Heap y no olviden que estoy en muchas redes sociales:

• Twitter
• Linkedin
• Youtube
• GitHub
• Last.fm
• Facebook

Esta es una experiencia de la certificación CKA por si alguien tiene dudas del proceso.

¿Que certificaciones para Kubernetes existen?

Partamos del hecho que Kubernetes en este momento es un proyecto Open Source donado por Google hacia la Cloud Native Computing Foundation. Al ser un producto Open Source pueden existir no una sino varias ofertas comerciales (que las hay) y en esa línea también diversas certificaciones, por lo que encontramos dos tipos:

Certificaciones de la implementación neutral (evaluadas por The Linux Foundation):

• Certified Kubernetes Administrator (CKA)
• Certified Kubernetes Application Developer (CKAD)
• Certified Kubernetes Security Specialist (CKS)

Certificaciones de una implementación en especifico, por ejemplo:

• Red Hat Certified Specialist in OpenShift Administration
• SUSE Certified Administrator in SUSE Rancher 2.5
• VMware Certified Master Specialist – Cloud Native 2021

En el caso de las certificaciones neutrales se recomienda tomar CKS y CKA si su principal rol es SRE/sysadmin y CKAD si lo que pretenden hacer es desplegar aplicaciones Cloud Native.

¿Porqué obtener la certificación?

Las certificaciones son una eterna polémica en TI, siendo así establezcamos que para desempeñar un trabajo bien se necesitan dos cosas:

• Experiencia (que viene con el tiempo y la práctica)
• Conocimiento (que viene con el estudio)

Y el conocimiento en TI generalmente se demuestra en tres formas:

• Diploma universitario
• Certificaciones
• Ejecución de pruebas técnicas

Tanto las certificaciones como los diplomas universitarios son a larga la validación de un tercero sobre el conocimiento, o sea una prueba técnica anticipada. Estas evaluaciones se realizan sobre una serie de tópicos generales (Universidad) o de una tecnología especifica (Certificaciones), la certificación o diploma universitario tendrá mas prestigio de acuerdo a quien la emite. Para poner un ejemplo no es lo mismo obtener la certificación Java de Oracle que de un proveedor de Mooc.

En otras palabras al obtener la certificación obtienes el sello de aprobación de The Linux Foundation de que sabes Kubernetes.

¿Porqué obtuve yo la certificación?

TL;DR Ver si me perdía de algo, también pereza de estar demostrando a cada rato que si se y pasé con 10 matemáticas, y es una forma monetaria de contribuir con The Linux Foundation obteniendo un beneficio, casi una teleton computina.

Siempre me he descrito como un desarrollador de software que se sabe uno que otro tango en Linux porque lo aprendió en la Universida’ de la Vida. Actualmente me dedico a consultorías con instituciones de banca, industria y gobierno, y en su mayoría mi equipo y/o yo participamos en desarrollo, implementaciones y acompañamiento en definición y arquitecturas de software tradicionales, Cloud Native y cualquier otro termino de marketing que surja en el futuro.

En el corto plazo y como ya he comprobado con otras certificaciones, son un atajo para conseguir contratos y brindar respaldo a los clientes, pero lo más importante evaluar si mi conocimiento está al nivel adecuado de mi experiencia, en Kubernetes en este caso (+/- 4 años).

Dificultad

Para mi la certificación más difícil que he tomado ha sido la certificación Oracle Certified Professional, Java SE 8 Programmer y sigue ahí. Si esa certificación es un 10, ubicaria CKA en un 7.

El examen de certificación tiene una duración total de 2 horas donde se realizan 17 tareas prácticas en al menos 6 clusters diferentes de Kubernetes, con una nota mínima de aprobación de 66%. La ejecución de estas tareas se utiliza una terminal dentro de un navegador Web (Chrome) la cual es bastante incomoda. Como estamos en COVIS toda prueba es remota con la camara encendida todo el tiempo y haciendo screensharing.

Durante el examen te permiten ver la documentación oficial de Kubernetes y Helm porque es imposible memorizar cada uno de los aspectos, pero al ser contra-reloj si no sabes que buscar estas frito (en esta línea recomiendo tener bookmarks).

Las tareas incluidas en mi examen fueron actualizaciones de clusters, troubleshooting, apertura de servicios al exterior mediante NodePorts e Ingress, backup de etcd, definición de políticas de seguridad y red, creación de volumenes de almacenamiento e instalación de un operador, pero puede variar.

Diria que el examen es bastante justo y refleja tareas básicas del día a día de un administrador Kubernetes, pero por mi experiencia creo que las personas lo fallan por los siguientes motivos:

• No tienen buenas nociones de Linux
• Hay que leer bien las instrucciones
• Hay que darse cuenta en que cluster se está trabajado en cada pregunta, si no Ixcamic
• Es contra reloj y a cada rato te dan advertencias que ya se te va ir la moto
• Solo está permitida la consulta de recursos en dominios de internet aprobados (documentación de Kubernetes, Helm) y si no haces caso te anulan el test
• Hay que saber usar bien vi o nano

¿Como me preparé para el test?

Esta sección es un poco difícil porque muchos recursos los fui usando durante el transcurso de los años pero me parecen útiles.

Antes de tomar la prueba el candidato debe de tener buena experiencia en Linux, no a nivel de compilar tu propio Kernel pero si un buen manejo de la terminal, sed, grep, awk, more, less, find, en otras palabras ser un buen Linuxero terminalero, en su momento hace muchos años en una galaxia muy muy lejana yo aprendí Linux por mi cuenta leyendo Linux Bible y también en la Universida’ de la Vida.

Para aprender Kubernetes en su momento compré el libro The Kubernetes Book de Nigel Poulton, es un buen libro introductorio y a excepción de la sección de seguridad (bastante incompleta) es un buen recurso que siempre recomiendo.

Aprovechando que tengo acceso a Oracle Cloud via Oracle Grounbreakers Ambassadors, me armé «a mano» via kubeadm un Cluster con dos nodos en OCI, esto lo pueden hacer también con Oracle Cloud Free Tier, con el objetivo de tener un entorno de pruebas. Muchas personas también recomiendan el tutorial Kubernetes the Hard Way de Kelsey HIghtower pero sinceramente eso solo lo hice una vez cuando empezaba a aprender Kubernetes, ante ese tutorial instalar Gentoo es fácil.

Si sumo los ratos libres donde iba haciendo mis pruebas probablemente ejecuté unas 20 horas de pruebas desperdigadas en 37 dias, la edad de mi clustercito de pruebas:

Al inicio de mi jornada compré el examen para tener una fecha límite y la oferta tenia acceso a Killer Shell con dos intentos. El primero sinceramente lo ejecuté sin humildad y lo perdí, pero me sirvió para identificar cosas no hago tan a menudo para reforzar esos conceptos, siendo en mi caso:

• Definición de políticas de red
• Backups de etcd
• RBAC
• Sidecars manuales
• Edits de despliegues en línea de comandos

Al buscar recursos recordé que como Java Champion tengo acceso a Pluralsight VIP Subscription y durante esas 20 horas además de hacer mis pruebas, tomé el MOOC Configuring and Managing Kubernetes Security de Anthony Nocentino para ponerme a punto, y al intentar de nuevo pasé en killer.sh y posteriormente pasé el examen al primer intento (el examen trae dos intentos). La verdad por conocimiento hubiera querido tomar más MOOCs porqué pluralsight tiene un path completo de Kubernetes, pero soy una persona muy ocupada actualmente y:

Al final te dan este diploma:

GraalVM es una de las innovaciones que más ha impactado el ecosistema de la JVM, incluidos lenguajes como Kotlin, Scala, Clojure o Groovy. Su modulo Native Image permite la creación ejecutables «self-contained», «AOT» y dependientes de sistema operativo que presentan menor velocidad de arranque y consumo de memoria.

En esta charla exploramos la creación de herramientas de línea de comandos con Kotlin y GraalVM Native, comparamos la herramienta con Kotlin Native y vemos la creación de una herramienta en línea de comandos, con Kotlin, PicoCLI, Maven y GraalVM Native.

Primero exploramos las diferencias entre Kotlin Native y Kotlin con GraalVM Native

Posteriormente hablamos más a fondo de GraalVM y su relación con Kotlin.

Luego, hablamos a detalle de las implicaciones de una Native Image

Por último creamos una herramienta CLI con PicoCLI y Kotlin, comparando el desempeño de la versión JVM versus la versión AOT.

Como de costumbre los slides se encuentran disponibles en slideshare.

Introducción a GraalVM Native para aplicaciones JVM from Víctor Leonel Orozco López

Los microservicios del mundo real utilizan muchas tecnologías además del chasis, como la persistencia de datos e IoC, lo que obliga a los arquitectos de Java a repetir los proyectos de ensamblaje. Desde la experiencia de campo, esta charla expone los beneficios de combinar proyectos como Eclipse JKube, Deltaspike en arquetipos convenientes.

Como de costumbre los slides se encuentran disponibles en slideshare

Iniciando microservicios reales con JakartaEE/MicroProfile y arquetipos de Maven from Víctor Leonel Orozco López

No se pierdan en octubre el curso «desarrollo de aplicaciones empresariales y microservicios con Java«, avalado por el Colegio de Ingenieros de Guatemala y la Facultad de Ingeniería de la Universidad de San Carlos de Guatemala.

En esta charla conjunta con el Colegio de Ingenieros de Guatemala exploramos muchas de las evoluciones que ha tenido Java desde Java 8 hasta Java 17, discutiendo porqué seria interesante actualizar tus versiones de Java.

Índice

• 00:00 – Inicio
• 02:32 – ¿Como se hace Java?
• 12:13 – Desde Java 8
• 17:48 – Java 9
• 26:43 – Java 10
• 35:27 – Java 11
• 38:50 – Java 12
• 49:54 – Java 13
• 51:40 – Java 14
• 58:29 – Java 15
• 01:09:31 – Java 16
• 01:14:01 – Java 17
• 01:18:41 – Anuncio diplomado desarrollo de aplicaciones empresariales y microservicios con Java y preguntas finales

Como de costumbre los slides se encuentran disponibles en Slideshare

De Java 8 a Java 17 from Víctor Leonel Orozco López

Considerando la salida de Java 17, el grupo de usuarios Java de Guatemala aprovechó a diagnosticar cual es el estado del ecosistema en el año 2021.

Abajo se detallan todas las respuestas brindadas por la comunidad guatemalteca pero en resumen:

• Java 8 sigue reinando en Guatemala
• Windows sigue siendo el sistema operativo #1 para programar en Guatemala
• La JVM de Oracle sigue siendo la más usada

Gracias a todos los participantes. los datos se encuentran a disposición en csv y fueron analizados con un notebook de Apache Zeppelin, por si desean realizar sus propios análisis todo esto lo pueden encontrar en GitHub, asi como una página compilada con los mismos datos mostrados acá por si necesitan en algún momento usar una referencia.

Continue reading →