Let's get into Microservices (together)

Why would anyone define microservices as an architecture choice?

If you're already familiar to microservices, then the answer to the question above might seem quite obvious. But if you aren't, like me, then you might learn some new concept today.

So, I've recently got his book titled "Building Microservices: Designing Fine-Grained Systems" by Sam Newman and I'm going to write some content as I read, and understand, it :).

Microservices are technology agnostic; they are independently deployable; they embrace the concept of information hidding.

Here is a statement I really like and find extremely important within the confines of... software?, system? development. Whatever.

“Information that is hidden from external parties can be changed freely as long as the networked interfaces the microservice exposes don't change in a backward-incompatible fashion.”

Sam Newman

That makes the whole system modular and reliable. 

But what kind of system could it be? Are we talking about a standalone software consisting of various microservices? Perhaps, a bigger picture of a system consisting of a few softwares, each of them working over microservices at the same time? 

Well, let's get through this by describing a few illustrative examples!

Mi opinión sobre el uso irresponsable de la inteligencia artificial y sus consecuencias

Me gustaría dar mi punto de vista sobre el mal uso que se le da (en muchas ocasiones) a la inteligencia artificial en el entorno laboral. Cuando digo IA me refiero a ChatGPT, Gemini, Claude, etc. indistintamente.

Como ingeniero y desarrollador de software sé perfectamente el tiempo y esfuerzo que supone hacer ciertas tareas. Pueden ser tareas de código (implementar una nueva funcionalidad sobre la que hay poca documentación en internet), o escribir un estado del arte sobre cierta tecnología y para un determinado propósito. Quizás podría ser algo tan simple como responder a una pregunta que te hace un compañero: "Hey, Chati GPT, ¿cuál es la mejor herramienta para capturar tráfico en Ubuntu 22?"; y le "copipasteas" la respuesta a tu compañero casi sin haberla leído y, ni mucho menos, razonado o contrastado.

Bueno, hasta aquí uno puede pensar que no es para tanto, o que solamente podrían darse problemas serios si es que estamos copiando y pegando código de la IA en código crítico. Bajo mi punto de vista hay otros muchos escenarios en los que es muy fácil caer en la tentación de usar la IA de mala manera. Escenarios en los que, indirectamente, se perjudica al desarrollo de un software haciendo que se implementen cosas que no tienen sentido.

Esto suele pasar cuando se hacen las cosas con prisa (sea porque hay realmente poco tiempo o por ser "un ansias").

Imagen generada con la ayuda de IA (lo de copiar, pegar, rezar de la taza me ha matado).

Principio de Mínimo Privilegio: qué acceso le das al cliente en tu repo de GitHub durante su desarrollo

Hace tiempo que quería investigar sobre este tema. Como desarrollador, entiendo que es normal encontrarse en este tipo de nuevas situaciones y no saber cómo gestionarlas de primera mano. El contexto es el siguiente: estás llevando a cabo el desarrollo de un software (llamémoslo Ajile) para un cliente (llamémoslo Uartec) y durante la contratación nos comprometimos a realizar una transferencia tecnológica (del desarrollo de Ajiile, en este caso). Uartec nos pide acceso al repositorio privado en el que se lleva a cabo este desarrollo, lo que nos hace preguntarnos: ¿qué nivel de acceso le damos?

Digamos que Ajile está subido en un repositorio de GitHub privado dentro de mi organización, Devsoft. Se acordó desde el principio que así sería, por razones de comodidad y organizativas. Para que Uartec tenga acceso al código necesita permisos de lectura, como mínimo. Pero, ¿solo de lectura? ¿O algo más?

Antes de tomar ninguna decisión, conviene tener clara la tabla de permisos que ofrece GitHub para colaboradores en un repositorio privado dentro de una organización:

• Lectura: se recomienda para colaboradores que no trabajan en el código, pero que quieren ver el proyecto o hablar sobre él
• Evaluación de prioridades: se recomienda para colaboradores que necesitan administrar de forma proactiva problemas, discusiones y solicitudes de incorporación de cambios sin acceso de escritura
• Escritura: se recomienda para los colaboradores que insertan cambios activamente en el proyecto
• Mantenimiento: se recomienda para los jefes de proyecto que necesiten administrar el repositorio sin acceder a acciones confidenciales o destructivas
• Administración: se recomienda para usuarios que necesitan acceso total al proyecto, incluidas acciones confidenciales y destructivas, como administrar la seguridad o eliminar un repositorio

Como puede uno imaginar, el rol asignado a cada colaborador debe ser estrictamente el de menor responsabilidad necesaria. Esto se define en el Principio de Mínimo Privilegio. Este fue formulado por primera vez por Jerome Howard "Jerry" Saltzer en su publicación titulada "The protection of information in computer systems", en 1975.

Su cita "Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job." recoge muy bien la idea que quiero transmitir con esta entrada.