Portada
mis comunidades
otras secciones
#1:
Imposible, a mi me han asegurado y re asegurado que los kubernetes y los sistemas distribuidos son la panacea. 
Un articulo muy bueno. Con una reflexión profunda. La mayoría de los proyectos se van al traste cuando la complejidad de los sistemas se vuelve inmanejable. Yo estoy cansado de decir al inicio de los proyectos, que seamos realistas. Y por lo general, los responsables te miran mal, y das la sensación de que el problema es la carencia de conocimientos.
Un articulo muy bueno. Con una reflexión profunda. La mayoría de los proyectos se van al traste cuando la complejidad de los sistemas se vuelve inmanejable. Yo estoy cansado de decir al inicio de los proyectos, que seamos realistas. Y por lo general, los responsables te miran mal, y das la sensación de que el problema es la carencia de conocimientos.
#4:
Esto es lo de siempre, muchos proyectos acaban en fracaso por un innecesario overenginiering
#10:
Dockers y Kubernetes está bien para entornos de desarrollo y para hacer pijaditas pero para cosas serias y ambientes productivos críticos mejor virtualización y ya lo dice el propio artículo y sí, soy administrador tanto de entornos que tienen tanto dockers como kubernetes y virtualizados
#11:
#1 Kubernetes vale para lo que vale, para ambientes productivos vale para servicios chorras no críticos, pero no todos los sistemas distribuidos son kubernetes, y no, los sistemas distribuidos no son una mierda es la base sobre la que funcionan todas las infraestructuras de IT bien montadas, te recomeindo que te leas
Distributed Systems: Concepts and Design
https://www.pearson.com/store/p/distributed-systems-concepts-and-design/P100002013755/9780132143011
cc #9
Distributed Systems: Concepts and Design
https://www.pearson.com/store/p/distributed-systems-concepts-and-design/P100002013755/9780132143011
cc #9
#45:
#10 pues no estoy de acuerdo en absoluto
El paradigma de trabajar con contenedores + kubernetes simplifica las operaciones tanto que sale muy muy muy a cuenta, y es muy facil construir con ello un sistema robusto y altamente automatizado
Otra cosa es que la gente intente meter todo con calzador ahi dentro, que no ... hay cosas que meterlas en kubernetes es complicarte la vida mogollón sin obtener grandes ventajas a cambio
Yo llevo 3 años con kubernetes en producción para muchas cosas y estoy SUPER contento
Otras cosas hemos intentado meterlas y hemos visto que era peor el remedio que la enfermedad, asi que se queda fuera, virtualizado y manejado con las herramientas tradicionales
El paradigma de trabajar con contenedores + kubernetes simplifica las operaciones tanto que sale muy muy muy a cuenta, y es muy facil construir con ello un sistema robusto y altamente automatizado
Otra cosa es que la gente intente meter todo con calzador ahi dentro, que no ... hay cosas que meterlas en kubernetes es complicarte la vida mogollón sin obtener grandes ventajas a cambio
Yo llevo 3 años con kubernetes en producción para muchas cosas y estoy SUPER contento
Otras cosas hemos intentado meterlas y hemos visto que era peor el remedio que la enfermedad, asi que se queda fuera, virtualizado y manejado con las herramientas tradicionales
#20:
Es un artículo poco ecuánime que más bien parece escrito desde odios personales en lugar de la objetividad. Kubernetes tiene indudables inconvenientes, pero también ventajas. Solo hay que tener en cuenta que no sirve para todo, sino solo para ciertos casos de uso.
Por poner un ejemplo claro, el primer "problema" es realmente absurdo. Kubernetes está diseñado para sistemas grandes en los cuales las tres o cuatro máquinas imprescindibles para que el clúster funcione suponen una parte muy pequeña de la infraestructura. Si necesitas un sistema distribuido de cuatro o cinco máquinas y utilizas Kubernetes el problema no es Kubernetes, sino tú por utilizar un software que no está diseñado para tus necesidades. PICNIC.
Por poner un ejemplo claro, el primer "problema" es realmente absurdo. Kubernetes está diseñado para sistemas grandes en los cuales las tres o cuatro máquinas imprescindibles para que el clúster funcione suponen una parte muy pequeña de la infraestructura. Si necesitas un sistema distribuido de cuatro o cinco máquinas y utilizas Kubernetes el problema no es Kubernetes, sino tú por utilizar un software que no está diseñado para tus necesidades. PICNIC.
Comentarios
Imposible, a mi me han asegurado y re asegurado que los kubernetes y los sistemas distribuidos son la panacea.
Un articulo muy bueno. Con una reflexión profunda. La mayoría de los proyectos se van al traste cuando la complejidad de los sistemas se vuelve inmanejable. Yo estoy cansado de decir al inicio de los proyectos, que seamos realistas. Y por lo general, los responsables te miran mal, y das la sensación de que el problema es la carencia de conocimientos.
#1 Un clásico. ¡Usemos esta tecnología, que la usa Google! ¡Si la usa Google será buena idea!
Como si las necesidades del 99% de los proyectos fueran los de Google
#1 Kubernetes vale para lo que vale, para ambientes productivos vale para servicios chorras no críticos, pero no todos los sistemas distribuidos son kubernetes, y no, los sistemas distribuidos no son una mierda es la base sobre la que funcionan todas las infraestructuras de IT bien montadas, te recomeindo que te leas
Distributed Systems: Concepts and Design
https://www.pearson.com/store/p/distributed-systems-concepts-and-design/P100002013755/9780132143011
cc #9
#11 Que si, que la teoría está muy bien. Pero necesitas un presupuesto, y un equipo, un tiempo, y mantener la inversión. Pero al final se matan mosquitos a cañonazos. Que se están montando Web de gestión, para 5 administrativos, con sistemas distribuidos en varias capas y duplicando frontales. Y lo peor, es que la aplicación no tira, porque es tan complicada, que los 2 becarios que han puesto, para mantenerla, no saben por donde meterle mano.
#13 Montar 6 máquinas, con dos webservers (Apache), dos servidores de aplicaciones (JBoss) y una BBDD (Postgresql) sobre linux no es ni caro ni complejo, en donde te vas a dejar la pasta es practicamente en el desarrollo y en el mantenimiento de los servidores (que lo puedes poner en azure o amazonws y seguro que te libras de montar hasta alguna instancia por opciones) y tienes alta disponibilidad y es un sistema distribuido
#15 Y si montas una maquina virtual con IIS, y una BBDD con SQLServer, es más sencillo, te va a dar más rendimiento, y te vas a gastar menos en desarrollo.
#16 También, pero windows es una mierda, aunque reconoczco que vale para lo que vale, sistemas críticos no lo puedes montar así porque ya tienes el IIS de frontal y ejecutando el aplicativo, es muy inseguro, tienes que poner en la DMZ un servidor web, otro IIs o un Apache o similar
#17 El Windows da mucho más rendimiento de lo que te crees, y es más seguro que cualquier otro. El problema es que para sistemas grandes es caro. Por eso se usan otras cosas.
#18 El Windows da mucho más rendimiento de lo que te crees, y es más seguro que cualquier otro.
¿Fuentes para esa afirmación?
#29 Cibeles y Canaletes.
#29 Pués Microsoft. Jope que desconfiado.
#29 Sobre rendimiento, Asp.net Core es uno de los servidores web mas rápidos que existen tanto en Linux como Windows.
https://www.techempower.com/benchmarks/#section=intro&hw=ph&test=plaintext
Sobre seguridad, puedes buscar el número de fallos de seguridad de Windows Server del último año.
No os ancleis en el pasado, Windows ha mejorado mucho, quitaos de la cabeza el Blaster y demas...
#72 ¿Cifras? ¿Comparativas? ¿Un artículo que lo sustente?
Si yo no digo que no, pero me gusta comprobar las cosas, no me basta con unos comentarios cortos en un foro cualquiera.
#72 Mira lo que he encontrado:
https://robertoprevato.github.io/Comparing-Linux-hosted-to-Windows-hosted-ASP-NET-Core-applications-in-Azure-Application-Service-Plan/
«Conclusions
Hosting applications using Linux and Docker in Azure Application Service Plan doesn’t affect negatively the performance of the application, unlike one may guess, given that Windows hosting is more mature. It is actually beneficial, performance-wise, especially for requests returning responses with small bodies.»
#29 stackoverflow funciona principalmente sobre el stack de Windows, con pocos servidores para la cantidad de usuarios y páginas que maneja. No soy yo muy partidario de hablar bien de Windows en servidores, pero hay que ser justo con la realidad. Lo que no quiere decir que sea "mejor". Yo sólo hablo del punto que menciona
gonas cuando dice "da mucho más rendimiento de lo que te crees".
#78 Ok, Stackoverflow funciona en Windows. Creo que es el único ejemplo llamativo. ¿Cuántas otras aplicaciones funcionan sobre Linux u otro Unix? La gran mayoría.
#82 Yo sólo uso Linux en mis servidores, no tienes que convencerme. Sólo estaba poniendo un ejemplo de que han debido mejorar algunas cosas si StackOverflow puede funcionar con la carga que tiene, y sobre Windows + SQL Server. También se apoyan en algún linux para otras cosas.
#84 A ver, que no te quiero convencer de nada, que el hilo viene de esta afirmación:
«El Windows da mucho más rendimiento de lo que te crees, y es más seguro que cualquier otro. »
Dejando de lado el signficado subjetivo de «más de lo que te crees», suena a que da incluso mejor rendimiento, cosa que me rasca un poco. Lo mismo con el tema seguridad. En realidad pido que me convenzan a mi.
#86 No creo que dé más rendimiento, ni que sea más seguro.
Sólo apuntaba a que es "bastante mejor que antes". O debe serlo, porque hace lustros que no lo toco ni con un palo, así que yo no lo sé.
#91 Ah claro, mejor que hace años digo yo que será, sí.
#93 A mí sólo me han "hackeado" un servidor en la vida ( que yo sepa ), y era un IIS. Yo no elegí un servidor Windows, me vino impuesto, y una vez que lo hackearon ya nos dejaron poner un servidor Linux.
#84 Por cierto, sobre StackOverflow siempre queda la duda de si es que el stack funciona muy bien o que la aplicación está diseñada e implementada especialmente bien.
#87 Con ese nivel de carga, ambas afirmaciones tienen que ser ciertas, porque tenían muy pocos servidores.
#29 #18 lo que pasa es que Microsoft tiene que pagar licencias de Windows y por eso des de que compro HoTMaiL los servidores de alta disponibilidad propios van con Linux.
No hay fuentes realistas objetivas
#17 Anda que no hay sistemas gigantes montados con Windows Server, IIS, etc. ¿Porque crees que Azure esta siendo la gallina de los huevos de oro de Microsoft?
Y decir que necesita un Apache delante... Madre mía... Se nota que no tienes ni idea de usar un Windows Server.
Claro que si no sabes usarlo o crees que todo es siguiente, siguiente, siguiente y que Windows Server es igual que hace 20 años... Normal que pienses eso.
#69 Azure funciona en win y linux
#71 Correcto. Pero nadie en su sano juicio usaria Azure para usar solo Linux. AWS es muy superior, facil de usar, etc.
Azure se usa porque es la mejor opción si quieres Windows.
#73 Azure se usa porque hay mucha gente que quiere usar todo el entorno de MS, incluyendo sus plataformas de datos, no solo por el Windows
#69 Y? Quien lo niega, pero no rinden ni igual de bien ni por asomo que equivalentes linux
Azure tiene instancias de todo tipo, de linux también (con apache, tomcat, websphere, en infinidad de productos etc) por eso es una gallina de los huevos de oro no porque tenga windows servers
Microsoft developer reveals Linux is now more used on Azure than Windows Server (2019)
https://www.zdnet.com/article/microsoft-developer-reveals-linux-is-now-more-used-on-azure-than-windows-server/
Y vuelve a leer mi comentario bien por favor, que he dicho "tienes que poner en la DMZ un servidor web, otro IIS o un Apache o similar" y esto se hace para securizar, si tú no tienes ni idea de que esto es necesario para tener un entorno lo más seguro posible no es mi problema, llevo 20 años trabajando de administración de sistemas en entornos que requieren una máxima seguridad y no poner un webserver por delante del servidor de aplicaciones es un fallo de los más gordos y una diana en tu culo diciendo "metemela aqui para hackear mis sistemas", aunque es cierto que existen alternativas como poner un ISA Server, pero lo mejor es siempre poner un webserver=>servidor de aplicaciones => base de datos; si quieres más seguridad la pones por encima del webserver, ya sea un IIS, Apache, nginx o lo que te de la gana mientras actue de webserver exclusivamente y sin acceso directo a la BBDD
A lo mejor el que no sabes usarlo eres tú
#15 Web de gestión, para 5 administrativos
Respuesta:
Montar 6 máquinas, con dos webservers (Apache), dos servidores de aplicaciones (JBoss) y una BBDD (Postgresql)
Más máquinas que administrativos,
Me empieza a recordar el chiste de los remeros, pero cambiando directores por máquinas.
#47 He pensado lo mismo, luego hablas de moscas a cañonazos y te dicen que no tienes ni idea de administración y blablabla
#13 Es que si no tienes un equipo suficiente para gestionarlo, no es que necesites kubernetes, es que tendrías que plantearte para que quieres un sistema distribuido.
#10 #11 pues hay infinidad de organizaciones que lo utilizan para servicios muy críticos, y en ocasiones con gran éxito.
#19 No, si nosotros también lo tenemos para algunas cosas, así va de mal que hay que reiniciar instancias cada semana o se cuajan, ya por no hablar de que los IIS que están en la DMZ son inseguros, el IIS hace de webserver y servidor de aplicaciones a la vez, es decir que si alguien lo ataca y toma el control tiene acceso directo contra la BBDD, por eso es mejor que haya otro delante y que el de la DMZ haga de webserver y el interno de AppServer, por otro lado las apps .net son una castaña pero bueno no no es que el java vaya muy allá tampoco
Ya te digo que nosotros los tememos pero son para basurillas, lo crítico está todo sobre linux
#22 si se cuajan no tiene por qué ser culpa de Kubernetes necesariamente. Puede que la aplicación funcione mal o que haya cosas mal configuradas.
Lo de la DMZ, tal como lo has explicado, no entiendo bien cómo está configurado. ¿Que hay nodos de Kubernetes expuestos?
#25 Me refería a las instancias en IIS que las aplicaciones .net se van a la mierda cada poco, no hablaba de kubernetes en este caso
#49 Seguramente esas aplicaciones están mal hechas. No des la culpa a .net del mal uso que hacéis del Framework.
#77 Hacemos? Yo soy de sistemas, en todo caso "harán los de desarrollo"
#11 >> Kubernetes vale para lo que vale, para ambientes productivos vale para servicios chorras no críticos.
Madre mia lo que hay que leer en Meneame y eso que yo no soy en mayor fan de Kubernetes
#58 Intenta ponerlo en un Banco ( en un sistema crítico como la web de particualares, de empresas o el broker) y a ver que te dice cualquier experto en sistemas, que un banco no es una tienda online que si le das a un click y lo que estás comprando se va a la mierda no pasa nada (grave) ahora dale un click a una transferencia de millones y que un pod le de por destruirse, la transferencia se ha hecho o no? En donde está?
Y te lo digo porque trabajo en un banco y no se les ocurre tocar dockers y Kubernetes na más que para experimentos con gaseosa de los de arquitectura
#100 pues yo trabajo en un banco y sí se usa kubernetes entre otras muchas cosas.
¿Quieres saber si se ha hecho o no la transferencia? Pues le preguntas al core, que la web de particulares, empresas o la del broker es un simple canal para operar con el core.
Otra cosa es poner un core bancario con kubernetes... pues mira, yo no sé si lo haría, pero es un ejercicio de ciencia ficción ya que el único banco en España que no tiene montado el core en un mainframe es ING y no tengo ni idea de cómo lo tienen montado.
#100 Creeme, me he pasado la ultima decada trabajando para Amazon Web Services y Google Cloud. Todos los bancos tienen algun "workload" en un gestor de contenedores (ECS, Kubernetes, lo que sea).
Yo no estaba en la organizacion de ventas, pero como te dice #104 no mueves el core bancario, pero los distintos canales que ofrecen experiencia de usuarios es de las primeras cosas que se mueven.
#1 es el pasar de las charlas al mundo real...
#1 Kubernetes está muy bien para aplicaciones que requieren mucha elasticidad: es decir, escalar y desescalar la aplicación rápidamente y distribuída en varios nodos. Un ejemplo son las aplicaciones de móvil tipo "runedia", que típicamente necesitan soportar una gran carga en momentos puntuales del día (cuando la gente sale a correr, por ejemplo), y pueden redefinirse los deployments con más réplicas on-demand.
Para CI/CD en general, o DevOps, no necesitas Kubernetes, con Docker te vale (desde mi humilde punto de vista)
#1 El soñar despierto en los proyectos, el tener 1 tio que sabe como funciona y el resto no, y la falta de documentacion.
Los 3 principales problemas.
Esto es lo de siempre, muchos proyectos acaban en fracaso por un innecesario overenginiering
#4 Si vas a usar barbarismos al menos escríbelos bien.
#6 take it easy bro
#44 Ya, he sonado un poco borde, pero me chirría tener que leer todo el día palabras extranjeras sin necesidad.
Si sirve de consuelo le he votado positivo, estoy de acuerdo.
Dockers y Kubernetes está bien para entornos de desarrollo y para hacer pijaditas pero para cosas serias y ambientes productivos críticos mejor virtualización y ya lo dice el propio artículo y sí, soy administrador tanto de entornos que tienen tanto dockers como kubernetes y virtualizados
#10 La tendencia es más bien la contraria.
Si, virtualizar esta muy bien para crear rápido un host igual que tendrías si siguieras usando servidores físicos, pero en cuanto el sistema adquiere una complejidad real, el tiempo perdido entre despliegues y "orquestaciones" pasa a ser inasumible. Por no hablar de los balanceos de carga, healtchecks y demás que en un sistema kubernetes bien montado no son una preocupación y en uno virtualizado siempre hay que andar investigando.
#30 las tendencias no tienen porque ser vuenas por desgracia
#33 Ni malas, pero hay un motivo para esta.
#40 yo tengo balanceo de carga en un sistema mio, es de juguete pero aun asi tengo picos de unos 2000 usuarios simultaneos y no uso kubernetes ni docker, snapshots de DO y arreando, evidentemente no soy especialista en esto (me pase de sistemas a desarrollo hace años) pero vamos que puede seguirse montando mierdas estables sin tener que ir a docker... tampoco digo que no este bien ni que no tenga sentido usarse, simplemente que no hace falta meterlo en todo
#46 Claro, para una persona tampoco vas a liarte a montar kubernetes. Docker igual si, por comodidad. Si es un proyecto personal puedes incluso permitir que AWS o donde tengas la infraestructura manejen el balanceo por muy poco dinero (es cuando se usa mucho cuando suele salir rentable tener uno)
#59 si si tiro por DO (digital.ocean) usaba el round robin por defecto pero termine cambiandolo
#33 diossssss acabo de ver esa v joder puto movil!!! Encima no puedo editar ya :,(
#33 Te he pegado un negativo por escribrir "vuenas". Esta noche no duermo. Por favor, aprende a escribir.
#75 es el puto movil el teclado no me hago con el.... pongo . En lugar de espacio ... espacio en lugar de n, b en lugar de v etc... pero si, merecido negativo de hecho lo he dicho en 42
#81 Bueno, no pasa nada. Me dio un sobresalto y escozor de ojos. Por respuesta, reconocimiento y actitud te "positivizo" ahora mismo.
#97 No no que no tiene perdon esa V jeje si es que hasta a mi me ha hecho sangrar los ojos...
#30 Sí en kubernetes esirectamente no puedess investigar, directamente se te va a la mierda el pod y desaaparecen los logs
PD: No en serio, ya se que puedes montar logging externo pero eso es lo que termina complejizando todo que luego dependes de cosas externas
#55 La idea es evitar tener que acceder al pod en la medida de lo posible, tener algo que almacene y analice los logs, ya sea el propio sistema de tu proveedor de cloud o te lo montes tú (kibana como open-source, logentries si prefieres pagar...).
Y si, aumenta el nivel de complejidad, pero si tu proyecto tiene una infraestructura suficientemente grande, compensa. Si no la tiene, mejor no complicarse la vida
#10 pues no estoy de acuerdo en absoluto
El paradigma de trabajar con contenedores + kubernetes simplifica las operaciones tanto que sale muy muy muy a cuenta, y es muy facil construir con ello un sistema robusto y altamente automatizado
Otra cosa es que la gente intente meter todo con calzador ahi dentro, que no ... hay cosas que meterlas en kubernetes es complicarte la vida mogollón sin obtener grandes ventajas a cambio
Yo llevo 3 años con kubernetes en producción para muchas cosas y estoy SUPER contento
Otras cosas hemos intentado meterlas y hemos visto que era peor el remedio que la enfermedad, asi que se queda fuera, virtualizado y manejado con las herramientas tradicionales
#45 Bien, venía a poner mi comentario, pero es casi el mismo que el tuyo. No hay que volverse loco, hay que pensar bien las cosas, ir poco a poco troceando monolitos, y sobre todo pensar mucho antes lo que quieres y lo que necesitas. Si tienes mucha complejidad, transacciones, etc. puede ser peor el remedio que la enfermedad, y te tienes que meter en colas, event sourcing, CQRS, etc. pero si no tienes tanta complejidad es incluso mucho más sencillo con Kubernetes. Y si puedes optar, por el precio, a un Openshift, pues más sencillo todavía.
Es un cambio de paradigma, de forma de pensar, y hay que analizar los pros y contras, pero en el 90+% de las empresas va a tener mucho sentido empezar a meterse en esto.
#10 Muchas aplicaciones móviles de gran éxito están basadas en contenedores (porque simplifica mucho el ciclo de desarrollo) y una capa de orquestación (k8s, OpenShift, etc) para poder escalar la aplicación de forma sencilla cuando la demanda lo requiere.
Es un artículo poco ecuánime que más bien parece escrito desde odios personales en lugar de la objetividad. Kubernetes tiene indudables inconvenientes, pero también ventajas. Solo hay que tener en cuenta que no sirve para todo, sino solo para ciertos casos de uso.
Por poner un ejemplo claro, el primer "problema" es realmente absurdo. Kubernetes está diseñado para sistemas grandes en los cuales las tres o cuatro máquinas imprescindibles para que el clúster funcione suponen una parte muy pequeña de la infraestructura. Si necesitas un sistema distribuido de cuatro o cinco máquinas y utilizas Kubernetes el problema no es Kubernetes, sino tú por utilizar un software que no está diseñado para tus necesidades. PICNIC.
#20 Pues eso dice el artículo. Que Kubernetes no es ni para todo ni para todos.
#21 tienes razón. Me he precipitado en el diagnóstico. No había leído los primeros párrafos con atención. Venía condicionado por algunos artículos que había leído previamente donde se decía que Kubernetes era una basura que no servía para nada.
#23 Es un producto complejo que requiere mucha planificación y personal especializado. No puedes decir "voy a hacer un proyecto con Kubernetes" y mandar a tres becarios y un "senior" de Java en plan consultora española.
Ahora, si tienes la necesidad real (una intraweb de un ministerio por ejemplo no es una necesidad real) y los recursos tanto de máquina de humanos pues por supuesto Kubernetes es un gran producto que resuelve muchos problemas.
#26 correcto. El problema es que la administración de sistemas está mal gestionada en muchísimas entidades y se le asignan pocos recursos porque es un gasto. Entonces cuando hay que administrar algo complejo como Kubernetes hay problemas, pero la culpa no es del software.
#28 estoy cansado de hablar con empresas del top (de europa y usa) y que no sepan ni usar su propio MDM... es una pena lo poco que se valora un buen sysadmin (llamadlo X si quereis) en muchos sitios
#20 Una de las funcionalidades de Kubernetes es gestionar aplicaciones hechas contenedores y todo lo que conlleva. Por ejemplo, encargarse de que los clientes accedan al puerto 80 y enrutar sus peticiones a los contenedores correspondientes (primero accediendo al pod correcto).
En esos casos entiendo que podrías sacarle partido con una sola máquina, donde están todos los contenedores (y pods) que gestionar Kubernetes).
Sin embargo, supongo que habrá otros software que hagan eso mismo sin la complejidad de Kubernetes. Pero el caso es que siempre que oído hablar de estas cosas siempre remiten a Kubernetes. ¿Qué otras opciones habría?
#37 si tienes un host o pocos puedes hacerlo directamente con Docker, así como otras opciones como Swarm que proporcionan tolerancia a fallos. Kubernetes es para cosas muy grandes.
Kubernetes, Docker, contenedores....he tratado de buscar qué es en su página oficial pero me quedo como estaba, ¿Alguien podría dar una explicación para legos en materia?
#41 Docker son contenedores. Por ejemplo, tú quieres montarte un servidor web apache.
Si lo hicieras de la forma tradicional necesitarías montar un servidor -Físico o virtual-, instalarle el SO y luego montar el apache encima.
Si dockerizas el servidor apache, lo que estás haciendo es meterlo en un contenedor que va a tener lo esencial para correrlo y va a usar los recursos (Kernel, etc) de la máquina anfitriona. De esta forma es más ligero y tu puedes desarrollar tu docker en tu casa, con la versión 2.4 de apache aunque en la máquina anfitrioina, solo disponga de apache 2.2 en sus repositorios.
Kubernetes digamos que es un cluster dedicado a correr este tipo de contenedores, donde te dan balanceadores para que si un contenedor estaba corriendo la maquina 1 del cluster se levante en la 2, si es que la máquina 1 ha muerto. Digamos que es una capa para hacer más potente todo el tema de contenedores.
¿Es guay? Si, mucho, pero también es muy complejo, y yo, a no ser que tuviera que montar un huevo de microservicios preferiría montarme un apache en una maquina virtual pequeña, porque es trivial.
Lo que pasa que al final la gente quiere hacer cosas guays. Como pasearse por el pueblo con un Ferrari.
Hay entornos para los que merece la pena, otros para los que no, pero los vendehumos siempre te venderán lo complicado para intentar cobrarte 500 mil euros por el montaje de una arquitectura compleja cuando para lo que tu quieres te vale con un seat y te sobra.
#48 Te enlace en #61 sin querer, ya he editado
#61 Soy estadístico, no informático. Eso hace que si bien desconozco profundamente muchos de los aspectos más complejos de la informática, sí he cacharreado lo suficiente como para hacer mis cosillas como programas en c++ de miles de líneas con punteros, clases y herencias, por ejemplo. Y siempre he tenido la sensación de que si bien en la estadística siempre se tiene a la simplificación, a encontrar el camino alternativo siguiendo la lógica matemática ancestral del "trabajar para no tener que trabajar", en el mundo de la informática/programación parece que se hace justo lo contrario, en un ejercicio de eterno y rebuscado over-engineering, un eterno deseo de abarcarlo todo sin renunciar a nada donde siempre está justificado que un hola mundo tenga tropecientas líneas de código. No sé, quizá sean cosas mías...
#94 En muchos casos, estas soluciones son más sencillas.
Por ejemplo. El famoso Big Data. Son clúster de bastantes máquinas con memoria y cpu's y lo que se hace es desarrollar algoritmos que pueden partirse en cachitos, y darles una parte a cada maquina en "contenedores". Realmente esto simplifica muchos escenarios.
Los dockers por ejemplo, para ciertos entornos no críticos también. Porque si funciona en tu "local" también funciona en tu cliente, porque es un paquetito que se autocontiene, no puede haber problemas de que esta biblioteca tal... Etc.
¿Cuando vienen los problemas? Cuando se quiere diseñar arquitecturas de Big Data para problemas que no los necesitan. O cuando quieres montar kubernetes para algo que con dos máquinas te sobra.
Yo creo que al final es un tema de ego empresarial. Si tal empresa lo ha montado, yo que soy grande no voy a tener menos. Y ahí van todos, a por algo que no necesitan porque otro lo ha hecho, y puede que este otro que lo hizo, reformulo toda su arquitectura para simplificarla en un unico punto convergente, y aquí si tenía sentido.
De todas formas yo estoy contigo, y me dedico a esto. La gente debería simplificar. Soy fan total de la filosofía KISS "Keep It Simple, Stupid"
#41 ¿Qué distribución tienes instalada? Es por saber cómo explicarlo.
Pues yo creo que kubernetes usar es bastante simple si realmente necesitas resolver los problemas que kubernetes resuelve. No creo que haya alternativas mucho más fáciles.
Otra cosa es que lo que necesites sean 2 HAProxies apuntando a 2 jbosses que consumen 2 postgresql y vayas sobradísimo, pero kubernetes juega en otra liga donde hablamos de mucha más escala y de despliegues más rápidos.
La queja de que es grande, y que son muchas líneas de código: Si y no, el core de kubernetes es complejo, incluye un type system en el runtime, servidores agregados, gestión de APIs, gestión de permisos, etc. pero mismo tiempo es extremadamente modular y navegar por el código es bastante fácil.
Hay partes muy complejas (sobre todo en kubelet y apiserver) pero por lo general es fácil navegar por el código en parte por golang y las herramientas que tiene (véase gpls y compañía).
Los clientXXX.go tienen una interfaz estándar, es fácil leerlos y fácil encontrarlos incluso con CRDs y apiservers agregados.
Kubectl es el cli mejor escrito que he visto con diferencia (tanto por consistencia y modularidad por como calidad de uso para el usuario).
Etcd también es complejo de cojones.
La complejidad del desarrollo me parece una crítica acertada, aunque hay bastantes opciones para tener un kubernetes en local.
La complejidad de la arquitectura, sinceramente no lo veo tan complejo si lo comparamos con las alternativas que resuelven los problemas que kubernetes resuelve, OpenStack me parece muchísimo más complejo (y trabajé en OpenStack algo más de un año)
Sobre la esalabilidad, el diga que es facil escalar una máquina verticalmente, coger 8 TiB de RAM y ya está directamente no tiene ni puta idea ni se ha pegado con NUMA en su vida. Las máquinas grandes siempre traen problemas que uno no espera. Sobre escalar con heroku, pues como escalar con un kubernetes gestionado por un tercero.
Aunque se base en la licencia Apache 2.0 pertenece a una gigante multinacional. Existen otras alternativas.
pero que dice este loco, si no usas kubernetes + blockchain + react tu aplicacion ya es legacy y tus angel se iran a alguna otra startup
Yo pensaba que me estaba quedando muy anticuado por no saber de Docker, kubernetes y todas estas moderneces, pero conforme voy aprendiendo sobre el tema (muy poco aún), todas las señales que recibo son "no lo uses en tu empresa (tenemos varios servidores con aplicaciones web). De hecho, tenemos una aplicación montada en AWS y no me termina de convencer... la documentación es pobre y parece más para comerciales que para desarrolladores
#35 Mi equipo gestiona una aplicación comercial que solía correr en 200 instancias EC2, totalmente migrada a Kubernetes desde hace meses y ningún problema. Requiere inversión y gente buena que lo entienda y lo sepa configurar bien, eso sí.
#35 Aws para comerciales... Si, te estas quedando atrás, unos 8 años atrás. Nadie duda de las ventajas de los clouds públicos.
#68 me refiero a que la documentación que da Amazon cuando estás intentando averiguar qué tipo de instancias necesitas es poco clara, me recuerda a las "landing pages" de una cárnica, con mucho lenguaje vago.
AWS funciona, pero estamos teniendo algunos problemas y resulta complicado saber qué pasa sin consultar a expertos... de hecho hemos tenido que delegar la configuración a una consultora porque íbamos con prisa (todo para ayer) y el departamento de informática de mi empresa somos tres personas y tenemos que llevar el desarrollo, mantenimiento y soporte a usuarios haciendo malabares.
A mi me llaman dinosaurio por no querer recomendar todos estos juguetes que facilitan la vida en macroproyectos con millones de usuarios, pero sin embargo las cutre consultoras de turno recomiendan a empresas de 100 empleados con 50usuarios simultaneos para su aplicación.
Vamos, elegir la herramienta en base al problema que tienes, no en base a la moda de turno...
Parece un artículo de la competencia.
Todo tiene sus aplicaciones, en ni empresa hemos pasado de maquinas virtuales, a docker y ahora Openshift, si , se añade otra capa mas encima de Kubernetes por parte de RedHat y como respaldo tenemos AKS (Kubernetes en cloud de microsoft) con lo cual añade otro componente más que es una herramienta de despliegue que sirva para ambos. En nuestro caso hemos elegido HELM.
En nuestro caso es una plataforma que tiene horarios valle y picos de que pueden superar los cientos de miles de usuarios, por ejemplo durante un partido de fútbol.
Es mas complejo K8s que docker? si, en nuestro caso nos facilita la vida ? si, a pesar de las complejidades añadidas donde antes teniamos corriendo 24 dockers ahora vemos que en algunos momentos con 2 nos basta y llegamos a escalar a 15 o 16. El tema de la red también es mucho más facil ahora. Podemos autogestionarnos de manera mas sencilla y tenemos una visión mas global y centralizada. En mi opinión el que ha escrito el articulo ha considerado que en su caso no es productivo pero como digo es solo su caso, no el nuestro
Yo creo que lo estais enfocando mal.
Hay mismo hay 3 opciones eres una empresa pequeña o desarollas para una empesa pequeña tiras de la nube,. Tu no tienes que tener la infraestructura desarrolas tus docker y microservicios y lo montas en la nube que quieras.
Eres una empresa grande miras que te sae más rentable. Puedes tener tu kubernetes si quieres para desarrolllar. Pero a la larga te sigue saliendo caro mantner tu propiesta infraestructura de kubernetes. Nuevamente debes tirar del servicio de cloud.
Quien entonces debe montar su kubernetes en producción. Pues quien por motivos de seguridad no puede fiarse de una nube de terceros.
Y en eso hablamos de proyectos de defensa, para la ESA o proyectos para empresas muy grandes.
Aqui puedes tener tu infraestructura propia.
Lo que esta claro que todo va a estar en la nube y por eso hay que tirar por microservicios.
El problema que hay con los entornos productivos es la falta de realidad y el uso de modas, cuando deberían regirse por casos de uso y por el dinero que se tiene.
Si tienes una solución tradicional que te cubre tus necesidades a un coste inferior, montalo. Tengo montados entornos clústers de Big Data de unos 10 nodos que podrían sustituirse con una mysql en HA de 2-3 nodos. Pero en su día mola menos.
Partiendo de la base de que todos reconozcan Docker como un avance enorme, la evolución natural es usar un gestor de contenedores.
a) Un gestor gestiona, ayuda y facilita las tareas comunes, eso es un gestor.
b) Para usar un gestor hay que saber usarlo, como todo.
El articulo me parece pobre, y los argumentos no tienen mucho sentido. En lo único que tiene razón es que para levantar una aplicación no te hace falta Kubernetes, aunque si se piensa....
c) Para aprovechar un gestor tienes que tener algo que gestionar.
Y ya basta de obviedades
Docker está muy bien, tanto para desarrollo como para muchas cosas de producción cuando ya le tienes pillado el truco. Y cuanto más lo uso más aprendo y para más cosas me vale.
Pero Kubernetes es un salto que no puedo... cada vez que lo pruebo me doy con una pared. Y cada vez que supero esa pared hay detrás otra más alta.
Yo espero que Docker Swarm tire para adelante y sobreviva a los cambios de dueños etc... porque a mi Swarm me da justo lo que necesito.
#34 Kubernettes para lo que está ahí es (entre otras cosas) para que cuando tengas que levantar 200 dockers que hacen 200 cosas distintas con 200 configuraciones diferentes no quieras pegarte un tiro.
Si no necesitas 200 contenedores no necesitas Kubernettes. O algo así más o menos, no se donde poner el límite, pero está claro que para una aplicación "normalita" que no esté basada en microservicios y funcione con 3 ó 4 servidores no es necesario para nada.
Como todo... nada es la perfección. Pero para mi pasar a docker fue un salto enormemente gratificante en todos los sentidos. Usar swarm más de lo mismo y pasar a Kubernetes más aún. Yo particularmente no encuentro ninguna de las cosas que dice el artículo como ciertas. De las críticas que hace me da la sensación de que hay un gran desconocimiento de Kubernetes por parte del autor.
Cuando Menéame era un lugar de técnicos, está sería una noticia con comentarios interesantes. Ahora solo hay ejpertos políticos y cuñados a sueldo
#2 Putos podemitas del VOX.
#2 ¿eres consciente de que la noticia se ha publicado hace veinte minutos y que nadie ha hablado de política?
#5 nadie no, él ha sido el primero en hablar del tema... y en el segundo comentario...
#2 Y en lugar de comentarios interesantes, te tenemos a ti.
#8 y a ti!
#2 meneame está mucho mejor ahora lleno de usuarios de abril de 2020