por
pobrecito hablador
el Jueves, 05 Diciembre de 2013, 00:01h
(#1351261)
En nuestro caso, como ya te he comentado, es más importante la estabilidad que las novedades. Y cuando me he referido al soporte de HP y Oracle, me has malinterpretado porque yo no hablo de soporte hardware. Hablo de software que se están pagando licencias y un soporte que de ser una Gentoo, no lo cubrirían puesto que no garantizan su funcionamiento en dicha distribución.
Si nos llega una incidencia de máxima prioridad tenemos 24 horas para resolverla. En esos momentos es muy importante saber la razón de porque los servicios están cayendo. En esos momentos tener controlados los parches que se metieron, las actualizaciones de los servicios, etc... Es vital, y una vez que se tiene una idea del problema, sino es código nuestro, reportarlo lo más rápidamente posible. Si hemos tenido caídas de los servidores por pequeños bugs del garbage collector de la máquina virtual java, con actualizaciones como pasar de una 1.6 update 15 a una java 1.6 update 22, que tras semanas de aparentemente funcionar bien poco a poco iban degradándose y saltaban todas las alarmas de consumo de memoria, como vamos a andar mezclando paquetes estables con inestables. Cuantas veces por añadir nuevas funcionalidades han metido bugs nuevos.
Y no tiene porque ser java, puede ser que alguien para meter un servicio nuevo requiera meter una nueva versión de alguna biblioteca de python, actualicen el paquete en el servidor y dejen de funcionar otros servicios porque estaban pensados para funcionar con otra versión de la biblioteca.
Meter un framework nuevo por la razón de meterlo nuevo, no es precisamente de buen ingeniero de software. Hay que analizar los pros y los contras, y yo desde luego en un servicio de máxima criticidad no voy a meter algo nuevo por ser lo más novedoso. Es como si me empeño en meter python 3 en vez de usar python 2.6 o la 2.7 por mis huevos, y no por razones objetivas, y luego resulta que las bibliotecas que usamos no están portadas o dan fallos con la versión de python3.
Los desarrolladores hacen nuevas versiones, introducen nuevas funcionalidades y con ellas aparecen nuevos bugs, reaparecen otros produciéndose regresiones, etc.. Si ya a veces parches que solo corrigen bugs introducen nuevos no es lógico cambiar a una nueva versión porque metan funcionalidades que no usas.
Vuelvo a repetir que no quiero desmerecer a la distribución Gentoo, ni pienso que hagan mal las pruebas de integración. Pero lo que no puedo hacer es poner un bug y que me lo resuelvan cuando les de la gana ya que por muy buenos que sean no tienen que tener las mismas prioridades que yo, y al no ser de pago no están obligados a nada, cuando yo lo que necesito es que me contesten a las pocas horas. Es por eso lo de mi comentario original, Centos para entornos de prueba y maqueta, y RedHat para producción.
Si no necesitas soporte, si tus entornos no son de máxima criticidad, en los que una caída de unos minutos vaya a suponer un perjuicio económicos muy grande pues entiendo que optes por otras soluciones que además serán mucho más baratas, pero comprende que no todos los proyectos tienen los mismos requisitos ni todos los contratos con clientes tienen las mismas penalizaciones en caso de fallo de servicio.
Re:Aún hay gente que usa distribuciones basad
(Puntos:0)Si nos llega una incidencia de máxima prioridad tenemos 24 horas para resolverla. En esos momentos es muy importante saber la razón de porque los servicios están cayendo. En esos momentos tener controlados los parches que se metieron, las actualizaciones de los servicios, etc... Es vital, y una vez que se tiene una idea del problema, sino es código nuestro, reportarlo lo más rápidamente posible. Si hemos tenido caídas de los servidores por pequeños bugs del garbage collector de la máquina virtual java, con actualizaciones como pasar de una 1.6 update 15 a una java 1.6 update 22, que tras semanas de aparentemente funcionar bien poco a poco iban degradándose y saltaban todas las alarmas de consumo de memoria, como vamos a andar mezclando paquetes estables con inestables. Cuantas veces por añadir nuevas funcionalidades han metido bugs nuevos.
Y no tiene porque ser java, puede ser que alguien para meter un servicio nuevo requiera meter una nueva versión de alguna biblioteca de python, actualicen el paquete en el servidor y dejen de funcionar otros servicios porque estaban pensados para funcionar con otra versión de la biblioteca.
Meter un framework nuevo por la razón de meterlo nuevo, no es precisamente de buen ingeniero de software. Hay que analizar los pros y los contras, y yo desde luego en un servicio de máxima criticidad no voy a meter algo nuevo por ser lo más novedoso. Es como si me empeño en meter python 3 en vez de usar python 2.6 o la 2.7 por mis huevos, y no por razones objetivas, y luego resulta que las bibliotecas que usamos no están portadas o dan fallos con la versión de python3.
Los desarrolladores hacen nuevas versiones, introducen nuevas funcionalidades y con ellas aparecen nuevos bugs, reaparecen otros produciéndose regresiones, etc.. Si ya a veces parches que solo corrigen bugs introducen nuevos no es lógico cambiar a una nueva versión porque metan funcionalidades que no usas.
Vuelvo a repetir que no quiero desmerecer a la distribución Gentoo, ni pienso que hagan mal las pruebas de integración. Pero lo que no puedo hacer es poner un bug y que me lo resuelvan cuando les de la gana ya que por muy buenos que sean no tienen que tener las mismas prioridades que yo, y al no ser de pago no están obligados a nada, cuando yo lo que necesito es que me contesten a las pocas horas. Es por eso lo de mi comentario original, Centos para entornos de prueba y maqueta, y RedHat para producción.
Si no necesitas soporte, si tus entornos no son de máxima criticidad, en los que una caída de unos minutos vaya a suponer un perjuicio económicos muy grande pues entiendo que optes por otras soluciones que además serán mucho más baratas, pero comprende que no todos los proyectos tienen los mismos requisitos ni todos los contratos con clientes tienen las mismas penalizaciones en caso de fallo de servicio.