Hace ya unos cuantos meses que llevo dándole vueltas a la posibilidad de migrar parte de las aplicaciones que desarrollamos profesionalmente a entornos Linux.
Hasta hace poco esto era algo impensable, ya que desarrollábamos aplicaciones de escritorio basadas en .NET y aplicaciones para dispositivos móviles con Windows Mobile, pero últimamente cada vez son más las aplicaciones basadas en HTML5 que forman parte de nuestro software para punto de venta.
Ese paso a aplicaciones HTML5 ha permitido que muchos de los clientes que se conectan al servidor central (desplegado localmente o on-premises, para los modernos) sean dispositivos con Android, iOS o incluso Linux.
¿El motivo fundamental? El coste del hardware y el coste de la licencia. Cuando tienes un equipo dedicado en exclusiva a realizar una tarea profesional, muchas veces el sistema operativo importa muy poco puesto que el usuario sólo utiliza una aplicación, y el coste de una tablet malucha con Android es mucho más bajo que el de cualquier PC con pantalla táctil y su correspondiente licencia de Windows.
Todavía tenemos una parte importante de aplicaciones que son aplicaciones de escritorio, pero parece plausible que a medio plazo éstas sean reemplazadas por sus equivalentes HTML5.
En un escenario así, lo único que seguiría dependiendo de Windows sería el servidor central, y la idea de poder desplegarlo en Linux resulta muy atractiva.
Por una parte, está el ahorro directo del coste de licencia, que para nuestros clientes es importante. Estamos hablando de licencias de menos de 100€, que para los que estáis en mundos enterprise os parecerá algo ridículo, pero la realidad es que en mi sector, ese coste se nota.
Por otra, evitaríamos depender de la estrategia de negocio de Microsoft y tendríamos más libertad a la hora de decidir qué versiones de sistema operativo utilizar (el fin de soporte para Windows XP ha sido incómodo en nuestro sector).
.NET Core como solución
Llegado a este punto, la opción más «lógica» para dar el paso a Linux sería aprovechar .NET Core. A fin de cuentas, una de las cosas que está «vendiendo» Microsoft de su nueva versión de .NET es que será multiplataforma.
Viéndolo así, no hay mucho que pensar. Seguiríamos utilizando .NET, con las herramientas que conocemos de hace mucho tiempo, el lenguaje que llevamos utilizando más de diez años y un framework con el que estamos familiarizados, pero además ganaríamos soporte multiplataforma. Todo perfecto, ¿no?
Pues no tanto, la verdad. Resulta que .NET Core no es realmente compatible hacia atrás y no es tan sencillo migrar una aplicación compleja realizada con, por ejemplo, .NET Framework 3.5 a .NET Core. Frans Bouma escribía sobre ello hace unos meses cuando evaluaba la posibilidad de migrar su ORM (LLBLGen) a .NET Core.
En ese sentido, incluso desde Microsoft hay quien recomienda actualizar las aplicaciones ya existentes a .NET Framework 4.6 en lugar de a .NET Core:
My personal advice? if you’re going to migrate an application, bet for ASP.NET 5 running on the regular CLR.
Para los que no estéis familiarizados con las nuevas versiones del Framework, al hablar del regular CLR se está refiriendo a .NET Framework 4.6, que será la evolución del actual .NET Framework 4.5 y que sólo tendrá soporte para Windows.
En el fondo, es razonable. Una de las partes buenas de .NET Core es que pretende «limpiar» el kipple acumulado en el framework durante todos estos años para hacerlo más modular y liviano, y además existen partes del framework que están íntimamente ligadas a Windows, por lo que es necesario hacer algo con ellas para poder utilizarlo en otras plataformas.
El hecho es que hay partes que para nosotros son importantes, como el caso de ORMs potentes, contenedores de inversión de control o soporte para determinadas bases de datos que, actualmente, no están soportados en .NET Core y no está muy claro que lo vayan a estar en el futuro.
Cuando empiezas a considerar todo esto y te das cuenta de que la transición no es directa, en parte por las características (yo no lo llamaría limitaciones) de .NET Core, y en parte por las propias dependencias que tiene nuestra aplicación sobre Windows (uso del registro de Windows, ejecución como servicio, etc.) y determinadas librerías, resulta que tal vez el esfuerzo sea lo bastante grande como para poder plantearse el paso a otras plataformas.
Aquí podríamos empezar a culpar a nuestra aplicación por estar acoplada a Windows, a un ORM o a lo que queramos. La realidad es que en su momento esas decisiones parecían razonables, nos han permitido obtener muy buenos resultados de negocio y, en cualquier caso, ahora simplemente es lo que hay y forman parte del escenario del que partimos. Tampoco creo que se trate de algo tan extraño dentro del mundo de .NET.
La JVM como alternativa a .NET Core
Decir esto en este blog es casi una herejía, pero lo cierto es que después de pensar un poco sobre el tema, cada vez me parece una alternativa más razonable para conseguir mi objetivo, que es acabar ejecutando nuestro servidor sobre Linux.
Dos de las cosas que ofrece .NET Core y que más se están publicitando en círculos afines a Microsoft, el ser open source y el ser multiplataforma, son algo que tiene Java desde hace mucho, mucho tiempo. La parte de open source, aun siendo importante, me importa algo menos en este momento, pero el multiplataforma, Linux first (o al menos Linux first-class), sí es crítica para lo que estoy buscando.
Al llevar tanto tiempo disponible para plataformas Linux, la estabilidad de la JVM está mucho más contrastada que la que tendrá .NET Core cuando por fin esté disponible para Linux (hoy en día se está usando Mono, cuya estabilidad y rendimiento no es comparable al de la JVM).
El esfuerzo de convertir una aplicación desarrollada en C# a Java (o posiblemente otro lenguaje sobre la JVM como Scala) no es despreciable, pero tampoco se trata de una tarea imposible. Además, viendo las limitaciones actuales en cuanto a disponibilidad de librerías para .NET Core, tal vez no fuese mucho mayor que el de convertir una aplicación de .NET Framework 3.5 a .NET Core. Sólo prescindir de NHibernate para utilizar Entify Framework 7, con todas sus limitaciones iniciales, ya supondría un trabajo considerable.
Precisamente muchas de las librerías que utilizamos actualmente, como NHibernate, NUnit o log4net son ports casi directos de sus equivalentes Java, por lo que ya estamos familiarizados con sus APIs y su funcionamiento general. Además, el paso a la JVM nos permitiría explorar otras vías que parecen interesantes, como el uso de Akka o Play.
En resumen
No pretendo convertir este post en un alegato sobre por qué Java es mucho mejor que .NET, porque sinceramente no creo que sea así. Cada uno tiene sus puntos fuertes y sus puntos débiles, y ambos han demostrado que son alternativas viables para desarrollar casi cualquier tipo de aplicación.
En mi caso, se trata simplemente de analizar dos alternativas para evolucionar a medio plazo un proyecto concreto, buscando un equilibrio entre estabilidad, coste de desarrollo y proyección de futuro. Cada escenario es diferente y merece una consideración aparte.
Lo que me resulta más curioso es que, hasta hace poco tiempo, para mi el mero hecho de plantearme cambiar .NET por la JVM era algo impensable, y sin embargo ahora me parece una alternativa razonable.
Por suerte no es una decisión que necesite tomar inmediatamente y eso me va a permitir ver cómo avanza .NET Core y cómo van resolviendo parte de los problemas que he descrito, por lo que cuando llegue el momento podré tomar una decisión basada en hechos más tangibles.
En cualquier caso, reescribir un sistema, ya sea para migrar a una plataforma o a otra, no deja de ser una decisión arriesgada y, posiblemente, errónea, por lo que es una decisión que no debe tomarse a la ligera. Veremos cómo acaba todo dentro de un tiempo.
Estoy seguro de que hay muchas cosas que se me escapan tanto de un entorno como del otro, y estaré eternamente agradecido al que lo indique en los comentarios.
Bienvenido, cambiar de infierno tiene sus ventajas, al menos las torturas son ligeramente diferentes :-P
Hablando de torturas, ¿has estudiado las diferencias entre las ides y entornos de construccion/ejecucion (eclipse, ant, maven, servidor de aplicaicones, etc)?
¿Habéis valorado instalar vuestras aplicaciones en Linux mediante Mono o Xamarin?
No sucederá. Seguiréis en .Net pero full porque el coste es menor que el enorme riesgo de migrarlo todo a Linux/Jvm. Y lo sabes ;)
Javier, sobre el tema de IDEs y herramientas de build, de momento no hemos mirado nada en profundidad, pero no creo que fuese muy traumático.
Estamos acostumbrados a ReSharper, que es de JetBrains, por lo que el paso a IntelliJ sería fácil, y pasar de MSBuild a cualquier cosa no puede ser muy difícil.
De todas formas, estoy seguro de que en esa parte echaríamos de menos, sobre todo al principio, el mundo de .NET. Las herramientas que hay son muy buenas y, sobre todo, las conocemos bien.
Lázaro, la opción de Mono, hoy por hoy, me parece frágil. Cuando he intentado hacer algo con él, siempre me ha tocado pegarme un buen rato con bugs en distintas versiones de Mono. Si .NET CLR acaba ofreciendo una alternativa sólida, estable y bien soportada para Linux, sería una opción más viable.
Escéptico, el coste, y sobre todo el riesgo, es muy grande.
Desde luego lo más sencillo sería seguir en .NET Full, pero es algo que no depende sólo de nosotros.
Si dentro de 3 años hace falta .NET Full para desarrollar sobre Windows 12, y .NET Full ya no soporta Windows XP, tendremos un problema porque no podremos soportar el parque de equipos que tenemos instalados y a la vez soportar los equipos nuevos.
Complicada elección, en mi opinión y aunque no tengo mucha experiencia con Java (experimentos unos cuantos), el ecosistema es bastante peor que .Net. Quizás una vez en el ajo, puede no notarse mucho la diferencia, pero pasar de .Net a Java… ya contarás :D
En tu entorno entiendo que habrá problemas de disponibilidad pero hoy en día parece factible (al menos plantearse) dar servicio SaaS, desconozco vuestro nicho, pero un porcentaje muy alto (~99%?) tendrán alta disponiblidad de internet (y con posibilidad de línea de backup vía telefonía móvil).
Las ventajas son claras, reducción de costes sobre el modelo actual y no tendríais que migrar de entorno de desarrollo ni rehacer mucho del desarrollo (si está bien hecho ;P).
La ubicuidad de acceso está garantizada siempre que los terminales tengan acceso a datos (y siempre podríais hacer nativas claro es independiente).
Sí, si pierden acceso a Internet están jod…
Pensar que por usar Resharper en Visual Studio, IntelliJ no va a ser un problema, es un grave error. Yo he usado (poco, es cierto) IntelliJ, y en algo de mayor medida PhpStorm… y son una auténtica porquería en comparación.
No es que no sean usables, ni que no tengan sus cosas buenas… pero Resharper no es un IDE: el IDE es Visual Studio, Resharper es un mero helper (que aprovecha en gran medida la potencia de Visual Studio para hacer lo que hace).
Por otro lado, soy un confeso detractor de Java como lenguaje (que no como plataforma) y me incomoda muchísimo escribir código Java (y también PHP), por lo que mis valoraciones son puramente subjetivas.
Yo opino que hay que usar las herramientas que a uno le vengan bien para el resultado final, pero si escribir Java os resulta tan incómodo como a mí (especialmente viniendo de algo claramente mejor [subjetividad again]), es algo a valorar también: la moral del equipo de trabajo puede acabar por los suelos (a mí me ocurriría :-) )
Hola Juanma,
Con independencia de aspectos técnicos (aquí entiendo que habrás evaluado concienzudamente tu reflexión antes de exponerla al público, de eso no me cabe duda), me parece un excelente y sano ejercicio de transparencia que cuentas estas cosas en tu blog. Está claro que tomar este tipo de decisiones no debe ser fácil (tiempo, coste, riesgo…). Al final, la «teoría» dice que los lenguajes, frameworks, herramientas, etc. están ahí para ayudarnos y no para limitarnos. Dicho esto y tomes el camino que tomes, seguro que será muy interesante el seguir tus devenires y reflexiones al respecto.
josejuan, la idea de SaaS es técnica y comercialmente muy atractiva, pero ahora mismo es un poco complicada de implementar comercialmente en este sector. Desde luego, para nosotros sería lo ideal, pero a corto plazo lo veo complicado.
Javier Campos, tal vez no seamos muy powerusers del Visual Studio y por eso no nos resulte tan imprescindible. De hecho hay gente en el equipo que usa WebStorm para desarrollo en Javascript (en lugar de Visual Studio 2013) y la transición les ha resultado bastante fácil.
Sergio, como decía en el post, por suerte no tengo que tomar la decisión ahora. Ya veremos qué pasa al final, si acaba todo en .NET Full, o en .NET Core, en SaaS, en Java o en cultivo de geranios :-) Lo bueno de hacerlo «público» es que puedo recibir gratis opiniones que me ayuden a ver mejor todas las vertientes del problema.
I, for one, welcome our new JVM overlords! :-D
Estoy seguro que hagáis lo que hagáis os irá bien, y yo personalmente estaré encantado de leer sobre ello :-)
Mi opinión sobre IntelliJ es positiva y ofrece una transición a Java más llevadera. Si hubiera que usar Eclipse directamente me parecería una locura abandonar .NET por Java.
Aunque IntelliJ es bastante bueno su funcionalidad está muy lejos de la que ofrece ReSharper.
Migrar los aplicativos a .NET Core sería (desde mi punto de vista por tu experiencia en el campo y la complejidad de ambas tecnologías) menos traumático que pasarlos a Java. Pero ahí viene un punto importante que mencionas: la multiplataforma. Es una piedra en el zapato en .NET, algo realmente insalvable para mí, a pesar de esfuerzos loables como Mono. El coste de las licencias por parte de los clientes es también un plus importante en este escenario.
Además, todo apunta a que en un futuro los aplicativos móviles de administración/monitoreo de este tipo de soluciones (las que he vito en tu página web) se migre a HTML5, donde lamentablemente la plataforma de MS es una minoría. Estando en el «mundo Java» es más consecuente desarrollar para Android (¡que tiene del 80% del mercado!). Lo de iOS siempre se tendrá que manejar de la misma forma, estés en el bando de Java o de .NET.
Por otro lado, si sigues en .NET serías uno de los -no pocos- profesionales que apostamos por el crecimiento de la plataforma y la apertura que está teniendo desde hace un tiempo. Además de migrar todo a .NET Core, podrías considerar el uso de Xamarin para el desarrollo de aplicativos móviles. Igual tendrías que dedicar esfuerzos para la UI de Android/iOS, pero al menos seguirías con tu plataforma favorita (en este momento).
Joel, tu análisis se ajusta muy bien a mi situación actual: lo más cómodo sería migrar a .NET Core, porque aunque haya que reescribir mucho, es un mundo que conocemos más, pero el multiplataforma inicial que tendrá .NET Core posiblemente no sea comparable al de la JVM.
Lo de Android es un buen punto, aunque ahora mismo no es algo crítico para nosotros. Es verdad que con .NET Core + Xamarin podría llegar a ejecutar servidores en linux y apps en Android, pero me temo que siempre iría un paso por detrás de plataformas como Java, que es más «nativa» tanto a Linux, como a Android.
Muy interesante el post, estar ante un caso real hace muy llevadera la lectura. Sin conocer en detalle el negocio y otras variables quizás evaluaría más la opción de pasar a Saas que cambiar la plataforma por Java (el esfuerzo es menor?).
Por otro lado, los programadores de tu equipo como evaluan esto? Dependendiendo el perfil de los mismos quizás pueda producirles ruido pasar de ser programadores seniors de .net a programadores juniors de java … siempre pensandolo desde el plano individual y de empleabilidad futura.
Pablo, es una cuestión muy interesante la del resto del equipo. En una decisión así es un factor importante, pero no sólo del equipo actual, sino de posibles incorporaciones (¿es fácil encontrar gente capacitada y dispuesta trabajar sobre esa plataforma?).
Creo (o al menos espero) que ninguno nos consideramos «programador .NET» sino «programador». Siempre he intentando rodearme de gente con bases sólidas y genéricas más que con conocimientos de especialista en una tecnología concreta, pero lo que planteas puede ser un problema en a tener en cuenta en ciertos entornos.
Yo estoy de acuerdo con Pablo… y pienso que es un problema más de actitud que de aptitud, en mi opinión.
Yo ahora programo en .NET (C# en concreto, pero no me importaría hacerlo en otra cosa), pero he pasado por PHP, Java, Delphi, Pascal (que no es lo mismo), Javascript, C/C++, y hasta ensamblador de x86 y z80…
El hecho de que haya programado (y mucho, durante muchos años, y profesionalmente) en C++, no quiere decir que hoy día me gustara hacerlo. Si tuviera que hacerlo, «podría hacerlo» (eso es la «aptitud»), pero viniendo de algo tan cómodo y potente como es C#, me sentiría incómodo y poco motivado (mi moral se iría por los suelos, y se notaría en mi «actitud»), al menos, una vez pasada la fase de «redescubrimiento» donde todo es interesante, y estoy plenamente convencido de que eso se notaría en mi rendimiento.
Precisamente el tener aptitudes (no necesariamente ser especialista) en muchos lenguajes y/o plataformas es lo que te hace apreciar las buenas herramientas… aquellos que se autodenominan «programadores PHP» pensarán que C# o Java son muy difíciles y no te permiten hacer nada, y que todo es muy complicado, sin tener claro el por qué.
Como digo, si tengo que hacer un proyecto en PHP (o en C++, o en Delphi, o en algún lenguaje que todavía no conozca o haya usado) puedo hacerlo… «querer es poder», pero «poder no es necesariamente querer» :-)
Perdona Javi, creo que no me he explicado bien.
Yo me refería más a la parte que comentaba Pablo de «(…) pasar de ser programadores seniors de .net a programadores juniors de java (…) pensando en la empleabilidad futura».
Mi argumento iba en el sentido de que, si tienes unas bases buenas, no pasas a ser Junior, sino que sigues siendo un programador con experiencia y que, además, conoce más lenguajes. Sobre todo si hablamos de pasar de C# a Java, que son dos lenguajes que comparten mucha filosofía (otra cosa sería pasar de PHP a Idris, pero no estamos hablando de eso).
En lo que tú comentas estoy de acuerdo. Que uno sea capaz de hacer muchas cosas no quiere decir que le dé igual qué cosas hacer.
Aun así, creo que el lenguaje/plataforma/herramienta es sólo una parte. Puedes programar en C# y pasártelo genial o aburrirte hasta el infinito. La forma de afrontar los proyectos, el tipo de desarrollos, el equipo… yo creo que esas cosas acaban pesando más que el lenguaje concreto.
Para mi, de todo lo que has explicado aquí, más que Java y .NET el aspecto clave es HTML5. Tú has basado tus razonamientos en que HTML5 no es negociable en estos momentos https://twitter.com/gulnor/status/554596711830921216 . Ahora nos ponemos De Icazistas y decimos que es un craso error esa postura a largo plazo porque cada vez el usuario va a ser más exigente y va a exigir una apariencia y funcionalidad homogénea de todas las aplicaciones en su plataforma. El modelo de negocio Xamarin se basa exclusivamente en esa suposición: que HTML5 no va a triunfar ni para aplicaciones móviles ni de escritorio. Si ese argumento es cierto (yo no tengo tan claro que esto sea cierto para el mercado español, pero a largo plazo creo que sí), y Microsoft remonta el vuelo y España no sigue androidzada, tu decisión habría sido errónea.
De todas formas no creo que Microsoft vaya a remontar el vuelo porque Nadella se ha quedado a medias: http://www.infoworld.com/article/2847372/open-source-software/microsoft-must-finish-opening-net.html . Si hace verdaderamente open source C# supongo que los fabricantes de móviles/tablets le apoyarían, y Microsoft conseguiría una buena cuota de mercado. No creo que Microsoft ya lo vaya a hacer si no lo ha hecho ya, porque esa decisión ya se la habrán pensado mucho, y por tanto los fabricantes le van a dar la espalda.
Buena argumentación, Luis.
Cuando decía en twitter que HTML5 no es negociable en estos momentos es porque nuestras experiencias con él han sido muy buenas. El coste de desarrollar para varias plataformas ha sido prácticamente cero (hay que probar y ajustar para varios browsers, pero poco más) y la posibilidad de despliegue, o mejor dicho, de no despliegue, en los dispositivos clientes cuando hay una actualización, vale su peso en oro en nuestro sector.
El argumento de De Icaza de la homogeneización es, cuanto menos, cuestionable. Yo manejo con frecuencia iOS y Android, y en ambos casos hay muchas aplicaciones con interfaces de lo más variado, y no me resulta extraño ni molesto.
Aun asumiendo que la hipótesis de De Icaza fuese cierta, hay un factor que debemos tener en cuenta: nosotros vamos a un usuario profesional. A este usuario le importa poco el sistema operativo que hay por debajo porque sólo ve nuestra aplicación.
En realidad es más importante que resulte familiar el interfaz de nuestra aplicación en cualquier plataforma, para que el usuario no tenga que cambiar su modelo mental al saltar de iOS a Android a Windows, que seguir las guías de estilo de cada plataforma.
Pues ese argumento que das en el último párrafo te parecerá una tontería pero no lo había pensado y es aplastante. Con las tablets/móviles siempre lo había pensado para un usuario personalizado. Acabas de perder un MVP Xamarin :D.
Y ahora que C# se hizo open source?
Cuando escribí el post ya se había anunciado la apertura de .NET, y de hecho hablo de .NET Core en el post, así que no cambia mucho las cosas.
Estimado
El no conocer a donde vas, en este caso Java, te darás cuenta que la transición será traumática. Ya he pasado por eso 3 veces y al final siempre es lo mismo, ese coste que mencionas se irá al agua en temas de mantenimiento y aprendizaje. Cuando llegues a los pocos meses de haber terminado, vas a querer regresar corriendo a .Net.
Hola desde Argentina.
Es interesante la situación que planteas. Yo particularmente estuve trabajando un tiempo con ASP.NET MVC, y la verdad es que funciona muy bien como herramienta para desarrollo web (no estoy enfocado en el desarrollo de escritorio).
Pero actualmente, con esta salida al mercado de los nuevos productos de Microsoft, estoy evaluando si continuar como estoy o cambiarme a Java, algo muy parecido a lo que te sucede.
Creo que hay que pensar en el costo beneficio de cada opción y, al fin y al cabo, en lo cómodo que nos sintamos nosotros.
Saludos!
Bueno en 2016 parece que lo ocurrido es lo siguiente:
Xamarin es la opción de calidad a la hora de programar multiplataforma en móvil y html5 (Cordova) es la opción barata de bajo rendimiento.
ASP.NET es open source así como C#. Es multiplataforma y muchas empresas están migrando a ello por la comodidad y velocidad de desarrollo que ofrece.
Microsoft parece que levanta vuelo con Windows 10 y se mete con sus tecnologías en linux y mac os X.
@kr1
Opino justo lo contrario. Microsoft ha perdido la guerra en los «frameworks» de desarrollo «software» y compra Xamarin como medida desesperada.
Los entornos de desarrollo tienen que ser de código abierto y multiplataforma. Los que se queden fuera de estos requisitos irán muriendo.
En mi caso tenía esperanzas de que Microsoft abriera .NET completamente, pero veo que no tiene intención de hacerlo, por lo tanto ya estoy en pleno proceso para su abandono. Considero que seguir trabajando con .NET es hipotecarme.
He visto tu comentario en Twitter y te contesto aquí (no soy usuario de Twitter).
Tu «tweet»:
** Lo de SQL Server en Linux me resulta tan inesperado como desconcertante. ¿Cuál es el objetivo? ¿Ahorrarte la licencia de windows? **
Creo que el objetivo de Microsoft es que los proveedores de «hosting» empiecen a incluir en su oferta ASP.NET Core y .NET en general. Microsoft intenta lanzar un mensaje a las empresas de «hosting» para que vean como una opción real ofrecer el entorno de desarrollo de Microsoft en Linux.
Considero que Microsoft está ya perdiendo la guerra del desarrollo «software» y una de la grandes razones es precisamente la pobre oferta de «hosting» sobre tecnología Microsoft. Actúa como caballo de Troya para hundir el uso de .NET.
Hola Julián,
En realidad saltar al blog hace que sea más cómodo hablar (aunque los comentarios peguen poco con el post :-)
Lo que comentas es razonable, hoy en día es caro encontrar hosting para windows y .net (al menos comparado con linux).
Sin embargo, para abaratarlo, ¿no hubiera sido más sencillo dar gratis las licencias de Windows Server? Además, así no sólo podrían usar SQL Server, sino también MSMQ o toda la tecnología de Microsoft que quisieran.
Creo que a las empresas de «hosting» les resulta más cómodo tener una sola infraestructura basada en Linux y sobre ella añadir entornos de desarrollo y aplicaciones.
Buenas…hace bastante que sufro con el dilema de a cual tecnología dedicarme de lleno…lo mas grande que he hecho fue en .net, hace tiempo vengo mas enfocado en la arquitectura del sw, sobre todo en los patrones, y me viene sonando JAVA EE en la cabeza hace rato, y en lo que leido al respecto, me da la impresión que están mas impuestas las buenas prácticas, el uso de patrones, DI, seguridad; tambien encuentro mas ejemplos de su aplicación en aplicaciones empresariales que en .net. Agregando que ahora MS reinventa su ecosistema con Net Core, Asp.net Core y EF, perdiendosé mucha compatibilidad para atrás (cosa que en JAVA EE no es tan así), me genera cada vez mas dudas.
Por otro lado, MS insiste en que la versión tradicional de NET seguira dando lucha, que mantendrán las dos opciones, pero dudo que a la larga se mantenga la tradicional, arriesgándonos a que si seguimos en NET FW tradicional arriesguemos mucho.
En base a tu experiencia, ya casi terminado este 2016, que conclusión sacas?
Hola Matías,
Los pasos en el mundo .NET son positivos, y ahora empieza a haber otros actores que, en mayor o medida, apuestan por él. Google uniéndose a la .NET Fundation es un ejemplo claro.
Aun así, toda la historia multiplataforma está mucho más verde que en Java.
Es complicado decidir y no hay una respuesta buena para todos. Personalmente, si tuviera que empezar ya un proyecto para entrar en producción a lo largo del 2017, apostaría por algo más estable que el nuevo .NET y con más recorrido que el antiguo .NET.
herejía!! y mucha blasfemia en el articulo
Ya hace tiempo se escribio este artículo, lo se, pero… Aun asi agrego:
Veo mucha gente aca criticando todavia java 5, creo que debieron antes al menos leer un poco al respecto sobre java y sus herramientas. Frameworks y librerias como Spring Data, Spring boot, play framework, Spark Java etc, etc. Estos frameworks potencian el desarrollo de forma brutal, ya sea usando arq. de microaervicios, o etc etc. Me imagino que muchos aquí solo conocen el viejo jsp y servlets, o el viejo jsf, y dan feedback de lo que conocieron en el pasado, por eso me parecen inválidas casi en su totalidad las opiniones.
Respecto a la decisión de aquella vez, difici, yo te habria preguntado, que tanto tiempo llevas desarrollando tus softwares, o madurandolos, que tan grandes son y demas cuestiones. Si eran separados en modulos o que, para mi es de gran valor eso para tomar una desición como esa. Si los softwares son modulos de un todo, yo tu habria hecho la prueba migrando uno, tambien habria sopesado que herramienta usar en java, spring, es excelente opción por lo ágil que es, habiéndo migrado un hipotético modulo sopeso el tiempo que me tomo migrarlo, restándole el tiempo de la curva de aprendizaje. Si haces la prueba te vas dando cuenta. Yo te diria que, con Spring data, Spring boot serias lo suficientemente agil como para tener todo el exito, siendo el hipotético caso de modulos que mencione.
En java solo en algunos casos, mayormente en el mantenimiento de apps legacy se usa el stack empresarial (Java EE). Hoy por hoy se no se necesita de un tomcat, o un war file, o un ear, la industria del software con java se decantó prácticamente por el stack Spring. Te habria recomendado Spring, Play tambien es valido, pero Spring encaja en desktop y web. Chequea Spring boot.