Aprende cómo puedes usar CodeReady Containers para configurar la última versión de Openshift Local solo en tu computadora.
Foto de pawel szvmanski en Unsplash En este momento, todos sabemos que el modo de implementación predeterminado para cualquier aplicación que queramos lanzar será una plataforma basada en contenedores y, especialmente, será una plataforma basada en Kubernetes. Pero ya sabemos que hay muchas variantes diferentes de distribuciones de Kubernetes, incluso escribí un artículo sobre eso que puedes encontrar aquí: Algunas de estas distribuciones intentan seguir lo más cerca posible la experiencia de Kubernetes, pero otras están tratando de mejorar y aumentar las capacidades que la plataforma proporciona. Debido a eso, a veces es importante tener una forma de realmente probar nuestro desarrollo en la plataforma objetivo sin esperar un modo de desarrollador basado en servidor. Sabemos que tenemos en nuestra propia laptop una plataforma basada en Kubernetes para ayudar a hacer el trabajo. minikube es la opción más común para hacer esto y proporcionará una vista muy básica de Kubernetes, pero a veces necesitamos un tipo diferente de plataforma. Openshift de RedHat se está convirtiendo en una de las soluciones de facto para implementaciones en la nube privada y especialmente para cualquier empresa que no planea mudarse a una solución gestionada en la nube pública como EKS, GKE o AKS. En el pasado teníamos un proyecto similar a minikube conocido como minishift que permitía ejecutar en sus propias palabras: Minishift es una herramienta que te ayuda a ejecutar OpenShift localmente ejecutando un clúster de OpenShift de un solo nodo dentro de una VM. Puedes probar OpenShift o desarrollarlo, día a día, en tu localhost.
GitHub - code-ready/crc: Red Hat CodeReady Containers is a tool that manages a local OpenShift 4.x cluster optimized for testing and development purposes
Red Hat CodeReady Containers is a tool that manages a local OpenShift 4.x cluster optimized for testing and development purposes - GitHub - code-ready/crc: Red Hat CodeReady Containers is a tool th...
El único problema con minishift es que solo soportan la versión 3.x de Openshift, pero estamos viendo que la mayoría de los clientes ya están actualizando a la versión 4.x, por lo que podríamos pensar que estamos un poco solos en esa tarea, ¡pero esto está lejos de la verdad! Porque tenemos CodeReady Containers o CRC para ayudarnos en esa tarea.
GitHub - code-ready/crc: Red Hat CodeReady Containers is a tool that manages a local OpenShift 4.x cluster optimized for testing and development purposes
Red Hat CodeReady Containers is a tool that manages a local OpenShift 4.x cluster optimized for testing and development purposes - GitHub - code-ready/crc: Red Hat CodeReady Containers is a tool th...
El propósito de Code Ready Containers es proporcionarte un clúster mínimo de Openshift optimizado para propósitos de desarrollo. Su proceso de instalación es muy, muy simple. Funciona de manera similar al modo de distribución anterior de VM y OVA, por lo que necesitarás obtener algunos binarios para poder configurar esto directamente desde Red Hat usando la siguiente dirección: https://console.redhat.com/openshift/create/local Necesitarás crear una cuenta, pero es gratuita y en unos pocos pasos obtendrás un gran binario de aproximadamente 3–4 GB y tu código de firma para poder ejecutar la plataforma y eso es todo, en unos minutos tendrás a tu disposición una plataforma completa de Openshift lista para que la uses.Instalación local de CodeReadyContainers en tu laptop Podrás encender y apagar la plataforma usando los comandos crc start y crc stop.Salida de consola de la ejecución del comando crc start Como puedes imaginar, esto solo es adecuado para el entorno local y de ninguna manera para la implementación en producción y también tiene algunas restricciones que pueden afectarte, tales como:
El clúster de OpenShift de CodeReady Containers es efímero y no está destinado para uso en producción.
No hay una ruta de actualización compatible a versiones más nuevas de OpenShift. Actualizar la versión de OpenShift puede causar problemas que son difíciles de reproducir.
Utiliza un solo nodo que actúa como nodo maestro y trabajador.
Desactiva el Operador de monitoring por defecto. Este Operador desactivado causa que la parte correspondiente de la consola web no funcione.
La instancia de OpenShift se ejecuta en una máquina virtual. Esto puede causar otras diferencias, particularmente con la red externa.
Espero que encuentres esto útil y que puedas usarlo como parte de tu proceso de implementación.
Descubre cómo los Init Containers pueden proporcionar capacidades adicionales a tus cargas de trabajo en Kubernetes
Hay muchos nuevos desafíos que vienen con el nuevo patrón de desarrollo de una manera mucho más distribuida y colaborativa, y cómo gestionamos las dependencias es crucial para nuestro éxito. Kubernetes y las distribuciones dedicadas se han convertido en el nuevo estándar de implementación para nuestra aplicación nativa de la nube y proporcionan muchas características para gestionar esas dependencias. Pero, por supuesto, el recurso más habitual que utilizarás para hacer eso son las sondas. Kubernetes proporciona diferentes tipos de sondas que permitirán a la plataforma conocer el estado de tu aplicación. Nos ayudará a saber si nuestra aplicación está «viva» (sonda de vivacidad), ha sido iniciada (sonda de inicio) y si está lista para procesar solicitudes (sonda de preparación).Ciclo de vida de las sondas de Kubernetes por Andrew Lock (https://andrewlock.net/deploying-asp-net-core-applications-to-kubernetes-part-6-adding-health-checks-with-liveness-readiness-and-startup-probes/) Las sondas de Kubernetes son la forma estándar de hacerlo, y si has implementado alguna carga de trabajo en un clúster de Kubernetes, probablemente hayas usado una. Pero hay ocasiones en las que esto no es suficiente. Eso puede ser porque la sonda que te gustaría hacer es demasiado compleja o porque te gustaría crear algún orden de inicio entre tus componentes. Y en esos casos, confías en otra herramienta: los Init Containers. Los Init Containers son otro tipo de contenedor en el que tienen su propia imagen que puede tener cualquier herramienta que puedas necesitar para establecer los diferentes chequeos o sondas que te gustaría realizar. Tienen las siguientes características únicas:
Los init containers siempre se ejecutan hasta completarse.
Cada init container debe completarse con éxito antes de que comience el siguiente.
¿Por qué usarías init containers?
#1 .- Gestionar Dependencias
El primer caso de uso para utilizar init containers es definir una relación de dependencias entre dos componentes como Deployments, y necesitas que uno comience antes que el otro. Imagina la siguiente situación: Tenemos dos componentes: una aplicación web y una base de datos; ambos se gestionan como contenedores en la plataforma. Así que si los implementas de la manera habitual, ambos intentarán comenzar simultáneamente, o el programador de Kubernetes definirá el orden, por lo que podría ser posible que la aplicación web intente comenzar cuando la base de datos no esté disponible. Podrías pensar que eso no es un problema porque para eso tienes una sonda de preparación o de vivacidad en tus contenedores, y tienes razón: el Pod no estará listo hasta que la base de datos esté lista, pero hay varias cosas a tener en cuenta aquí:
Ambas sondas tienen un límite de intentos; después de eso, entrarás en un escenario de CrashLoopBack, y el pod no intentará comenzar de nuevo hasta que lo reinicies manualmente.
El pod de la aplicación web consumirá más recursos de los necesarios cuando sabes que la aplicación no comenzará en absoluto. Así que, al final, estás desperdiciando recursos en el proceso.
Por lo tanto, definir un init container como parte de la implementación de la aplicación web que verifique si la base de datos está disponible, tal vez solo incluyendo un cliente de base de datos para ver rápidamente si la base de datos y todas las tablas están adecuadamente pobladas, será suficiente para resolver ambas situaciones.
#2 .- Optimización de recursos
Una cosa crítica cuando defines tus contenedores es asegurarte de que tienen todo lo que necesitan para realizar su tarea y que no tienen nada que no sea necesario para ese propósito. Así que en lugar de agregar más herramientas para verificar el comportamiento del componente, especialmente si esto es algo para gestionar en momentos específicos, puedes descargar eso a un init container y mantener el contenedor principal más optimizado en términos de tamaño y recursos utilizados.
#3.- Precarga de datos
A veces necesitas realizar algunas actividades al inicio de tu aplicación, y puedes separar eso del trabajo habitual de tu aplicación, por lo que te gustaría evitar el tipo de lógica para verificar si el componente ha sido inicializado o no. Usando este patrón, tendrás un init container gestionando todo el trabajo de inicialización y asegurando que todo el trabajo de inicialización se haya realizado cuando se ejecute el contenedor principal.Ejemplo del proceso de inicialización (https://www.magalix.com/blog/kubernetes-patterns-the-init-container-pattern)
¿Cómo definir un Init Container?
Para poder definir un init container, necesitas usar una sección específica de la sección de especificaciones de tu archivo YAML, como se muestra en la imagen a continuación:
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo ¡La aplicación está en ejecución! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo esperando a myservice; sleep 2; done"]
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo esperando a mydb; sleep 2; done"]
Puedes definir tantos Init Containers como necesites. Sin embargo, notarás que todos los init containers se ejecutarán en secuencia como se describe en el archivo YAML, y un init container solo puede ejecutarse si el anterior se ha completado con éxito.
Resumen
Espero que este artículo te haya proporcionado una nueva forma de definir la gestión de tus dependencias entre cargas de trabajo en Kubernetes y, al mismo tiempo, también otros grandes casos de uso donde la capacidad del init container puede aportar valor a tus cargas de trabajo.
Los AccessModes de Kubernetes proporcionan mucha flexibilidad sobre cómo los diferentes pods pueden acceder a los volúmenes compartidos
Todas las empresas se están moviendo hacia una transformación, cambiando las cargas de trabajo actuales en servidores de aplicaciones que se ejecutan en máquinas virtuales en un centro de datos hacia una arquitectura nativa de la nube donde las aplicaciones se han descompuesto en diferentes servicios que se ejecutan como componentes aislados utilizando contenedores y gestionados por una plataforma basada en Kubernetes. Comenzamos con los casos de uso y cargas de trabajo más fáciles, moviendo nuestros servicios en línea, principalmente API REST que funcionan en modo de balanceo de carga, pero los problemas comenzaron cuando movimos otras cargas de trabajo para seguir el mismo camino de transformación. La plataforma Kubernetes no estaba lista en ese momento. La mayoría de sus mejoras se han realizado para admitir más casos de uso. ¿Significa eso que la API REST es mucho más nativa de la nube que una aplicación que requiere una solución de almacenamiento de archivos? ¡Absolutamente no! Estábamos confundiendo diferentes cosas. Los patrones nativos de la nube son válidos independientemente de esas decisiones. Sin embargo, es cierto que en el camino hacia la nube e incluso antes, hubo algunos patrones que intentamos reemplazar, especialmente los basados en archivos. Pero esto no es por el uso del archivo en sí. Era más sobre el enfoque por lotes que estaba estrechamente relacionado con el uso de archivos que intentamos reemplazar por varias razones, como las siguientes:
El enfoque en línea reduce el tiempo de acción: las actualizaciones y notificaciones llegan más rápido al objetivo, por lo que los componentes están actualizados.
Las soluciones basadas en archivos reducen la escalabilidad de la solución: generas una dependencia con un componente central que tiene una solución de escalabilidad más compleja.
Pero este camino se está facilitando, y la última actualización en ese viaje fueron los Access Modes introducidos por Kubernetes. El Access Mode define cómo los diferentes pods interactuarán con un volumen persistente específico. Los modos de acceso son los que se muestran a continuación.
ReadWriteOnce — el volumen puede montarse como lectura-escritura por un solo nodo
Representación Gráfica de ReadWriteOnce AccessMode
ReadOnlyMany — el volumen puede montarse como solo lectura por muchos nodos.
Representación Gráfica de ReadOnlyMany AccessMode
ReadWriteMany — el volumen puede montarse como lectura-escritura por muchos nodos
Representación Gráfica de ReadWriteMany AccessMode
ReadWriteOncePod — el volumen puede montarse como lectura-escritura por un solo Pod. Esto solo es compatible con volúmenes CSI y Kubernetes versión 1.22+.
Representación Gráfica de ReadWriteOncePod AccessMode Puedes definir el modo de acceso como una de las propiedades de tus PVs y PVCs, como se muestra en el ejemplo a continuación:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: single-writer-only
spec:
accessModes:
- ReadWriteOncePod # Permitir solo a un único pod acceder a single-writer-only.
resources:
requests:
storage: 1Gi
Todo esto nos ayudará en nuestro camino para que todos nuestros diferentes tipos de cargas de trabajo logren todos los beneficios de la transformación digital y nos permita, como arquitectos o desarrolladores, elegir el patrón correcto para nuestro caso de uso sin estar restringidos en absoluto.
Los creadores de contenido están educando a los desarrolladores junior en plataformas sociales que probablemente idealizan su visión incluso cuando no son los mejores de su clase.
Estamos viviendo un momento de máxima exposición a la creación de contenido con temas de desarrollo de software. La última noticia sobre este tema es la creación de una sección específica sobre Canales de Desarrollo de Software en la popular plataforma de streaming Twitch:
Twitch introduces new “Software & Game Development” streaming category, boosting gamedev content discoverability | Game World Observer
Twitch announced that it’s introducing new Software & Game Development streaming category to improve the discoverability of content for devs.
Y eso es solo una etapa adicional en la tendencia que estamos viendo en los últimos años donde el contenido creado y las personas que invierten su tiempo en compartir su conocimiento en internet están explotando.
El pie de foto del Desarrollo de Software y Juegos de Twitch.tv
Prácticamente puedes encontrar un Canal en Vivo que te enseñará o compartirá contigo mucho conocimiento y experiencia sobre todos los temas relacionados con el desarrollo de software. No importa qué tema estés buscando, lo tendrás allí. Por ejemplo, hoy más temprano fui. Encontré los siguientes canales en vivo: Creando un MMO desde cero, Desarrollo de Maya, Programación en Java, Programación en GoLang, Programación de CMS usando Django y Python, y mucho más.
Esto es algo grandioso. Vivimos en una era donde tenemos contenido de gran calidad a nuestra disposición, especialmente en nuestra industria, que nos ayudará a mejorar nuestras habilidades y base de conocimientos. Todos estos creadores de contenido son los principales contribuyentes a eso. Y esos están aumentando la popularidad de los mejores creadores de contenido alcanzando niveles sobresalientes.
Pero esa situación también está creando la circunstancia de que los desarrolladores junior o simplemente personas que comienzan una nueva habilidad comiencen a pensar que las personas que muestran su visión o experiencia sobre un tema son los mejores desarrolladores en esa área, y eso está muy lejos de la verdad. Así que se está inclinando hacia una situación peligrosa.
Para ser claro: Los Creadores de Contenido no suelen ser Grandes Desarrolladores. Normalmente son desarrolladores regulares con habilidades de comunicación impresionantes. Y eso es más importante con una voluntad de compartir lo que saben con su audiencia. Incluso que están ganando dinero con esto, para ser justos, tienen una determinación inequívoca de desempeñar un papel social de compartir el conocimiento con el mundo, y eso es muy importante.
Esto no es solo intentar avergonzar a los creadores de contenido por su calidad; esto está sucediendo en todas las industrias. El mejor conocimiento compartido no suele ser el mejor de su práctica. Puedes pensar en cualquier tema: Matemáticas, Física, pero también Deportes. ¿Son los mejores narradores de Fútbol los mejores jugadores? No, seguro.
Pero por esta razón, es importante tener en cuenta esto cuando asistimos a esos canales o vemos esos videos que no son los verdaderos expertos, por lo que siempre debes verificar sus declaraciones para asegurarte de que estén alineadas con las mejores prácticas y procesos.
Si te gustaría ver lo que los verdaderos buenos desarrolladores están haciendo, es mucho más fácil encontrarlo cerca de donde reside el código. Usando plataformas como GitHub o SourceForge, los proyectos con más estrellas que proporcionan valor y leyendo sus conversaciones o analizando sus commits, te proporcionaremos una visión mucho más clara de lo que los verdaderos desarrolladores de alto nivel están haciendo.
Proyectos de GitHub que proporcionan una fuente increíble de conocimiento y buenas prácticas
Otra opción es suscribirse a la lista de correo de esos proyectos donde puedes ver la discusión real de los desarrolladores, los puntos principales que están haciendo y el razonamiento detrás de esas decisiones.
Una lista de correo te ayudará a entender cuál es el razonamiento detrás de algunas decisiones importantes de software
Este es un conocimiento mucho más importante que lo que puedes ver en una sesión en vivo de alguien programando en una plataforma de streaming, pero esto también es parte del proceso porque necesitarás tener la base para estar listo para entender a qué se refiere la discusión y para ese nivel de introducción la forma en que este increíble creador de contenido está compartiendo el conocimiento es la mejor manera para que cualquiera lo entienda y lo asimile.
Vamos a ver si el protocolo gRPC, que está surgiendo como una de las fuertes alternativas frente al servicio REST tradicional, puede mostrar todos los beneficios que la gente está reclamando
Si ya has estado en la industria tecnológica últimamente, sabes que gRPC se está convirtiendo en uno de los protocolos más populares para la integración entre componentes, principalmente microservicios, debido a sus beneficios en comparación con otras soluciones estándar como REST o SOAP.
Hay otras alternativas que también se están volviendo mucho más populares a diario, como GraphQL, pero el enfoque de hoy es en gRPC. Si deseas echar un vistazo a los beneficios de GraphQL, puedes ver el artículo que se muestra a continuación:
Why Should You Use GraphQL for your APIs?
3 benefits of using GraphQL in your API that you should take into consideration. Photo by Mika Baumeister on Unsplash We all know that APIs are the new standard when we develop any piece of software. All the latest paradigm approaches are based on a distributed amount of components created with a collaborative approach in mind […]
Entonces, ¿cuáles son los principales beneficios que generalmente se exponen respecto al uso de gRPC y por qué empresas como Netflix o Uber lo están utilizando?
Mensajes ligeros
Alto rendimiento
Soporte para patrón de transmisión
Parece una buena alternativa de una versión renovada de la llamada a procedimiento remoto tradicional que se ha estado utilizando en los años 90, pero probémoslo en algunos casos de uso real para intentar medir los beneficios que todos están reclamando, especialmente en cuanto al rendimiento y la ligereza de los mensajes, así que decidí definir un escenario muy sencillo de un patrón de solicitud/respuesta entre dos aplicaciones y probarlas con una llamada REST normal y una llamada gRPC.
Definición de Escenario de Prueba Simple
Pila Tecnológica
Vamos a usar TIBCO Flogo para crear la aplicación y utilizar un entorno visual sin código para simplificar la generación de la aplicación. Si deseas ver más en detalle sobre esta tecnología, por favor revisa el post a continuación:
TIBCO Flogo Introduction
Flogo is the next new thing in the developing applications in a cloud-native way. Since its foundation has been designed to cover all the new challenges that we need to face when dealing with new cloud-native development. So, please, if you or your enterprise is starting its movement to the cloud it’s the moment to […]
Entonces, vamos a crear dos aplicaciones: La primera se activará en intervalos programados cada 100 ms y llamará usando gRPC a la segunda aplicación que simplemente devolverá los datos a la aplicación de llamada codificados de manera fija para evitar que cualquier otro sistema de terceros pueda impactar en la medición del rendimiento.
En cuanto a los datos que vamos a transmitir, será un enfoque simple de Hola Mundo. La primera aplicación enviará un nombre a la segunda aplicación que devolverá el “Hola, nombre, Esta es mi aplicación gRPC (o REST)” para poder imprimirlo en la consola.
Enfoque REST
A continuación se muestran las aplicaciones para el caso de prueba utilizando la tecnología TIBCO Flogo para definirlo:
Aplicaciones Flogo para el caso REST
Como puedes ver, es simple e intuitivo. Tenemos la primera aplicación activada por un Trigger y con una actividad de Invocación REST y luego un Mensaje de Registro para imprimir lo que se ha recibido. La segunda aplicación es aún más simple, solo expone la API REST y devuelve los datos codificados de manera fija.
Enfoque gRPC
El enfoque gRPC será un poco más difícil porque necesitamos crear la definición protobuf para el cliente y servidor gRPC. Así que comenzaremos con una definición simple del servicio Hello como puedes ver en la imagen a continuación:
Definición de Protobuf para el Escenario de Prueba gRPC
Y basado en eso, podemos generar las diferentes aplicaciones tanto del cliente como del servidor de esta prueba simple:
Aplicaciones gRPC en TIBCO Flogo
Como puedes ver, las aplicaciones son muy similares a las de REST, solo cambiando un protocolo por el otro, y eso es una de las cosas increíbles de TIBCO Flogo, podemos tener una implementación simple sin conocer los detalles de los protocolos más nuevos pero obteniendo todas las ventajas que proporcionan.
Resultados de la Prueba
Después de 100 ejecuciones del servicio REST, estas son las métricas que pudimos obtener usando el exportador de Prometheus que proporciona la herramienta:
Métricas de Prometheus para la Ejecución del Escenario REST
Así que tenemos alrededor de 4 ms para el flujo del cliente y 0.16 ms para el servicio REST en sí, por lo que ya son números bajos. ¿Realmente crees que una versión gRPC podría mejorarlo? Vamos a verlo. Aquí están las mismas métricas para 100 invocaciones del segundo flujo usando gRPC:
Métricas de Prometheus para la Ejecución del Escenario gRPC
Como puedes ver, la mejora es impresionante incluso para un servicio simple que se ejecuta en localhost. El servicio gRPC tuvo métricas de 0.035 ms frente a los 0.159 que tenía la versión REST, una mejora del 77.98% frente a la API REST, esto es simplemente increíble… pero ¿qué pasa con el cliente? Pasó de 4.066 ms a 0.89 ms, lo que significa otra mejora del 78.1%.
Representación Gráfica de Ambas Ejecuciones de Escenario
Entonces, la lógica debería ser si esto se puede hacer con un servicio simple donde los datos intercambiados son prácticamente nada, ¿qué puede hacer cuando la carga útil es grande? las opciones son simplemente inimaginables…
Resumen
Probamos las cosas buenas que hemos escuchado en línea sobre el método gRPC que la mayoría de las tecnologías de vanguardia están utilizando hoy en día y hemos quedado impresionados solo con un escenario simple comparándolo con el rendimiento de una interfaz REST. Seguro que gRPC tiene sus contras como cualquier otra opción, pero en términos de rendimiento y optimización de mensajes, los datos hablan por sí mismos, es simplemente asombroso. ¡Mantente atento a nuevas pruebas sobre los beneficios de gRPC y también algunos de sus contras para intentar ver si podría ser una gran opción para tu próximo desarrollo!
Cuando el marketing se apropia de una palabra técnica, conduce a la locura y a un cambio completo de su significado.
API es el siguiente en la lista. Siempre es el mismo patrón con respecto a los términos técnicos cuando van más allá del foro realmente técnico normal y alcanzan un nivel más «mainstream» en la industria. Tan pronto como esto sucede, el término comienza a perder su significado y empieza a ser como una palabra comodín que puede significar cosas muy diferentes para personas muy diferentes. Si no me crees, acompáñame a este conjunto de ejemplos.
Puedes argumentar que los términos necesitan evolucionar y que la misma palabra puede significar cosas diferentes siempre que la industria continúe evolucionando, y eso es cierto. Por ejemplo, el término paquete que en el pasado se refería a la forma de empaquetar software para poder compartirlo, generalmente a través de correo o un servidor FTP como un paquete TAR, ha sido redefinido con la eclosión de los gestores de paquetes en los años 90 y después con la gestión de artefactos para manejar dependencias con enfoques como Maven, npm, etc.
Pero no estoy hablando de estos ejemplos. Estoy hablando de cuando un término se usa mucho porque es elegante y significa evolución o modernización, por lo que intentas usarlo tanto como sea posible, incluso para significar cosas diferentes. Y uno de estos términos es API.
API significa Interfaz de Programación de Aplicaciones, y como su nombre indica, es una interfaz. Desde el principio de los tiempos de la computación, se ha creado para referirse al contrato y cómo necesitas interactuar con un programa de aplicación específico. Sin embargo, el término se usaba principalmente para bibliotecas para definir su contrato para otras aplicaciones que necesitaban la capacidad.
Así que si quisiéramos mostrar esto en una forma gráfica, esto es a lo que se refiere la API:
Con la eclosión de los Servicios REST y las aplicaciones móviles, el término API se expandirá más allá de su uso normal y se convertirá en una palabra normal en el mundo de hoy porque todos los desarrolladores necesitan alguna API para trabajar. Comenzando desde las capacidades comunes como la Autenticación hasta que solo se necesitan capacidades concretas para realizar su trabajo.
La explosión de servicios que expusieron su propia API requirió una forma de proporcionar gestión central a las interfaces expuestas, especialmente cuando comenzamos a publicar algunas de estas capacidades al mundo exterior. Necesitábamos asegurarlas, identificar quién las estaba usando y a qué nivel, y una forma para que los desarrolladores encontraran la documentación necesaria para poder usar sus servicios. Y debido a eso, tenemos el auge de las soluciones de Gestión de API.
Y luego vinieron los microservicios a revolucionar cómo se realizan las aplicaciones, y eso supone que ahora tenemos más servicios, cada uno de ellos proporcionando su propia API a un nivel que prácticamente tenemos un servicio para una capacidad y debido a eso una API para una capacidad, algo como puedes ver en la imagen a continuación:
Y el uso de API se volvió tan popular que algunas personas comenzaron a usar el término para referirse a la interfaz y al servicio completo que implementa esta API, lo que lleva y está llevando a mucha confusión. Así que debido a eso, cuando hablamos ahora sobre Desarrollo de API, podemos hablar de cosas muy diferentes:
Podemos hablar sobre la definición y el modelo de la interfaz en sí misma y su gestión.
Podemos hablar sobre una implementación de servicio con una API expuesta para ser utilizada y gestionada adecuadamente.
Incluso podemos hablar sobre un servicio que utiliza varias APIs como parte de su implementación de capacidad.
Y el problema principal cuando usamos el mismo término para referirse a tantas cosas diferentes es que la palabra pierde todo su significado y con eso complica nuestra comprensión en cualquier conversación y eso lleva a muchos problemas que podríamos evitar simplemente usando las palabras adecuadas e intentando mantener todo el ruido y el marketing un poco fuera de las conversaciones técnicas.
Medium puede ser uno de tus mejores aliados en esta tarea interminable de mantenerse al día con las actualizaciones en la industria tecnológica.
Todos los que estamos aquí usamos Medium. Estoy siendo un poco Capitán Obvio aquí porque si estás leyendo esto, estoy seguro de que ya estás usando Medium para el crecimiento profesional y para aprender cosas nuevas, pero me gustaría destacar cómo lo uso para mantenerme al día con la situación actual.
Sabes que las cosas cambian muy rápido. Por supuesto, esto está sucediendo en todas las industrias y negocios, pero es aún más urgente en la industria tecnológica.
Estamos viendo nuevas tecnologías cada semana o incluso cada día. Los frameworks cambian tan rápido como podemos imaginar, y tratar de mantener el ritmo de eso es bastante complejo para cualquiera de nosotros. Por lo tanto, debemos usar todas las herramientas a nuestra disposición para asegurarnos de hacer lo mejor en esta situación.
#1 Ajusta tus Recomendaciones Personalizadas
Una de las grandes cosas de Medium es que utiliza tus intereses y los artículos que has estado leyendo y cuánto tiempo pasaste leyéndolos para recomendarte nuevos artículos relevantes.
Así que, aquí las recomendaciones son claras: Usa Medium todo el tiempo. Intenta usar la capacidad de búsqueda para buscar en muchos artículos disponibles porque cuanto más lo uses, más precisas serán las recomendaciones para ti.
Tuve un tiempo, hace unas semanas, cuando estaba realmente interesado en Arquitecturas de Datos Modernas y Nativas de la Nube debido a algunas responsabilidades profesionales. Así que comencé a buscar esos artículos en Medium. Desde ese momento, las recomendaciones han sido bastante precisas sobre lo que estaba buscando y me ayudaron a mejorar mi conocimiento y encontrar artículos que no tenía idea de que estaban disponibles en Medium.
Además de eso, necesitas asegurarte de que tus intereses estén bien configurados. Por lo general, cuando configuramos una cuenta y nos preguntan sobre nuestros intereses, probablemente no lo pensamos mucho tiempo porque lo único que queremos es acceder al contenido de inmediato (¡culpable aquí!).
Por lo tanto, debes tomarte tu tiempo ahora para asegurarte de que los intereses que seleccionaste cuando te uniste sigan siendo los más relevantes para ti hoy. Si deseas verificar tus intereses actuales, necesitas ir a tu perfil y hacer clic en «Controla tus Recomendaciones», como puedes ver en la imagen a continuación:
Página de Controla tus Recomendaciones de mi perfil de Medium
Además, verás los temas que te interesan ahora y un montón de sugerencias de nuevos temas basados en tu historial de lectura que creen que podrían interesarte. Por lo tanto, es importante visitar la página de vez en cuando para asegurarte de que sean precisos y verificar las recomendaciones que te están proporcionando.
#2: Función Leer Más Tarde
Otra característica clave es guardar todos los artículos interesantes para continuar leyéndolos más tarde o mantenerlos como tu propia biblioteca. Este es el uso principal que le doy a ese concepto. Intento usar la función Leer Más Tarde para crear y gestionar mi propia «biblioteca basada en Medium».
Y la razón principal detrás de este enfoque es porque todos hemos sufrido esta situación cuando encontramos un gran artículo sobre un tema. Sin embargo, cambiamos a otra tarea, y más tarde, cuando necesitamos encontrar ese artículo nuevamente, no recordamos el título o el autor, y pasamos mucho tiempo tratando de localizarlo nuevamente.
#3: Capacidad de Búsqueda
Incluso cuando estamos acostumbrados a usar Google como nuestra principal opción de búsqueda para buscar cualquier cosa, creo que es importante usar las capacidades de búsqueda en el sitio de Medium por varias razones:
El contenido que tenemos disponible en Medium es enorme, y la mayoría de ellos es de gran calidad debido al proceso de curación.
Es importante que Medium te conozca mejor, y eso afinará todas las recomendaciones que ya hemos comentado.
Y todo esto sin preocuparte de que encontrarás muchos anuncios basados en tu historial de búsqueda 🙂
#4: Miembro de Medium
Y he dejado para el final lo que creo que es la parte más importante: Convertirse en Miembro de Medium.
Medium es genial, no importa si eres miembro o no. Aún así, cuando no era miembro de Medium, era simplemente molesto encontrar el artículo que necesitaba, pero no podía leerlo porque ya había gastado los artículos «destacados» del mes, y necesitaba esperar un mes adicional. Así que sabemos que esto no es válido si quieres mantenerte actualizado en la industria tecnológica, así que por favor, hazte un favor y conviértete en miembro de Medium. Te sentirás más cómodo en la plataforma y comenzarás a vivir dentro de ella.
No, no era una cuestión de salario. Se trataba de confianza
Todos pasamos por varios procesos de reclutamiento cada año. Puede que no nos sintamos cómodos con nuestra empresa o rol actual. Tiendo a usarlos para ver qué hay disponible afuera y asegurarme de que no me estoy quedando obsoleto.
No suelo postularme a ofertas en línea en situaciones normales, pero cuando alguien se acerca a mí con una propuesta interesante, tiendo a escucharlos para ver qué tienen para ofrecer.
Así es como comencé mi último proceso de reclutamiento.
La razón principal para estar a bordo con el proceso fue que la empresa (no la nombraré aquí) y el rol eran lo que tenía en mi radar como mi próximo paso.
El Proceso
Comenzó con una charla básica con el reclutador para obtener una visión general del rol de la empresa (la empresa es bastante conocida por todos, así que fue rápido) y lo que esperaban. Acordamos los términos, y los números que compartió respecto al salario me convencieron de avanzar con los siguientes pasos para invertir algo de tiempo en esta oportunidad.
Debo admitir que no soy alguien que se prepara y estudia para entrevistas. Soy quien soy. Si mis conocimientos y habilidades son adecuados para la empresa, no quiero pretender ser otra persona o mostrar que soy más inteligente de lo que soy.
Comenzamos con un proceso virtual y algunas tareas virtuales — primero, un modelo de rol que me gustó porque fue inesperado. Tienes un buzón virtual, recibes correos electrónicos de tu jefe o colegas, y necesitas decidir cuál es la respuesta más adecuada.
Luego pasamos a un cuestionario técnico que fue como se esperaba. Cosas normales de bajo nivel para el rol que estaba tratando de obtener (Arquitecto de Soluciones Senior), pero eso estaba bien.
Así que, fuimos a la primera llamada con mi futuro Gerente de Contratación, y fue más basada en el rol que técnica. Quería saber sobre mi experiencia previa que había mostrado algunos aspectos que consideraba relevantes para el trabajo. Eso estuvo bien, y fue una discusión cómoda. Pero esta fue la primera entrevista, y comencé a detectar que algo no estaba bien. Todo se aclararía en la última parte del proceso.
Antes de eso, tuve otra tarea técnica que fue bastante fácil. Se centró en resolver un problema, proporcionando mejoras a mediano y largo plazo. Fue un gran ejercicio de una hora. Como dije, nada complicado pero aún así divertido.
La última parte del proceso consistió en una serie de entrevistas con diferentes perfiles en la empresa. Siguió el mismo enfoque que la anterior. La mayoría de ellas se centraron en preguntas de modelo de rol y otras se centraron en temas relacionados con tecnologías que usaría en mi trabajo o preguntas generales relacionadas con TI.
La Resolución
Aparte del proceso que consume mucho tiempo (al final, hice nueve entrevistas con RRHH), no tuve ningún problema con esas entrevistas. Estuvieron bien y todas me hicieron sentir muy cómodo, pero el proceso tomó el enfoque equivocado en varios aspectos:
Las preguntas técnicas no se centraron en las cosas correctas. He hecho muchas entrevistas en mi vida en ambos lados de la mesa, y en este caso, se sintió más como un examen de TI que como una entrevista. La mayoría de las preguntas eran de muy bajo nivel para un Arquitecto Senior y más similares a las cosas que ves cuando recién sales de la universidad. Nunca me gustó este enfoque de entrevistas como si fuera un examen que necesitas aprobar. Fue la primera advertencia.
Pero la segunda advertencia fue durante cada una de las entrevistas. Todas las entrevistas incluían cinco minutos para que yo hiciera preguntas sobre mi rol o la empresa. Si tuve siete entrevistas (no contaré las de RRHH), tuve cinco minutos en cada una de ellas. Tuve 35 minutos para hacer mis preguntas (que preparé de antemano), y ellos tuvieron 385 minutos para sus preguntas. Eso me dejó con el 9% del tiempo de la entrevista para decidir si esta era la empresa adecuada para mí.
Resumen
Finalmente, recibí la oferta y decidí rechazarla porque este no era el enfoque que esperaría cuando estás contratando a alguien adecuadamente. Puedo entender que las grandes empresas necesitan tener un proceso definido para asegurarse de que solo contratan a los mejores entre un gran grupo de candidatos. Aún así, creo que hay un aspecto que no están cubriendo.
Esto es una calle de dos vías: Como empresa, debería ser tan importante para mí seleccionar al candidato adecuado como lo es para ellos. Fallaron en ese sentido. No me sentí cómodo ni como si tuviera suficiente información. Aún peor, no creo que siquiera les importara si estaba teniendo alguna duda sobre la empresa.
No pretenderé que este artículo hará que las empresas reconsideren sus procesos. Solo quería mostrar mi proceso de pensamiento y por qué el trabajo adecuado y el salario adecuado en una empresa increíble no fueron suficientes. Si ni siquiera pude sentirme cómodo durante el proceso, esta empresa no sería una buena opción para mí a largo plazo.
Espero que hayas disfrutado este artículo. Por favor, siéntete libre de compartir tus opiniones y puntos de vista — especialmente si piensas que actué como un tonto.
Descubre cuáles son las razones por las que, para mí, Apache NetBeans sigue siendo el mejor IDE de Java que puedes usar
Permíteme empezar desde el principio. Siempre he sido un Desarrollador Java desde mi tiempo en la Universidad. Aunque primero aprendí otro lenguaje de programación menos conocido (Modula-2), rápidamente pasé a Java para hacer todas las diferentes tareas y prácticamente cada tarea en mi camino como estudiante y luego como ingeniero de software.
Siempre estaba buscando el mejor IDE que pudiera encontrar para acelerar mis tareas de programación. La principal opción era Eclipse en la universidad, pero nunca fui fan de Eclipse, y eso se convirtió en un problema.
Si estás en la industria del Software Empresarial, habrás notado que prácticamente todas las herramientas basadas en Desarrolladores están basadas en Eclipse porque su licencia y la comunidad detrás lo hacen la mejor opción. Pero nunca pensé que Eclipse fuera un gran IDE, era demasiado flexible pero al mismo tiempo demasiado complejo.
Así que en ese momento es cuando descubrí NetBeans. Creo que la primera versión que probé fue en la rama 3.x, y Sun Microsystem lo desarrolló en ese momento. Era mucho mejor que Eclipse. De hecho, la cantidad de plugins disponibles no era comparable con Eclipse, pero las cosas que hacía, las hacía increíblemente bien.
Para mí, si necesito declarar por qué en ese momento NetBeans era mejor que Eclipse, probablemente las principales cosas serían estas:
Simplicidad en la Configuración de Ejecución: Aún creo que la mayoría de los IDE de Java hacen las cosas demasiado complejas solo para ejecutar el código. NetBeans simplemente ejecuta sin necesidad de crear una Configuración de Ejecución y configurarla (puedes hacerlo, pero no estás obligado a hacerlo)
Mejor Apariencia: Esto se basa más en una preferencia personal, pero prefiero la configuración predeterminada de NetBeans en comparación con Eclipse.
Así que por eso, NetBeans se convirtió en mi aplicación predeterminada para hacer mi Programación Java, pero Oracle llegó, y las cosas cambiaron un poco. Con la adquisición de Sun Microsystems por parte de Oracle, NetBeans se estancó como muchos otros proyectos de código abierto. Durante años no hubo muchas actualizaciones y progreso.
No es que hayan dejado de lado el producto, pero Oracle tenía un IDE diferente en ese momento, JDeveloper, que era la opción principal. Esto es fácil de entender. Continué siendo leal a NetBeans incluso cuando teníamos otro gran competidor: IntelliJ IDEA.
Esta es la opción elegante, la que la mayoría de los desarrolladores usan hoy en día para la programación en Java, y puedo entender por qué. He intentado varias veces en mi idea tratar de sentir las mismas sensaciones que otros tuvieron, y pude leer los diferentes artículos, y reconozco algunas de las ventajas de la solución:
Mejor rendimiento: Está claro que el tiempo de respuesta del IDE es mejor con IntelliJ IDEA que con NetBeans porque no proviene de un viaje de casi 20 años, y pudo comenzar desde cero y usar enfoques modernos para la GUI.
Menos Recursos de Memoria: Seamos honestos: Todos los IDE consumen toneladas de memoria. Ninguno lo hace genial aquí (a menos que estés hablando de editores de texto con compilador de Java; esa es otra historia). NetBeans de hecho requiere más recursos para funcionar correctamente.
Así que, hice el cambio y comencé a usar la solución de JetBrains, pero nunca me convenció, porque para mí sigue siendo demasiado complejo. Muchas cosas elegantes, pero menos enfoque en las que necesito. O, simplemente porque estaba demasiado acostumbrado a cómo NetBeans hace las cosas, no pude hacer el cambio mental que se requiere para adoptar una nueva herramienta.
Y entonces… cuando todo parecía perdido, algo increíble sucedió: NetBeans fue donado a la Fundación Apache y se convirtió en Apache NetBeans. Parece una nueva vida para la herramienta proporcionando cosas simples como el Modo Oscuro y manteniendo la solución actualizada con el progreso en el Desarrollo de Java.
Así que, hoy, Apache NetBeans sigue siendo mi IDE preferido, y no podría recomendar más el uso de esta increíble herramienta. Y estos son los puntos principales que me gustaría destacar aquí:
Mejor Gestión de Maven: Para mí, la forma y la simplicidad con la que puedes gestionar tu proyecto Maven con NetBeans está fuera de esta liga. Es simple y se enfoca en el rendimiento, agregando una nueva dependencia sin ir al archivo pom.xml, actualizando dependencias sobre la marcha.
Configuración de Ejecución: Nuevamente, esto sigue siendo un diferenciador. Cuando estoy codificando algo rápido debido a un nuevo tipo de utilidad, no me gusta perder tiempo creando configuraciones de ejecución o agregando un plugin maven exec a mi pom.xml para ejecutar el software que acabo de codificar. En su lugar, necesito hacer clic en Ejecutar, un botón verde, y dejar que la magia comience.
No hay necesidad de todo lo demás: Las cosas evolucionan demasiado rápido en el mundo de la programación Java, pero incluso hoy, nunca siento que me falte alguna capacidad o algo en mi IDE NetBeans que podría obtener si me muevo a una alternativa más moderna. Así que, no hay concesiones aquí a este nivel.
Así que, soy consciente de que probablemente mi elección se deba a que tengo una visión sesgada de esta situación. Después de todo, esta ha sido mi solución principal durante más de una década, y simplemente estoy acostumbrado a ella. Pero me considero una persona abierta, y si viera una diferencia clara, no tendría dudas en abandonar NetBeans como lo hice con muchas otras soluciones en el pasado (Evernote, OneNote, Apple Mail, Gmail, KDE Basket, Things, Wunderstling.. )
Así que, si tienes curiosidad por ver cómo ha progresado Apache NetBeans, por favor echa un vistazo a la última versión y dale una oportunidad. O, si sientes que no conectas con la herramienta actual, dale una oportunidad de nuevo. ¡¡¡Quizás tengas la misma visión sesgada que yo!!!
Descubre el estado actual de las primeras interfaces gráficas para contenedores docker y cómo proporciona una solución para las plataformas de contenedores modernas
Quiero comenzar este artículo con una historia que no estoy seguro de que todos ustedes, increíbles lectores, conozcan. Hubo un tiempo en que no había interfaces gráficas para monitorear tus contenedores. Fue hace mucho tiempo, entendiendo mucho tiempo como podemos hacerlo en el mundo de los contenedores. Tal vez esto fue en 2014-2015 cuando Kubernetes estaba en su etapa inicial, y también, Docker Swarm acababa de ser lanzado y parecía la solución más confiable.
Así que la mayoría de nosotros no teníamos una plataforma de contenedores como tal. Simplemente ejecutábamos nuestros contenedores desde nuestras propias laptops o pequeños servidores para empresas de vanguardia usando comandos de docker directamente y sin más ayuda que la herramienta CLI. Como puedes ver, las cosas han cambiado mucho desde entonces, y si te gustaría refrescar esa visión, puedes consultar el artículo compartido a continuación:
Discover Your Perfect Tool for Managing Kubernetes
Maximizing the productivity of working with Kubernetes Environment with a tool for each persona Photo by Christina @ wocintechchat.com on Unsplash We all know that Kubernetes is the default environment for all our new applications we developed we will build. The flavor of that Kubernetes platform can be of different ways and forms, but one thing is […]
Y en ese momento, un proyecto de código abierto proporciona la solución más increíble porque no sabíamos que necesitábamos eso hasta que lo usamos, y esa opción era portainer. Portainer proporciona una interfaz web muy impresionante donde puedes ver todos los contenedores docker desplegados en tu host docker y desplegar como otra plataforma.
Fue el primero y generó un impacto tremendo, incluso generó una serie de otros proyectos que fueron nombrados: el portainer de… como dodo el portainer de la infraestructura de Kubernetes en ese momento.
Pero tal vez te preguntes… ¿y cómo está portainer? ¿sigue siendo portainer una cosa? Sigue vivo y coleando, como puedes ver en su página de proyecto de GitHub: https://github.com/portainer/portainer, con el último lanzamiento a finales de mayo de 2021.
Ahora tienen una versión Business pero aún como Community Edition, que es la que voy a estar analizando aquí con más detalle en otro artículo. Aún así, me gustaría proporcionar algunos aspectos destacados iniciales:
El proceso de instalación sigue el mismo enfoque que los lanzamientos iniciales para ser otro componente de tu clúster. Las opciones para ser utilizadas en Docker, Docker Swarm o Kubernetes cubren todas las soluciones principales que todas las empresas utilizan.
Welcome | Portainer Documentation
Ahora proporciona una lista de plantillas de aplicaciones similar a la lista del Catálogo de Openshift, y también puedes crear las tuyas propias. Esto es muy útil para las empresas que suelen depender de estas plantillas para permitir a los desarrolladores usar un enfoque común de despliegue sin necesidad de hacer todo el trabajo.
Vista de Plantilla de Aplicación de Portainer 2.5.1
Las capacidades de Gestión de Equipos pueden definir usuarios con acceso a la plataforma y agrupar a esos usuarios como parte del equipo para una gestión de permisos más granular.
Soporte multi-registro: Por defecto, se integrará con Docker Hub, pero también puedes agregar tus propios registros y poder extraer imágenes directamente de esos directamente desde la GUI.
En resumen, esta es una gran evolución de la herramienta portainer mientras mantiene el mismo espíritu que todos los antiguos usuarios amaban en ese momento: Simplicidad y Enfoque en lo que un Administrador o Desarrollador necesita saber, pero también agregando más características y capacidades para mantener el ritmo de la evolución en la industria de plataformas de contenedores.
