“Que vivas en tiempos interesantes” es la traducción al inglés de la maldición china, y esto no podría ser más cierto como descripción de los tiempos en los que vivimos en cuanto a nuestra arquitectura de aplicaciones y desarrollo de aplicaciones.
Todos los cambios del enfoque nativo de la nube, incluyendo todas las nuevas tecnologías que vienen con él, como contenedores, microservicios, API, DevOps, etc., han transformado completamente la situación para cualquier arquitectura, desarrollador o administración de sistemas.
Es algo similar si te fuiste a la cama en 2003 y te despiertas en 2020, todos los cambios, todas las nuevas filosofías, pero también todos los desafíos únicos que vienen con los cambios y nuevas capacidades son cosas con las que necesitamos lidiar hoy.
Creo que todos podemos estar de acuerdo en que el presente es políglota en términos de desarrollo de aplicaciones. Hoy no se espera que ninguna gran empresa o corporación encuentre una tecnología disponible, un lenguaje disponible para soportar todos sus productos internos. Hoy todos seguimos y estamos de acuerdo con el principio de “la herramienta adecuada para el trabajo adecuado” para intentar crear nuestro conjunto de herramientas de tecnologías que vamos a usar para resolver diferentes casos de uso o patrones que necesitas enfrentar.
Pero ese acuerdo y movimiento también vienen con su desafío respecto a cosas en las que usualmente no pensamos, como el rastreo y la observabilidad en general.
Cuando usamos una sola tecnología, todo es más sencillo. Definir una estrategia común para rastrear tus flujos de extremo a extremo es fácil; solo necesitas incrustar la lógica en tu marco de desarrollo común o biblioteca que todos tus desarrollos están usando. Probablemente definir una arquitectura de encabezado típica con todos los datos que necesitas para poder rastrear efectivamente todas las solicitudes y definir un protocolo estándar para enviar todos esos rastros a un sistema estándar que pueda almacenarlos y correlacionarlos todos y explicar el flujo de extremo a extremo. Pero intenta mover eso a un ecosistema políglota: ¿Debería escribir mi marco o biblioteca para cada lenguaje o tecnología que necesitaría usar, o también puedo usar en el futuro? ¿Tiene sentido eso?
Pero no solo eso, ¿debería ralentizar la adopción de una nueva tecnología que puede ayudar rápidamente al negocio porque necesito proporcionar desde un equipo compartido este tipo de componentes estándar? Ese es el mejor caso en el que tengo suficiente gente que sabe cómo funcionan los internos de mi marco y tiene las habilidades en todos los lenguajes que estamos adoptando para poder hacerlo rápidamente y de manera eficiente. Parece poco probable, ¿verdad?
Entonces, a nuevos desafíos también nuevas soluciones. Ya he estado hablando sobre Service Mesh respecto a las capacidades que proporciona desde una perspectiva de comunicación, y si no lo recuerdas, puedes echar un vistazo a esas publicaciones:
Integrating Istio with BWCE Applications
Introduction Services Mesh is one the “greatest new thing” in our PaaS environments. No matter if you’re working with K8S, Docker Swarm, pure-cloud with EKS or AWS, you’ve heard and probably tried to know how can be used this new thing that has so many advantages because it provides a lot of options in handling […]
Pero también proporciona capacidades desde otras perspectivas y el rastreo y la observabilidad es una de ellas. Porque cuando no podemos incluir esas características en cualquier tecnología que necesitemos usar, podemos hacerlo en una tecnología general que sea compatible con todas ellas, y ese es el caso con Service Mesh.
Como Service Mesh es la forma estándar de comunicar sincrónicamente tus microservicios en una comunicación de este a oeste cubriendo la comunicación de servicio a servicio. Entonces, si puedes incluir en ese componente también la capacidad de rastreo, puedes tener un rastreo de extremo a extremo sin necesidad de implementar nada en cada una de las diferentes tecnologías que puedes usar para implementar la lógica que necesitas, así que, has cambiado de la Figura A a la Figura B en la imagen a continuación:
Implementación de lógica de rastreo en la aplicación vs. Soporte de rastreo de Service Mesh
Y eso es lo que la mayoría de las tecnologías de Service Mesh están haciendo. Por ejemplo, Istio, como una de las opciones predeterminadas cuando se trata de Service Mesh, incluye una implementación del estándar OpenTracing que permite la integración con cualquier herramienta que soporte el estándar para poder recopilar toda la información de rastreo para cualquier tecnología que se use para comunicarse a través de la malla.
Entonces, ese cambio de mentalidad nos permite integrar fácilmente diferentes tecnologías sin necesidad de ningún soporte excepcional de esos estándares para cualquier tecnología específica. ¿Significa eso que la implementación de esos estándares para esas tecnologías no es necesaria? En absoluto, eso sigue siendo relevante, porque las que también soportan esos estándares pueden proporcionar aún más información. Después de todo, el Service Mesh solo conoce parte de la información que es el flujo que está sucediendo fuera de cada tecnología. Es algo similar a un enfoque de caja negra. Pero también agregar el soporte para cada tecnología al mismo estándar proporciona un enfoque adicional de caja blanca como puedes ver gráficamente en la imagen a continuación:
Combinación de datos de rastreo de caja blanca y datos de rastreo de caja negra
Ya hablamos sobre el cumplimiento de algunas tecnologías con el estándar OpenTracing como TIBCO BusinessWorks Container Edition que puedes recordar aquí:
OpenTracing support in TIBCO BusinessWorks Container Edition
The past month during the KubeCon 2019 Europe in Barcelona OpenTracing announces its merge with OpenCensus project to create a new standard named OpenTelemetry that is going to be live in September 2019. So, I think that would be awesome to take a look at the capabilities regarding OpenTracing we have available in TIBCO BusinessWorks […]
Entonces, también, el soporte de estas tecnologías de los estándares de la industria es necesario e incluso una ventaja competitiva porque sin necesidad de desarrollar tu marco de rastreo, puedes lograr un enfoque de Datos de Rastreo Completo adicional a lo que ya proporciona el nivel de Service Mesh en sí mismo.
“May you live in interesting times” is the English translation of the Chinese curse, and this couldn’t be more true as a description of the times that we’re living regarding our application architecture and application development.
All the changes from the cloud-native approach, including all the new technologies that come with it like containers, microservices, API, DevOps, and so on has transformed the situation entirely for any architecture, developer, or system administration.
It’s something similar if you went to bed in 2003, and you wake up in 2020 all the changes, all the new philosophies, but also all the unique challenges that come with the changes and new capabilities are things that we need to deal with today.
I think we all can agree the present is polyglot in terms of application development. Today is not expected for any big company or enterprise to find an available technology, an available language to support all their in-house products. Today we all follow and agree on the “the right tool for the right job principle” to try to create our toolset of technologies that we are going to use to solve different use cases or patterns that you need to face.
But that agreement and movement also come with its challenge regarding things that we usually don’t think about like Tracing and Observability in general.
When we use a single technology, everything is more straightforward. To define a common strategy to trace your end to end flows is easy; you only need to embed the logic into your common development framework or library all your developments are using. Probably define a typical header architecture with all the data that you need to be able to effectively trace all the requests and define a standard protocol to send all those traces to a standard system that can store and correlate all of them and explain the end to end flow. But try to move that to a polyglot ecosystem: Should I write my framework or library for each language or technology I’d need to use, or I can also use in the future? Does that make sense?
But not only that, should I slow the adoption of a new technology that can quickly help the business because I need to provide from a shared team this kind of standard components? That is the best case that I have enough people that know how the internals of my framework work and have the skills in all the languages that we’re adopting to be able to do it quickly and in an efficient way. It seems unlikely, right?
So, to new challenges also new solutions. I’m already have been talking about Service Mesh regarding the capabilities that provide from a communication perspective, and if you don’t remember you can take a look at those posts:
Integrating Istio with BWCE Applications
Introduction Services Mesh is one the “greatest new thing” in our PaaS environments. No matter if you’re working with K8S, Docker Swarm, pure-cloud with EKS or AWS, you’ve heard and probably tried to know how can be used this new thing that has so many advantages because it provides a lot of options in handling […]
But it also provides capabilities from other perspectives and Tracing, and Observability is one of them. Because when we cannot include those features in any technology, we need to use, we can do it in a general technology that is supported by all of them, and that’s the case with Service Mesh.
As Service Mesh is the standard way to communicate synchronously, your microservices in an east-west communication fashion covering the service-to-service communication. So, if you’re able to include in that component also the tracing capability, you can have an end-to-end tracing without needed to implement anything in each of the different technologies that you can use to implement the logic that you need, so, you’ve been changing from Figure A to Figure B in the picture below:
In-App Tracing logic implementation vs. Service Mesh Tracing Support
And that what most of the Service Mesh technologies are doing. For example, Istio, as one of the default choices when it comes to Service Mesh, includes an implementation of the OpenTracing standard that allows integration with any tool that supports the standard to be able to collect all the tracing information for any technology that is used to communicate across the mesh.
So, that mind-change allows us to easily integrates different technologies without needed any exceptional support of those standards for any specific technology. Does that mean that the implementation of those standards for those technologies is not required? Not at all, that is still relevant, because the ones that also support those standards can provide even more insights. After all, the Service Mesh only knows part of the information that is the flow that’s happening outside of each technology. It’s something similar to a black-box approach. But also adding the support for each technology to the same standard provides an additional white-box approach as you can see graphically in the image below:
Merging White Box Tracing Data and Black Box Tracing Data
We already talked about the compliance of some technologies with the OpenTracing standard like TIBCO BusinessWorks Container Edition that you can remember it here:
OpenTracing support in TIBCO BusinessWorks Container Edition
The past month during the KubeCon 2019 Europe in Barcelona OpenTracing announces its merge with OpenCensus project to create a new standard named OpenTelemetry that is going to be live in September 2019. So, I think that would be awesome to take a look at the capabilities regarding OpenTracing we have available in TIBCO BusinessWorks […]
So, also, the support from these technologies of the industry standards is needed and even a competitive advantage because without needing to develop your tracing framework, you’re able to achieve a Complete Tracing Data approach additional to that is already provided by the Service Mesh level itself.
