Desde 2003, he usado como mi herramienta principal para desarrollar aplicaciones y servicios. Hace diecinueve años, me impresionó tanto la pequeña cantidad de RAM requerida para usar el IDE como las capacidades de refactorización incluidas con la versión 1.x. IntelliJ Desarrollar en Java no requiere que use el producto IntelliJ IDEA. Otros desarrolladores en mi proyecto actual usan Eclipse o VS Code, pero estas herramientas no son necesarias. Cuando pueda escribir sus componentes, servicios y aplicaciones con un editor de texto simple y una sesión de terminal, terminará con el mismo código Java compilado. Entonces, ¿por qué gasto el dinero en IntelliJ todos los años? Porque IntelliJ IDEA está diseñado para facilitar las cosas a los desarrolladores, lo que equivale a que yo sea mucho más productivo. Por ejemplo, hacer clic con el botón derecho en una clase me brinda la opción de reubicar la clase en cuestión de segundos. Cuando IntelliJ encuentra una oportunidad para eliminar el código duplicado, crea el nuevo código compartido y actualiza correctamente las ubicaciones que dependen del método centralizado. IntelliJ también es una excelente fuente de validación durante las revisiones de código. Si bien este ejemplo puede parecer un poco elemental, me pregunto por qué más ingenieros de software no adoptan un enfoque similar al crear sus servicios. Servicios Spring Boot y Kubernetes Supongamos que su equipo de características ha estandarizado el uso de para los servicios de API. Como resultado del arduo trabajo y el diseño detallado de su equipo, los consumidores públicos consideran que sus API son exitosas. Su organización decide utilizar para estos servicios. Spring Boot Kubernetes Para cada servicio Spring Boot que desarrolla su equipo, así es como se ve el ciclo de vida de alto nivel: Se inicializa un servicio Spring Boot y se agrega un código personalizado. Ese servicio se incluye en un contenedor en una imagen de , que finalmente se implementa en Kubernetes. Docker Al utilizar Kubernetes, obtenemos las siguientes ventajas: Una colección de contenedores Docker basados en Spring Boot se colocan en un "Pod" para actuar como una sola aplicación. Esto permite que cada servicio Spring Boot se centre con precisión en un aspecto determinado de la API resultante. Se pueden agrupar uno o más pods para formar el servicio de API resultante, que se puede configurar para la detección, la observabilidad, la escala horizontal y el equilibrio de carga. Las actualizaciones continuas y las implementaciones canary se utilizan para lograr una experiencia estable para el consumidor. Si está interesado en usar Kubernetes con Spring Boot, consulte la siguiente URL: Spring Boot Kubernetes Basándonos en el éxito de estas populares API, imaginemos que a los líderes ejecutivos les gustaría monetizar los servicios para obtener ingresos de los consumidores más activos. Todavía estará disponible un nivel gratuito, pero se introducirán límites en el uso de la API. Si bien el equipo podría implementar alguna lógica personalizada en el nivel de Spring Boot, esto no tiene sentido. Lo que necesitamos es una forma centralizada de manejar este nuevo requisito. Controlador Kong Ingress al rescate El año pasado, comencé a familiarizarme con la suite de productos como parte de un estado de solución a largo plazo para uno de mis clientes. El escenario que describí anteriormente refleja situaciones que he encontrado en los últimos cinco años: la centralización de componentes comunes es clave para una implementación exitosa de microservicios. Kong Si quieres leer más sobre Kong, echa un vistazo a mi publicación del pasado mes de mayo: Cómo dejé de codificar componentes de servicio repetitivos con Kong Para el caso de uso mencionado anteriormente, podríamos manejar los siguientes componentes en el nivel de puerta de enlace API: Registro de aplicaciones (key-auth) Limitación de velocidad Registro centralizado Dado que Kong Gateway es de código abierto y un "líder" en el Cuadrante Mágico de Gartner de 2021 para la gestión de API de ciclo de vida completo, Kong Gateway es una forma segura de manejar estos componentes comunes. Saber que Kong también proporciona un controlador de entrada para usar dentro de Kubernetes valida aún más la decisión del producto. Puede encontrar todo lo que necesita para comenzar con Kong Ingress Controller (KIC) en esta página de GitHub: Controlador de entrada Kong para Kubernetes La siguiente ilustración muestra el diseño deseado para los dos servicios: Las solicitudes llegan a Kubernetes para el servicio API n.° 1 o n.° 2. El controlador Kong Ingress intercepta las solicitudes y valida la clave API proporcionada. Con base en esa información, el controlador determina si el consumidor que realiza la solicitud ha excedido su límite de solicitud. Si no se ha excedido el límite de frecuencia, la solicitud se envía al servicio correspondiente. Sin embargo, si se supera el límite de velocidad, se devolverá una respuesta HTTP 429 (demasiadas solicitudes). En todos los casos, el módulo de registro se puede configurar fácilmente para realizar un seguimiento de todas las solicitudes entrantes, incluidos todos los metadatos proporcionados por el consumidor de la API. El valor de este diseño Cuando damos un paso atrás y observamos la arquitectura y el diseño resultantes, vemos rápidamente los beneficios: Los servicios de Spring Boot son verdaderos microservicios, cada uno enfocado en un solo aspecto de la API. Docker permite que los servicios de Spring Boot sean independientes y se distribuyan en cualquier punto del ciclo de vida del desarrollo. Kubernetes brinda la capacidad de agrupar esas imágenes de Docker con fines específicos en Pods, que actúan como una sola aplicación. Esos pods luego se agrupan para aparecer como servicios API en nuestro ejemplo. Los componentes compartidos, como el registro de aplicaciones, la limitación de velocidad y el registro, existen en una ubicación centralizada dentro de Kong Gateway. Kong Ingress Controller se convierte en la capa de middleware entre Kong Gateway y Kubernetes para aprovechar todos los componentes compartidos. Como resultado de este modelo, los desarrolladores del equipo de características que trabajan en los servicios de Spring Boot solo necesitan concentrarse en el trabajo proporcionado por el propietario del producto para mejorar o ampliar el servicio. Estos desarrolladores no necesitan preocuparse por las claves API, la limitación de velocidad o cualquier otro componente compartido administrado en otro lugar. Los ingenieros de DevOps que respaldan la implementación de Kubernetes tampoco tienen que diseñar ningún aspecto de diseño personalizado para manejar esos componentes compartidos. Esto se debe a que Kong Gateway está diseñado para adaptarse a esas necesidades y funciona bien a través de Kong Ingress Controller. Conclusión Desde 2021, he estado tratando de vivir de acuerdo con la siguiente declaración de misión, que creo que puede aplicarse a cualquier profesional de TI: “Concentre su tiempo en ofrecer características/funcionalidades que amplíen el valor de su propiedad intelectual. Aproveche los marcos, productos y servicios para todo lo demás”. -J. Vester Al comienzo de esta publicación, hablé sobre cómo prefiero IntelliJ IDEA sobre un editor de texto y una sesión de terminal. En realidad, la razón central se relaciona directamente con mi declaración de misión personal. El producto IDEA me permite concentrarme en las cosas correctas; mientras tanto, maneja las tareas repetitivas relacionadas con la escritura del código fuente original. De manera similar, Spring, Docker, Kubernetes y Kong han proporcionado soluciones y marcos para trabajar con la misma misión. Cada aspecto mencionado anteriormente se puede rastrear hasta una única fuente de verdad para un elemento determinado. Como resultado, no hay duplicación de servicios o funcionalidades en todo el panorama de aplicaciones. Si se encuentra implementando el mismo proceso por segunda vez, sin duda es hora de considerar refactorizar su diseño. Si su nivel de servicio cae en un modal similar al que he discutido aquí y no está utilizando Kong Gateway o Kong Ingress Controller, ciertamente deberían estar en su lista de productos para revisar cuando esté listo para refinar su diseño de servicio. ¡Que tengas un gran día!

Initialized

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Making security fun one episode at a time

Cómo usar el controlador Kong Ingress con Spring Boot Services

Cómo usar el controlador Kong Ingress con Spring Boot Services

Demasiado Largo; Para Leer

Company Mentioned

John Vester

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

Cómo usar el controlador Kong Ingress con Spring Boot Services

Demasiado Largo; Para Leer

Company Mentioned

John Vester

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS