Cómo seleccionar una plataforma de desarrollo para un proyecto web

Un conocido me dijo en cierta ocasión que al informático que mantenía su sitio web le llamaban El Hechicero porque nadie excepto él sabía cómo dar unos pases mágicos al invento que hacía que su website funcionase. Todos los hechiceros tienen su libro de recetas ocultas y ello conduce al primer consejo previo antes de empezar con el análisis comparativo de plataformas:

Cualquier gurú te dirá que la plataforma que él maneja es la mejor, pero sólo porque no conoce otras plataformas.

Entonces, si otra (que no es la del gurú) es mejor ¿Cual escoger? Mi primera respuesta sería ¡no importa! Las plataformas más populares compiten ferozmente entre ellas por ofrecer mejores funcionalidades y prestaciones. Son como las participantes en un concurso de belleza, aunque votes por la menos agraciada, incluso así, acabarás eligiendo una mujer que no es después de todo para nada fea. Esto me lleva al siguiente corolario:

Si tu plan de empresa depende críticamente de las presuntas eficiencias espectaculares de una determinada plataforma, entonces es que deberías replantearte algo en tu plan de empresa.

Criterios para evaluar una plataforma de desarrollo.

Bueno, entonces ¿Todo da igual? No. Tampoco es eso, voy a comentar a continuación las 5 plataformas más populares de lado servidor: Java, PHP, Microsoft .NET, Python y Ruby On Rails. Las plataformas voy a evaluarlas en base a los siguientes criterios:

1º) Grado de madurez.
2º) Tamaño y grado de actividad de la comunidad.
3º) Disponibilidad de librerías y aplicaciones de terceros.
4º) Disponibilidad y coste salarial de los programadores.
5º) Dificultad de la curva de aprendizaje.
6º) Compatibilidad con el resto del ecosistema.
7º) Rendimiento y escalabilidad.

He dejado premeditadamente fuera de la lista la productividad, porque, como ya he expresado, opino que, si se usan bien, todas ellas ofrecen un grado de productividad equivalente, o, al menos no lo bastante diferente como para que debiera ser relevante.

¿Por qué es relevante cada uno de los siete factores anteriores?

Primero, la madurez. Hay proyectos, como por ejemplo node.js que se crearon para resolver problemas específicos. En el caso de node.js el tratamiento de peticiones AJAX desde las nuevas aplicaciones HTML5. Node.js ofrece una modalidad de procesamiento asíncrono junto con la propuesta de programar en JavaScript igualmente en el lado cliente y en el servidor (¿alguien se acuerda del SSJS de Netscape en el 94?) cosa que sus promotores denominan “el nirvana de los programadores”, aunque yo no calificaría a JavaScript como el nirvana de nada. Lo que sucede es que lo mismo que se puede hacer con node.js se puede hacer con los servlets asíncronos de Tomcat 7. Es más enrevesado de aprender y de codificar en Tomcat, ciertamente, pero a cambio se tiene una plataforma mucho más madura, eficiente y compatible que node.js. Más madura implica, por ejemplo, casi siempre mejor documentada. Las carencias de la documentación, por cierto, son un mal endémico en las librerías JavaScript cliente incluso en las más maduras como Dojo o YUI.

Segundo, el tamaño y grado de actividad de la comunidad. Es relevante porque cuanto mayor sea la comunidad más probable es que hay alguien que se haya topado con el mismo problema que nosotros y lo haya resulto. Más probable que en Stack Overflow o en cualquier otro sitio de preguntas y respuestas hallemos la solución a un problema que nos mantiene atascados.

Tercero, la disponibilidad de aplicaciones y librerías de terceros. El framework de desarrollo es sólo la herramienta base para construir una aplicación. Justo a continuación de elegir la plataforma hay que elegir las librerías. Por ejemplo, Java domina absolutamente el entorno financiero y bancario porque su middleware es el mejor. Lo hay para todos los gustos desde JBoss a TIBCO, pasando por Informatica UM. Los frameworks más modernos de todos los lenguajes han ido incorporando librerías de serie. Java apareció en 1995 y, más que un lenguaje para aplicaciones web estaba pensado con filosofía WORA (Write Once Run Anywhere) y para tener la menor cantidad de dependencias posible. Ruby On Rails apareció 10 años después e incorporaba en su arquitectura el paradigma Modelo Vista Controlador (MVC) y mecanismos como ActiveRecord que permiten que las clases tomen de la base de datos los nombres de la columnas sin necesidad de definirlas explícitamente en el código. Para conseguir con Java un framework funcionalmente similar a Ruby on Rails se necesita, al menos, una librería MVC como Struts, una capa de persistencia como Hibernate, soporte de servicios REST como Jersey, una librería de tags como JSTL y JavaMail. La cantidad de librerías Java es tal que existen empresas como Black Duck en EE.UU. Autentia en España especializadas en evaluarlas y dar formación a los clientes corporativos.

Cuarto, la disponibilidad y coste de programadores. Si sólo se van a necesitar dos o tres, entonces no hay problema. Pero si se estima que el proyecto requerirá 40 o 50 desarrolladores entonces encontrar y contratar personas puede llegar a ser muy difícil y costoso. Si se estima que el proyecto necesitará más de 50 desarrolladores, entonces es que se ha hecho mal el plan y bien hay que partir el proyecto en trozos de menos de 50, bien sería mejor cancelarlo y tirarlo todo a la basura antes de que se queme una burrada de dinero en producir un monstruo.

Quinto, la dificultad de la curva de aprendizaje. He dicho antes que todas las plataformas son igualmente buenas en cuanto a productividad. Pero no todas son igualmente fáciles de aprender. Si se tiene cuenta el tiempo que requiere un programador novato para aprender cómo funciona el invento, entonces sí que existen diferencias entre unas y otras. El orden de más fácil a más difícil es: PHP, Ruby On Rails, .NET, Python y Java.

Sexto, la compatibilidad con el resto del ecosistema. Rara vez las aplicaciones existen de forma aislada e independiente unas de otras. En general, las diferentes plataformas no son fácilmente interoperables unas con otras. Existen muchas herramientas de integración y formatos de representación de datos independientes del lenguaje como Protocol Buffers, pero lo más común, por fácil, es que las plataformas en dos lenguajes diferentes se acaben integrando vía base de datos relacional, XML o ficheros de texto delimitado.

Séptimo, el rendimiento y escalabilidad. Todos los programadores que conozco afirman que ellos desarrollan aplicaciones escalables. De ellos, he visto con mis propios ojos desarrollos ir lentísimos con tan poco como 100.000 registros. Con ello quiero decir que la escalabilidad es en primer lugar una cuestión de diseño y sólo en segundo lugar algo que dependa de la plataforma. La prueba es que existen sitios web de altísimo tráfico sobre todas las plataformas que comentamos aquí. A grosso modo, si se tiene una base de datos con tablas que no superan el millón de registros y un sitio web que no supera las cien mil visitas al día, entonces la escalabilidad no será una cuestión relevante se use lo que se use a menos que el programador sea realmente malo, pues cualquier servidor quad-core medio moderno puede atender tal volumen de trabajo sobre una base de datos relacional.

Java
Java es la plataforma más extendida en el entorno corporativo. Se trata de una tecnología muy madura y popular que cuenta con innumerables herramientas de todo tipo y es bastante sencillo encontrar programadores. Casi todo el mundo que desarrolla en Java usa Eclipse o Netbeans como IDE. Ambos son bastante pesados y a mi personalmente me gusta más JCreator, aunque en un portátil con 4Gb de RAM tanto Eclipse como Netbeans corren perfectamente. La principal pega de Java para el desarrollo de aplicaciones web es que la plataforma no se concibió originalmente para eso, sino que fueron apareciendo proyectos como Tomcat en 1999. Las extensiones a la plataforma se acuerdan mediante el Java Community Process (JCP) compuesto por más de mil miembros que trabajan sobre más de 300 Java Specification Requests (JSR) Estas especificaciones tienden a ser muy densas y a veces salen cosas realmente retorcidas como JavaMail. Algunos presuntos gurús han difundido el mito de que una startup no debería basar su tecnología en Java. Esto es radicalmente falso pues Java es perfectamente compatible con el modelo lean en boga. La curva de aprendizaje de Java no es suave. No porque el lenguaje en sí mismo sea muy complejo sino porque además del propio Java hay que conocer todos los entresijos de las decenas de librerías y herramientas de terceros hasta el punto en que es habitual que en las demandas de programadores se especifique no que sepan Java sino que dominen el uso de Spring, Struts, Hibernate, etc. Hay bastantes programadores Java en el mercado, pero los genuinamente senior escasean debido a la gran cantidad de herramientas y técnicas que hay que dominar para explotar a fondo todo el potencial de Java. Java es, a mi juicio, la plataforma más rápida y escalable de las comentadas aquí, o, al menos, es la que permite un mayor grado de manejo a bajo nivel para optimizar el rendimiento a menos que se usen librerías en C++ llamadas desde las páginas dinámicas. Una prueba de ello es que los sitios web de alto tráfico basados en Java tienden a ser puro Java, mientras que es común encontrar que tras PHP, Django o RoR hay alguna librería compilada a código máquina para hacer algo.

PHP
También conocido popularmente como LAMP (Linux+Apache+MySQL+PHP). PHP (acrónimo recursivo de Hypertext Pre-processor) es coetáneo de Java. Apareció también en 1995, pero, a diferencia de Java, estaba pensado desde el principio como un lenguaje que se pudiera incorporar en documentos HTML. La gran ventaja de PHP es que resulta sencillo empezar con él y existe mucha documentación online. Es más fácil aprender PHP que Java, y todos los ISP proprocionan algún tipo de stack LAMP preconfigurado. Es por consiguiente sencillo encontrar programadores PHP a precios asequibles. PHP no proporciona un sistema MVC por defecto pero existen muchas opciones para ello. A mi me gusta CakePHP mas se pueden contar las alternativas por decenas siendo Zend probablemente la más popular. Hay muchas startups de éxito basadas en PHP, incluídas algunas de las de mayor tráfico como Wikipedia, Yahoo o Facebook entre ellas. El lenguage en sí mismo presenta algunas limitaciones importantes. No se pueden crear de forma natural pools de conexiones, no hay sesiones, el módulo mod_php para Apache permite mantener sesiones pero mucha gente lo considera intrínsecamente inseguro. La propia facebook acabó desarrollando su propio compilador just in time (JIT) HHVM para poder alcanzar el rendimiento que necesitaban con PHP.

.NET
Si Sun no hubiese creado Java probablemente .NET dominaría ahora mismo todo el panorama de software empresarial. El punto fuerte de plataforma de Microsoft es el grado de integración entre el escritorio y las aplicaciones web. Si yo tuviese que desarrollar una Intranet a sabiendas de que los usuarios van a tener todos Windows no lo dudaría y la desarrollaría sobre .NET. Mas para una startup yo nunca elegiría .NET no por problema alguno con la tecnología sino simplemente porque el software de Microsoft no es Open Source. .NET sólo puede correr en servidores distintos de Microsoft Internet Information Server si se usa Mono y los servidores Windows son más caros de alojar que los Linux. Además usar SQL Server (la elección natural para .NET) también es bastante más caro que elegir PostgreSQL o MySQL.

Python
Python para la web es sinónimo de Django. Django apareció en 2005 como framework para la creación de sitios web de contenidos dinámicos, y, si eso es lo que hay que hacer, puede ser una excelente elección. Python es un lenguaje interpretado, no usa bytecodes como Java, y aunque existen versiones de Python que pueden correr sobre JVM yo no conozco a nadie que las use en producción. El tipado dinámico y los tipos de alto nivel hacen que el código Python sea más corto que Java. Como RoR, Django incluye un subsistema MVC (aunque algo ecléctico) y también mapeador objeto-relacional, un sistema extensible de plantillas basado en etiquetas, un despachador de URLs basado en expresiones regulares y middleware para cacheo, compresión de la salida, normalización de URLs, protección Cross-Site Request Forgery (CSRF) y soporte de sesiones. Lo normal es ejecutar Python con el mod_python de Apache 2. Aunque gracias al soporte WSGI se puede correr también sobre Lighttpd. En general es de esperar que el rendimiento de Python sea inferior al de Java y, por consiguiente, ello puede ser un obstáculo si se pretende llevar el tráfico hasta el límite. Algunos sitios web de alto tráfico como Instagram o Pinterest están desarrollados con Django, aunque ellos mismos han reconocido que tuvieron problemas con la escalabilidad debido a su vertiginoso crecimiento, no sólo por Python sino también en gran parte por llegar al límite de las tecnologías de almacenamiento de datos. My experiencia personal con Python/Django es que es muy bueno como como “lenguaje pegamento”, es como un “Perl con esteroides”, pero no es tan bueno como lenguaje para una plataforma, porque permite programar muy sucio y porque es fácil embarullar la capa del Controlador en el MVC de Django. Python es relativamente sencillo de aprender, y a la mayoría de los programadores profesionales les gusta cuando llegan a conocerlo, pero, debido a que existe menos demanda de programadores Python que de Java, .NET o PHP estos son más difíciles de encontrar.

Ruby On Rails
Ningún framework de los anteriores levanta tantas pasiones a favor y en contra que Ruby On Rails. Como Django, RoR es un framework que se pensó desde el principio para el diseño de aplicaciones web. Es un framework de pila completa, lo que significa que trata de integrarlo todo desde la base de datos hasta el código que corre en el navegador cliente. RoR incorpora de serie el paradigma MVC, el mapeo objeto-relacional, infraestructura para crear recursos REST y otras funcionalidades propias del desarrollo web como un detector de inyección de JavaScript y SQL. RoR también incorpora JQuery, y se pueden conseguir herramientas de terceros como Aptana para el desarrollo de las páginas HTML5. Los críticos de RoR argumentan que es lento y que no escala bien en webfarms. Es cierto que las sesiones sólo se pueden compartir en Ruby a través de la base de datos. Pero es que yo soy partidario de que las aplicaciones no deben mantener nada en una sesión de lado servidor sino que se deben usar cookies para mantener las credenciales del usuario y luego cachear el resto. El sitio web más grande basado en RoR probablemente es Twitter. Otra crítica común es que, debido a la integración transparente entre el lenguage y la base de datos, no se puede usar Ruby fácilmente contra un modelo de datos que ya esté creado o siga unas normas de programación del estilo de sólo poder acceder a la información vía procedimientos almacenados, o, más bien, sí se puede, pero entonces se le mata la magia de ActiveRecord al lenguaje. Ruby es relativamente fácil de aprender, más o menos como PHP sólo que la documentación de Ruby no es tan extensa ni detallada. Hay muchos menos programadores de Ruby que de Java o de PHP. Sus defensores argumentan que los programadores de Ruby son pocos porque son todos unos gurús, mas creo que leyendo este artículo ya se sabe lo que opino de los gurús.

Tecnologías Front-End
¿Agotado con las opciones de los frameworks de lado servidor? Pues ¡un momento! porque aún nos queda hablar del software del lado cliente.
La compatibilidad entre navegadores web ha sido desde siempre una merienda de negros y con la llegada de HTML5 y CSS3 la situación no ha mejorado para nada. La oveja negra es Internet Explorer sobre todo las versiones anteriores a la 10. Es virtualmente imposible desarrollar una aplicación HTML5 cross-browser sin una librería de compatibilidad como Modernizr. CSS también tiene tantas sutiles diferencias que prácticamente nadie desarrolla sin un paraguas como YUI. Y para el desarrollo en JavaScript es totalmente común encontrar JQuery o Dojo. Existen decenas de otras librerías como Bootstrap, Backbone, CoffeeScript, Datejs, RequireJS, PhantomJS, etc. O frameworks como Ext.js. Incluso se puede desarrollar en Java Swing y convertirlo a JavaScript con GWT o, aún más exótico, desarrollar en Dart y compilarlo a JavaScript. Una herramienta muy útil para componer CSS es LESS aunque hay que precompilar siempre los scripts puesto que a Rhino le puede costar 2 segundos compilar un archivo .less de ~30Kb lo cual es un tiempo muy significativo en la carga de una página web.

Conclusión
Ninguna plataforma es óptima para todas las necesidades. Para concluir con algunas reglas sencillas, mi propuesta es la siguiente:

– Si tienes que desarrollar un sitio web para una multinacional, o hacer integraciones complejas con otras plataformas o realmente vas a crecer mucho tanto en tráfico como en número de desarrolladores, entonces elige Java sobre PostgreSQL.

– Si quieres tener presencia online eficaz y asequible, incluso e-commerce, pero tu website no es el factor crítico exclusivo de tu negocio, entonces elige LAMP.

– Si tienes que desarrollar una intranet o un sitio web corporativo a sabiendas de que los usuarios tendrán Internet Explorer y tecnologías Microsoft entonces elige .NET sobre SQL Server

– Si necesitas una web con contenidos dinámicos mantenida por un equipo compacto y eficiente de programadores entonces elige Django sobre PostgreSQL o RoR sobre MySQL.

Posts relacionados:
Cómo elegir librerías y sobrevivir a JavaScript
Ruby 3 y el diseño por convenio
Cómo encontrar y gestionar un partner técnico

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Esta entrada fue publicada en Adoptando Sw Libre en una Organización, Casos Prácticos, Tecnologías Libres. Guarda el enlace permanente.

26 respuestas a Cómo seleccionar una plataforma de desarrollo para un proyecto web

  1. Carlos dijo:

    Excelente artículo. Creo que es una buena visión de los entornos de desarrollo actuales.

  2. Pingback: Cómo seleccionar una plataforma de desarrollo para un proyecto web

  3. Nettero dijo:

    Quieres bajarte el código fuente del .NET framework, para no volver a decir que no es OSS? Aquí te lo dejo.

    http://referencesource.microsoft.com/netframework.aspx

    • Francisco dijo:

      Hola Nettero,

      El hecho de que puedas descargar el código fuente no significa que sea software libre. De hecho si lees los EULA verás que expresamente no te permite redistribuir el software, entre otras cosas.

      Un saludo.

  4. Francisco dijo:

    Hola Sergio,

    Me ha parecido muy interesante tu artículo. Y en muchos aspectos coincido totalmente,
    en otros no tanto.

    Me gustaría preguntarte si conoces el framework (Python) Web2py. y ¿Qué opinas de él?. Yo llevo un tiempo utilizándolo para algunos proyectos y me parece realmente bueno.
    El nivel de productividad que se alcanza es enorme.

    Gracias por tu opinión.
    Un saludo

    • Francisco: no conocía Web2py, gracias por la referencia, lo descargaré y le echaré un vistazo.
      Nettero: Microsoft es menos demoníaco de lo que la comunidad FLOSS lo ha hecho parecer. Es una empresa bastante más abierta que Apple, que Oracle o incluso que la extinta Sun en sus tiempos de hard+soft ferozmente privativo. Aún así, .NET sigue siendo EULA de fuente abierta. Leyendo a Miguel de Icaza se puede comprobar el cuidado extraordinario que han tenido que tener en Mono con las patentes de Microsoft. Trabajo que hubiese sido innecesario si .NET fuese Open Source de verdad.

  5. Emilio dijo:

    Sergio, que opinas de grails?

    Aunque no lo he probado en profundidad, auna las cosas buenas de django y RoR sobre las tecnologías maduras de java.

    • Estuvimos probando Grails hace unos tres años y lo descartamos. Pero no porque fuese malo en absoluto sino porque para cuando lo probamos en 2009 ya llevábamos 10 años desarrollando Java y los problemas que resuelve Grails ya los teníamos resueltos de alguna otra manera. Pero si se va a empezar un proyecto nuevo libre de herencia tecnológica a mi me parece una opción bastante viable.

  6. Eduardo dijo:

    Hola Sergio,

    solo quería puntualizar 3 cosas:

    – Has llamado “plataformas” a lenguajes de programación (aunque luego hagas referencia a las plataformas más conocidas de cada lenguaje, como LAMP para PHP o IIS + SQL server para .NET, etc).

    – En el articulo vas lenguaje de programación en lenguaje de programación hasta que llegas a RoR. No puedes poner RoR a la altura de Java, PHP o Python, creo que lo acertado es hablar de Ruby y luego hablar de RoR así como has hablado de Python y Django, aunque también exista Sinatra.

    – Siendo del mundillo de PHP, me gustaría comentarte que Cake no es su mejor exponente actual. Si, hay muchos frameworks y este no es un artículo para ello, pero en un articulo de este tipo tal vez Zend 2, Symfony 2 (este lo usa Drupal 8 por ejemplo), Laravel o Sílex habrían sido mas representativos del PHP de hoy.

    Por lo demás es un artículo muy recomendable para los emprendedores no técnicos

  7. Hola Sergio,
    actualmente trabajo en el ambiente de ciencia y tecnología de Argentina, y me parece que este artículo aplica perfectamente al Open Source en general, y no exclusivamente a plataformas web.
    Has planteado (tácitamente) el principal problema en la evaluación de software tiene que ver con que si bien somos seres racionales, nuestra conducta se ve fuertemente influida por nuestra estructura emocional, que tiene un rol principal en las elecciones que hacemos en el transcurso de nuestra vida. De ahí que siempre nos parece que es mejor … lo que ya conocemos. Y esa emocionalidad muchas veces nos entusiasma demasiado, induciéndonos a no hacer un análisis metódico como el que estás proponiendo con los 7 criterios. Éste es un artículo para tener siempre a mano.
    Felicitaciones
    Ricardo

  8. Pingback: Cómo seleccionar una plataforma de desarrollo para un proyecto web | Conocimiento Libre (o lo que está detrás del Software Libre)

  9. Pingback: Tendencias en el desarrollo de software 2014 | La Pastilla Roja

  10. Jhony Rivero dijo:

    Excelente articulo, en lo particular soy desarrollador de .Net pero siempre he admirado la comunidad Java y he pensado muchas veces aprenderlo, lo que me enreda es que me parece confuso la eleccion entre tantas opciones de IDEs y frameworks.

  11. jorge dijo:

    php = 80% de la web mundial

  12. Miguel dijo:

    En general coincido con las apreciaciones volcadas, aunque no concuerdo con el orden de facilidad de aprendizaje que se indica.
    Hace más de 30 años que vengo aprendiendo cada vez más y sabiendo cada vez menos sobre lenguajes de programación. Cuando a balbucear en un uno, inventan dos o tres o avanzan en capacidades y caracteristicas.
    A mi criterio, la curva de aprendizaje de python para mi es la mejor.
    Se necesitan 6 veces menos instrucciones en python que C# o Java, y un 70% de lo necesario en PHP (con Ruby andan hacha y hacha)
    Eso no significa que se termine de aprender todo rápido (posiblemente, como en todos los casos, se use un 20% del lenguaje).
    Y las reglas de un programa son: Correcto, Documentado, Mantenible, Veloz.
    Puede faltar algo por ahí, pero creo que en ese orden, si tengo que tocar algo, código corto es más fácil de mantener que código largo.
    Saludos.

  13. Juan dijo:

    Hola Francisco.
    Me gustó tu comparación de alternativas de lenguajes/plataformas web.

    Respecto a .NET, Nettero tiene razón… tu lo calificaste como “no es Open Source”, y sí lo es. Open Source (fuentes abiertos, es decir, disponibles para verlos) y Free Software no son lo mismo. Y la cuestión de precios no tiene nada que ver con estos conceptos (a pesar de que hay mucho Software Libre que además es Gratis, así como hay Software “no libre” que también es Gratis).

    Saludos.

  14. Jeancarlo Fontalvo dijo:

    Genial el articulo, y sobretodo convincente.
    Tengo una pregunta:
    Si quiero desarrollar una plataforma web de Gestión Educativa, (como las que usan las instituciones educativas) ¿Qué Plataforma me recomendarías?

  15. Pedro dijo:

    Francisco … gracias.

  16. gengue dijo:

    No puedo creer que hayas dicho que python permite programar muy sucio …

  17. Luis Ramirez dijo:

    Saludos, gracias por este vistazo, ojala puedas sugerirme, estoy en proceso de análisis para un proyecto de servicio en la web para administración de centros de salud, manejo de entradas, historiales, y demás, se espera que sean al rededor de 1000 centros con un promedio de 50 pacientes cada uno, que plataforma me recomiendas???

    • 50.000 pacientes te cabrán fácilmente en una base de datos PostgreSQL, pero por experiencia previa con historiales médicos las imágenes (si hay que digitalizarlas) pueden ser un problema (sobre todo las radiografías). Si yo tuviera que hacer un proyecto así desde cero usaría Django. Pero creo que depende fundamentalmente de la disponibilidad de programadores que tengas. Si saben Ruby o Java/JSP, o incluso .NET pues también vale. 1.000 usuarios online con gente esperando en una cola a que funcione el sistema pueden dar muchísimos quebraderos de cabeza, asegúrate de que las herramientas de administración para crear usuarios y etc. son buenas y de que el sistema está montado en alta disponibilidad para que no tenga interrupciones de servicio en horas punta. Depende también de si es un proyecto puntual o pretendes revenderlo más veces. Si pretendes revenderlo desarróllalo en Java pues es la plataforma con la que te resultará más fácil conseguir un partner.

      • Luis Ramirez dijo:

        Gracias, por tu comentario de hecho por el momento solo seré yo programando, tengo mas experiencia con asp net pero con lo que esperamos de aplicación creo que seguire tu consejo al utilizar java, y le hechare un vistazo a Django. Una ultima pregunta, e realizado muchas aplicaciones pero con pocos usuarios, para esta aplicacion cada centro obviamente tendra usuarios con permisos cada uno, mi pregunta es, al dar de alta un nuevo centro es recomendable que se cree una base de datos independiente (obviamente sobre el mismo PostreSQL) para cada centro, o si solo son tablas, no es un poco inseguro??

        Gracias

        • Luis Ramirez dijo:

          Por cierto, el equipo ya esta formado, todos los demas son para administracion, ventas y demas yo me encargare de desarrollar la aplicacion, su mantenimiento y demás cosas. Entonces, cres que sea mejor desarrollarlo en asp net, conociendo claro sus costos, ya que es con el que mas experiencia tengo, y que opinas de la combinacion .NET y MySQL

  18. Pingback: Programación orientada a procesos de negocio | La Pastilla Roja

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *