Aplicaciones web sin servidor, o casi (arquitecturas serverless)

¿Cómo es esto posible? Si tenemos una cosa clara en el mundo de Internet es que si queremos tener en pie un servicio, éste debe estar alojado en una máquina que esté conectada a Internet, con energía y que nos asegure en cierta forma que está levantada. Estos servidores pueden ser de diversos tipos según las necesidades de la aplicación: web, base de datos, autentificación, tareas, logs, notificaciones, etc. Así que, ¿qué es esto de aplicaciones sin servidor? ¿o serverless?

[#1 seif]

Estas tecnologías están muy bien cuando los ingenieros o programadores las escogen después de analizarlas cuidadosamente, pero échate a temblar si las escoge el ejecutivo de turno porque le han dicho que es algo muy moderno y que le va a ahorra miles y miles de millones a la empresa.

[#2 delawen]

#1 Si es una empresa sin un departamento fuerte de administración de sistemas, subcontratar a terceros debería ser lo normal.

Igual que hace 20 años se llevaba tener tu propio servidor de correos y hoy en día casi nadie lo hace.

[#5 Shotokax]

#2 dándole los datos sensibles de tu empresa a Microsoft y a Google, y encima pagando por ello.

[#9 delawen]

#5 Bueno, hay otras empresas de pago que además te permiten encriptar y eso. Pero claro, ¿quién quiere pagar con dinero pudiendo pagar con privacidad, que les sale gratis?

[#10 Shotokax]

#9 en el mejor de los casos puedes cifrar lo que tienes almacenado en el servidor, pero el tráfico es en abierto.

[#11 delawen]

#10 O usas un cliente que cifre en local. A ver, formas hay. Lo que sí es verdad es que el correo se envía y se recibe (normalmente) en claro, por lo que siempre vas a tener ahí un problema de seguridad, pero aunque uses tu propio servidor.

En cualquier caso, no estás obligado a venderte a una gran empresa, que era lo que quería decir en #9

[#12 Shotokax]

#11 por eso digo. Si encima de ese problema lo centralizas todo en un servidor gestionado por terceros, pasando el 100% del tráfico por ahí, apaga y vámonos.

[#25 Desactivado]

#10 No tiene por qué ser en abierto.

Yo me conecto en remoto a mis servidores a través de SSH, despliego las aplicaciones y a partir de ahí las comunicaciones entre clientes y servidores se hacen a través de TLS.

En este caso los equipos son míos, pero aunque fuesen de Amazon la privacidad sería la misma.

[#26 Shotokax]

#25 eso no es externalizar el servicio de correo, sino el alojamiento de los servidores de correo por lo que deduzco. De todos modos, ¿los correos que envías cómo los cifras? Ya contesto yo: no los puedes cifrar.

[#27 Desactivado]

#26 El artículo habla de FaaS, como AWS Lambda. Ellos administran el servidor, pero el código es tuyo y puedes encriptar los datos tanto si necesitas persistencia como si no.

¿los correos que envías cómo los cifras?

Yo con GnuPG

[#28 Shotokax]

#27 yo no hablaba del artículo, sino que respondía a un comentario que decía que hoy en día el servicio de correo (no el servidor) lo externalizan todas las empresas.

¿Para qué quieres cifrarlos si no los va a descifrar el receptor (hablamos de empresas)?

[#36 Desactivado]

#28 Ah, disculpa, te entendí mal. Hablabas de SaaS (como G Suite), no de FaaS.

Entonces posiblemente tengas toda la razón. La verdad es que no conozco mucho ese ecosistema pero me puedo imaginar a un montón de ejecutivos dándose palmaditas en la espalda por lo que se han ahorrado en IT y abrazando alegremente el "yes, whatever, pase usted hasta la cocina que ya tengo el ojete dado de sí".

De hecho, apostaría a que gran parte del interés de Google en el NLP en Tensorflow se debe precisamente al afán por extraer toda esa información con la que miles de empresas les obsequian diariamente.

[#49 Shotokax]

#36 efectivamente. Cuando el big data mejore y con redes neuronales y/o computación cuántica se cepillen cualquier cifrado van a saber hasta la marca de los calzoncillos de todo el mundo con tres clicks de ratón, a no ser que los del lado del bien inventen otras cosas (eso ha ocurrido siempre y eso espero que siga ocurriendo).

[#32 vejeke]

#3 #7 #14 #10 #27

Me gustan este tipo de envíos donde los comentarios aportan incluso más que la propia noticia. La de cosas que uno aprende por aquí...

Soy teleco, no informático pero en su día para mi trabajo de fin de carrera decidí desarrollar una aplicación web y una API REST. Intrusismo a tope. Yo iba a ciegas completamente, aunque para no tener ni pajolera idea al final acabé sintiéndome bastante orgulloso de lo que pude llegar a construir, en un par de meses, aprendiendo por mi cuenta y sin ayuda de ningún tipo... Así que seguramente os parezca una mierda

Resumiendo, se trataba de dar soporte a una serie de máquinas que poseían unos sensores con los que analizaban diferentes sustancias. Mediante el uso de la API subían los resultados de los experimentos a la infraestructura nube que monté exprofeso haciendo posible al personal de laboratorio gestionar esa información a través de una aplicación web.

Lo único que tenía claro al principio es que quería programarlo todo en Python, principalmente porque ser el lenguaje más simpático de todos los que conocía y era una buena oportunidad de aprenderlo aún en mayor profundidad, y de paso comprobar si realmente servía para hacer algo así. Al final me decanté por Django como entrono de desarrollo, algo que me simplificó bastante trabajo porque logré integrar todo perfectamente con la infraestructura de AWS.

(esquema chapucero de mi querida chapuza)
https://i.imgur.com/ovO7kOP.png

Como servidor web opté por Nginx (Apache ya lo tenía muy visto y se trataba de aprender cosas nuevas) y para comunicarlo con las apps de Django (Python) usé uWSGI. Como sistema operativo Ubuntu. Todo en EC2 usando instancias T2.micro pudiendo escalarlas horizontalmente (y así sacarle el máximo partido a la capa gratuita que ofrecía AWS durante un año). Pero para ello tuve que separar cosas. Los estáticos y el contenido multimedia de la aplicación web los puse en S3 (luego los distribuía con CloudFront) y para el servidor de bases de datos use una instancia en RDS. Como sistema de gestión usé MariaDB.

https://i.imgur.com/MxWGcqa.png

La web app no era nada del otro mundo. Django me gustó bastante y en Python se hace todo muy rápido. En cuanto a la apariencia y sin entrar en mucho detalle, usé Bootstrap para que fuera adaptable (cogí el ejemplo del dashboard y a partir de ahí fui trabajando) y Google Charts para las gráficas. Poco más... La API la hice con Django REST framework. Una gozada, aunque tuve que tocar demasiadas cosas para dejarla a mi gusto.

En total usé bastantes cosas...
https://i.imgur.com/6Xfx7wa.png


Adjunto un esquema algo más profesional de la infraestructura final que puse en Amazon Web Services y que daba soporte a todo eso.

Como servidor web opté por Nginx (Apache ya lo tenía muy visto y se trataba de aprender cosas nuevas) y para comunicarlo con las apps de Django (Python) usé uWSGI. Como sistema operativo Ubuntu. Todo en EC2 usando instancias T2.micro pudiendo escalarlas horizontalmente (y así sacarle el máximo partido a la capa gratuita que ofrecía AWS durante un año). Pero para ello tuve que separar cosas. Los estáticos y el contenido multimedia de la aplicación web los puse en S3 (luego los distribuía con CloudFront) y para el servidor de bases de datos use una instancia en RDS. Como sistema de gestión usé MariaDB.

https://i.imgur.com/MxWGcqa.png

La web app no era nada del otro mundo. Django me gustó bastante y en Python se hace todo muy rápido. En cuanto a la apariencia y sin entrar en mucho detalle, usé Bootstrap para que fuera adaptable (cogí el ejemplo del dashboard y a partir de ahí fui trabajando) y Google Charts para las gráficas. Poco más... La API la hice con Django REST framework. Una gozada, aunque tuve que tocar demasiadas cosas para dejarla a mi gusto.

En total usé bastantes cosas...
https://i.imgur.com/6Xfx7wa.png

[#33 Desactivado]

#32 Pues es un stack cojonudo Salvo por MariaDB y añadiendo una cola de tareas asíncronas como Celery y un message broker como RabbitMQ yo apostaría a que es el más utilizado actualmente para desarrollar web apps en Python.

[#22 BBE]

#5 Cómo cualquier gestoria. Pocas pymes llevan solas toda su contabilidad, nominas, declaraciones trimestrales de IVA etc. etc. y son aspectos seguramente más sensibles.

[#24 manson2000]

#2 Bueno es de que no lo hace casi nadie...

[#3 Desactivado]

#1 Esas herramientas están bien para hacer experimentos con gaseosa en tu pc en casa, en el mundo real tienes que tener una infraestructura con un servidor de aplicaciones robusto como un Websphere, Weblogic o similar que de de un minimo de seguridad y fiabilidad y no basura como esta

PD: Soy Ingeniero Informático certificado por IBM en Websphere Application Server en la versión 7.0 y 8.5 y tengo más de 10 años de experiencia como administrador de estos sistemas , sé de lo que hablo y estas cosas para tu casita está muy bien, chicos de desarrolo, en una empresa jamás se os ocurra usar algo así si no queréis que los de sistemas os mandemos a la mierda directamente

PD2: si queréis puedo entrar en detalles técnicos como donde guardaría este engendro la sesión en caso de necesitarlo (no lo hace, no puede) o cuantas peticiones es capaz de aguantar antes de caerse (le metes 100 peticiones a esto y se cae, un instancia de Apache aguanta 1200 sin problemas y puedes escalar con varias instancias en vertical y horizontal, con esto no puedes)

[#4 estoyausente]

#3 Tampoco hay que cerrarse. Igual que ahora mismo puedes hacer una app sin servidor usando los servicios de. por ejemplo, firebase, puedes hacer una aplicación sin servidor como tal usando firebase y herramientas similares que ejecutan microservicios o microoperaciones. La lógica la llevas casi toda al front y utilizas la página para sesiones, almacenar datos casi en crudo y poco más.

Y eso escala y tiene sus casos de uso.

¿Vale siempre para todo? No, obviamente no, pero tiene sus casos de uso. Así que igual sí, igual en una empresa se me ocurre usarlo

[#6 Desactivado]

#4 Que sea en una empresa de las que puedes andar en zapatillas y pijama sin ducharte por sus instalaciones

Si lo haces en una seria que tenga departamento de sistemas lo más bonito que te pueden decir es "qué cojones me estás contando?".

Donde estoy yo un supuesto gurú de arquitectura quiere ponerlo todo con Dockers y microservicios y ya tiene un pié en la calle, así que no te digo más

PD: Todo esto lo digo sin ánimo de acritud y como consejo desde alguien que está en un departamento de sistemas, los experimentos están muy bien y puedes aprender muchas cosas pero luego está la realidad y la práctica. no te digo que no valga para poner una web estática que tenga publicidad o alguna chorrada no crítica pero no puedes basar tu negocio en esa infraestructura sin comprometer la seguridad, la estabilidad y la fiabilidad de la plataforma. Luego te la ataca un hacker con mínimos conocimientos para saltarse la nula seguridad de esos sistemas, consigue datos sensibles y la multa por la LODP hace que tengas que cerrar la empresa

[#20 estoyausente]

#6 Pues... no me convences.

Igual en tu empresa no cuaja y posiblemente en muchas no encaje (bancos, empresas de comunicaciones, que son muy conservadoras y tienen departamentos de sistemas muy conservadores generalmente, etc.) pero hay empresas serias que sí que tienen cosas nuevas e innovadoras como estas. Todo es cuestión de cómo es tu plataforma o servicio. No vale para todos los casos por supuesto pero está su caso de uso que aporta una solución tan válida como otras.

Aunque eso sí, si es serverless igual te quedas en paro

(No he usado Docker pero tengo compañeros que sí y tiene muchas bondades, y se usa en grandes empresas también (no de andar por casa), pero no es la panacea tiene sus puntos mierder, como todo. Si eres un gurú obsesionado con ponerlo donde no procede pues lo normal es que acabes en la calle)

[#21 Desactivado]

#20 A ver una tienda la puedes llevar con eso, como Amazon, de hecho la caida del otro día que tuvieron que dicen que fue porque un técnico ejecutó un comando que borró servidores estoy seguro que ejecutó un

docker images | grep "pattern" | awk '' | xargs docker rm

Y el patrón comprendía más de lo que creía

Eso lo haces en un websphere por accidente y el deploy manager te replica la información en cuanto reinstales el nodo (tardas 15 minutos en reinstalar el binario y federar el nodo) y luego lo que tarde en replicar lo que haya, que no tarda mucho

Vamos que para una tienda como Amazon o El Corte Ingles te valen los dockers, pero no te vale un sistema serverless. a no ser que tu tienda tenga 40 metros cuadrados y vendas calceta, por decir.

Ojo, que repito de nuevo, los experimentos para aprender están muy bien, pero en casa o en un departamento de I+D

[#35 Desactivado]

#34 Léete mi comentario de #8 #16 #21

En concreto la parte de:

"Donde estoy yo un supuesto gurú de arquitectura quiere ponerlo todo con Dockers y microservicios y ya tiene un pié en la calle, así que no te digo más"

Cuando lo echen te cuento todas las cagadas que lleva asociadas con querer meter todo el negocio con Dockers y ya va incumpliendo varias normativas de seguridad porque de momento esa tecnología está en pañales y donde estoy yo no puedes meter algo tan nuevo porque incumples hasta leyes debido a que esa arquitectura no tiene la seguridad que debería.

Luego dime que no hay por donde cogerlo cuando me baso en hechos y sí ya sé que kubernetes uno de tantos gestores de dockers, precisamente el que quieren usar aquí

[#37 Desactivado]

#35 docker en pañales????

Google funciona completamente con contaieners desde hace más de 10 años

[#38 Desactivado]

#37 Ya lo sé, Google es un buscador, no tiene que guardar tu dinero, si tiene un Docker y lo destruye no pasa nada con los logs o con los datos de tu busqueda porque se pierdan.

En un banco si tienes un contenedor que está haciendo una transferencia, hay un error y lo destruyes, esa transferencia ¿qué ha pasado con ella? se ha hecho o no? y en cualquier caso cual ha sido el error? los logs se acaban de destruir ya que estaba en el contenedor, si decides guardarlos en una unidad compartida por todos los dockers es hasta posible que se dupliquen los mismos (que es lo que nos esta pasando). ¿Cómo monitorizas un conjunto de dockers si tienes varios asociados a un servicio y varios a otro si se crean y destruyen? ¿Cuando haya un error en la plataforma en qué docker me meto a mirarlo si todos son clones unos de otro y no sé cual es el que está jodido? ¿Cómo consigo que el sistema si genera 200 docker que son clones con cada uno 50 conexiones a BBDD no tiren abajo la base de datos por exceso de conexiones? ¿cuando tengo una aplicación web que requiere un giga de JVM que hago generar un docker de 4 gigas y 4 cpus que crece segúne le de la gana?, en donde lo meto en un cray de la nasa? porque eso en un entorno tradicional tengo una máquina con 4 gigas y 4 cores y lo tengo limitado y si tengo que crecer le meto más gigas o cores a la máquina virtual con un click de manera manual pero no crece según le de la gana como un docker.

Todo esto que te pregunto son los problemas que estamos teniendo y que NO tienen solución por parte de ese super gurú de los dockers que ha venido a vender su moto para un entorno que NO sirve. Y todo esto que te pregunto no sucede con un entorno tradicional con máquinas virtuales, servidores web, de aplicaciones y Bases de datos persistentes todos ellos, porque está controlado, todo está en el mismo sitio, no se crea y se destruye continuamente, si tienes que crecer puedes hacerlo vertical u horizontalmente aunque sea de forma más lenta pero lo haces.

Dockers es una tecnología de hace 4 años, está en pañales, para tí a lo mejor es mucho pero un servidor de aplicaciones tiene casi 20 años y todavía tienen problemas pero se lo considera sólido y seguro

Lanzamiento inicial 13 de marzo de 2013 (4 años y 15 días)

https://es.wikipedia.org/wiki/Docker_(software)

[#42 Desactivado]

#38 Tu confundes docker con los containers, docker es una reimplementación libre de los contenedores que están funcionando en google desde hace más de una década. Es una tecnología madura desde su nacimiento.

Google maneja más dinero que un banco, tiene que controlar las cuentas de adsense y adwords que son como 80.000 millones de dolares anuales.

Y otra cosa, tu puedes levantar, parar y destruir contenedores pero no tienes porque perder nada porque los datos suelen estar en un volumen compartido, una base de datos o lo que sea. Docker está pensado para procesar, los datos no deberían estar dentro del mismo docker en el que trabajas con ellos.

¿Cómo monitorizas un conjunto de dockers si tienes varios asociados a un servicio y varios a otro si se crean y destruyen?
Para eso hay sistemas de gestión de contenedores. Nadie usa docker sin un sistema de gestión de contenedores salvo que sea una práctica de la carrera y solo estés usando 3.

¿cuando tengo una aplicación web que requiere un giga de JVM que hago generar un docker de 4 gigas y 4 cpus que crece segúne le de la gana?
Con docker escalas en horizontal, no en vertical. Escalar en vertical está obsoleto.

¿Cómo consigo que el sistema si genera 200 docker que son clones con cada uno 50 conexiones a BBDD no tiren abajo la base de datos por exceso de conexiones?
¿Quien te impide tener también distribuida la base de datos?

Todo lo que comentas está resuelto, yo no soy ningún guru de docker para asesorarte, si te puedo decir que este año lo hemos empezado a usar y a partir del año que viene todo lo vamos a hacer sobre docker.
Si viajas al pasado también te encontrarías con problemas al migrar a tecnologías nuevas, siempre hay problemas, pero los beneficios a largo plazo supera el coste inicial.

[#45 Desactivado]

#42
1- Google NO tiene todo en containers (y no lo confundo, antes hablaba de Dockers porque es lo que quieren poner aquí), tiene parte de su infraestructura (que será mucha no te digo que no), adivina donde tiene el dinero

2- Ese volumen compartido sabes que rendimiento tiene? aquí pretenden ponerlo en un NFS que va como el culo con respecto a tenerlo en local, aparte puedes mirar por internet, tienen varios casos reportados de rendimiento pésimo cuando se hace esa operativa y eso para empezar. El otro problema gordo que hay es que cuando hay un error tienes que bucear entre todos los logs de TODOS los dockers, destruidos y existentes, es inmanejable.

3.- Y cuando se te caiga la JVM por un outofmemory pero el docker esté arriba ¿cómo monitorizas la JVM si no tienes un gestor como el dmgr del WAS para manejarla y saberlo? a eso me refiero, NO puedes, pierdes esa capacidad, tienes el Docker arriba y tu con una JVM recibiendo peticiones que NO maneja = monitorización que no vale para nada, es como tener casas en pie que por dentro se han caido.

4-Qué más da como escales? no me has entendido, no me refiero a eso. Los Dockers escalan por su cuenta descontroladamente, pueden llenar un sistema completo y cuando otra aplicación requiera parte de ese sistema NO la va a tener, por otro lado el requerimiento de cada docker es superior al de una JVM y con menos recursos consigues más potencia con JVMs (los dockers llevan el SO y la JVM, necesitas más memoria y CPU, la JVM puedes poner varias en el mismo SO y solo requiren lo que subas en JVMs, el SO no necesita más)

5-Claro tengo una base de datos capaz de soportar 10000 conexiones para algo que a lo mejor no sube de 100, muy inteligente ;). Otra vez no lo pillas, si tengo un ataque de Denegación de servicio o una subida repentina en la demanda NO esperada en un sistema con Dockers se van a generar dockers para aceptar todas las conexiones hasta que se pete el sistema con dockers y voy a tener que tener preparada la BBDD para eso y es ridículo (las BBDDs son más complejas y caras de mantener que los servidores de aplicaciones, ¿no iba la cosa de ahorrar?) sin embargo en un entorno tradicional eso no va a suceder, no se van a "autoescalar" solas las JVMs y el el caso de que se llegue al máximo y si hace falta las reinicio y se recuperarn. Uan BBDD no se puede rebotar así como así, un servidor de aplicaciones sí.

Todo lo que comentas tiene un montón de problemas y lo sé porque lo estoy viviendo, quizás en 5 o 10 años se solvente, pero de momento los experimentos con gaseosa

[#47 Desactivado]

#45 se me haría muy largo rebatir cada uno de los puntos, pero alguno denota que has visto docker muy de lejos o no lo has visto nunca.

[#48 Desactivado]

#47 Mira mi comentario de #46 no lo digo yo sólo

En cuanto a lo de los dockers el lunes te hago un pantallazo si quieres de uno aquí

[#50 Desactivado]

#47 y me rebatirás lo que quieras y yo te pondré ejemplos como este https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/

Que es he hace pocos meses y de nuevo me da la razón. Es un software en pañales y da un montón de problemas. Dentro de 5 o 6 años quizás, ahora es experimento con gaseosa

[#52 Desactivado]

#50 no vale para todo, pero para lo que vale es la mejor alternativa.

El error es intentar hacerlo todo con la misma tecnología. Cada tecnología tiene unos determinados casos de uso.

[#53 Desactivado]

#52 La recomendación es NO usar Dockers en un entorno productivo, ahora tú mismo...

Containers reality check: Why they're still not production-ready

https://techbeacon.com/containers-reality-check-why-theyre-still-not-production-ready

PD: que sí que para alicaciones basurilla sí puedes, un buscador, una tienda (no necesitan seguridad, si te roban tu cesta de la compra, qué van a hacer con ella?)... para aplicaciones críticas (las de la pasta) NO

Repito, tecnología en pañales... en 5 años quizás, ahora NO

Are containers production-ready?

So are we any closer to mainstream containerization and moving containers into production environments?

The answer is nuanced. Are we closer? Yes. Are we there yet? No, and we still have a long way to go.

[#54 Desactivado]

#53 en tu caso opinaras eso, en el mio opino que es la mejor opción y de ahora en adelante lo vamos a usar en todos los proyectos

[#55 Desactivado]

#54 Pues suerte, en serio

[#39 AndyG]

#35 He trabajado con una aseguradora que esta moviendo parte de su carga a contenedores docker en Azure, y el resto lo mantiene en una nube privada (que tambien van a migrar a docker), pero supongo que no tienen ni idea de lo que estan haciendo, en temas de seguridad, normativa y tal ¯\_(ツ)_/¯

[#40 Desactivado]

#39 ¿la parte que estáis moviendo es crítica o es la parte que si se cae o se va a la mierda no pasa nada? proque aquí también hay Azure, ¿sabes para que lo usamos? para el entorno PREproductivo de una basura de aplicación, no hay nada más en la nube porque legalmente no podemos y tú al estar en una aseguradora la parte con información sensible tampoco la vais a poder subir a la nube así como así, y si no lo sabes es que no estás bien informado.

Aquí los dockers pretenden ponerlos en el propio CPD

[#41 AndyG]

#40 La idea es mover a Azure todo lo posible, y lo que no se pueda se migra también a contenedores, pero en la nube privada.

Estoy enterado de los temas de compliance, para eso existen las zonas de disponibilidad.

Pero me parece que mejor me voy a callar, porque según los gurus de meneame no tenemos ni idea

[#43 Desactivado]

#41 No, no soy un gurú, soy Ingeniero Informático certificado como Administrador de servidores de aplicaciones Websphere aparte de tener 12 años de experiencia con estas tecnologias. Los gurus son los cuñaos que creen que saben que saben más con algo que tiene 4 años que el que sabe de algo que tiene 20 años de existencia y tiene 12 de experiencia con ello.

Si tu departamento de sistemas está metiendo todo en dockers y ha aceptado o desarrollo manda más o las tragaderas del responsable de sistemas son de campeonato.

Cuando haya un error en el sistema grave a ver como lo debuggean, en serio te deseo mucha suerte si estás en el ajo porque a mi no me gustaría

[#44 AndyG]

#43 Iba a editar mi comentario anterior pero ya que estoy te contesto.

Aquí va un ejemplo real de uso de docker en producción, uno de tantos.

https://schd.ws/hosted_files/cloudnativeeu2017/e2/Kubernetes-From-Dev-To-Prod-GoEuro.pdf

Ahí desmonta las gilipolleces de compliance, escalabilidad, y ahora que lo mencionas motorización (porque por supuesto no existen los sistemas de motorización).

[#46 Desactivado]

#44 https://blog.philipphauer.de/discussing-docker-pros-and-cons/

Disadvantages and Challenges
After praising Docker (too much?), let’s consider the drawbacks and challenges when using Docker:

Increased complexity due to an additional layer. This affects not only the deployment but also the development and build.
In addition, managing a huge amount of containers is challenging – especially when it comes to clustering containers. Tools like Google Kubernetes and Apache Mesos can help here.
The containers share the same kernel and are therefore less isolated than real VMs. A bug in the kernel affects every container.
Docker bases on Linux Containers (LXU), which is a Linux technology. Therefore, we can’t run Docker on other systems and our container is always a Linux system. But Boot2Docker enables the usage of Docker on Windows and Mac OS X by using VirtualBox. The Docker client runs on the host OS and communicates with the Docker daemon inside the VirtualBox. Unfortunately, this is less comfortable and makes daily use clumsy and more complicated than running Docker natively.
Introducing Docker can be a demanding and time-consuming task. We have to evaluate if it is worth the effort and the increased complexity. In a past project of mine, the management rejected Docker with the argument, that 3 nodes (production, pre-production and experimental) are not enough to justify the effort… However, when you have a cluster of nodes (when scaling horizontally) or use Continuous Delivery you need an approach to reproduce environments and Docker is brilliant in this. Moreover, Continuous Delivery reduces the time-to-market (new features can be brought to production faster because the deployment and environment setup is automated), which can be used to convince the management.
I also made the experience that there are also reservations about Docker in strictly regulated domains (like the banking sector):
To run a container you need root rights. This can be a problem for some companies, in which the colleagues that are supposed to run and update the application on the production server must not have root rights.
It is unclear if the usage of Docker agrees with certain security standards which have to be fulfilled (like PCI).
In some companies, there is the questionable rule, that only software from official/trusted sources can be installed on the machines. For instance, Docker is not included in Red Hat Enterprise Linux 6 and therefore needs to be installed from docker.com, which is an “untrusted source”.

https://www.quora.com/Is-Docker-ready-for-production

Further, from an ecosystem standpoint there are critical elements still missing or very immature:

Monitoring - This is something of a Docker issue as well as a full spectrum of metrics is only now coming on line for the currently line of tools to incorporate. (e.g. New Relic, Zabbix, Data Dog)
Logging - Companies that have sophisticated log strategies around customer usage behaviors and patterns find the STDOUT and STDERR paradigm to be far to limiting. Again the very recent addition of facilities such as syslog mean that the ecosystem will now be able to develop this sophistication (e.g. Splunk, Sumologic, Logstash)

[#23 seif]

#3 Yo también soy ingeniero informático con unos 7 años de experiencia, tal y como indica #4 no hay que cerrarse a nuevas ideas, estos sistemas tienen sus posibilidades y pueden ofrecer cosas útiles, a mi personalmente no me gusta depender en exceso de terceros pero hay ocasiones en que ahorran mucho tiempo de desarrollo. Todo depende de lo grande que sea la empresa en cuestión y de la finalidad del proyecto. No es lo mismo una startup que requiere obtener un producto rápido para entrar en el mercado y conseguir financiación, que una gran empresa ya consolidada que dispone de su departamento de sistemas. Incluso en una gran empresa, no es lo mismo una aplicación interna en fase de producción que un proyecto de marketing digital.

[#29 Desactivado]

#23 Ya lo he explicado antes y dije lo mismo, estoy de acuerdo en lo de experimentar y aprender

Léete mi comentario de #8 y #16

[#7 ktzar]

#3 Quizás recomiendas Websphere Application Server porque es en lo que estás certificado y llevas diez años anclado a esa tecnología. ¿Puede ser? Serverless puede ser una pasada si haces las cosas bien. NodeJS en la nube puede sonar muy cool y muy moderno, pero además de ello, funciona.

Todas las tecnologías tienen sus puntos fuertes. Pero cuanto más pasa el tiempo más aborrezco Java.

PD: No soy ingeniero informático, no tengo certificaciones oficiales, pero he desarrollado y mantenido aplicaciones que usaban 50k personas a la vez (sí, 6 millones al día) con la tecnología arriba descrita. Downtime? 👌 Y lo mejor de todo, no necesitábamos a nadie "de sistemas", ya que podíamos configurar el escalado nosotros mismos y con un coste inferior al anterior con el datacenter de la empresa. Ah, y no hacían falta CABs ni reuniones ni tickets para hacer pases a producción. ¿Acaso sabes cómo funciona alguna de las empresas que hacen software, que probablemente uses, y sirven millones de peticiones cada hora? Hint: pocas (si acaso alguna) usan Websphere.

No hay balas de plata, pero comentarios con tantas "verdades absolutas" como el tuyo chirrían un poco

[#8 Desactivado]

#7 No, en serio puedes usar Tomcat como servidor de aplicaciones y si quieres algo más avanzado JBoss (la versión gratuita), ambos gratis, al igual que Apache como webserver, en cuanto a tener varios servidores puedes usar máquinas virtuales puedes usar virtualbox u otras soluciones Linux, todo gratis.

Pues parece que no sabes de lo que hablas Nodejs no te vale para todo, nodejs es un runtime para aplicaciones ens javascrip que no es igual que tomcat que es para aplicaciones escritas en java, se usan para cosas distintas, aparte de la seguridad de nodejs que es nula (he administrado nodejs también) y que no es stateful (persistencia de sesion, bueno la tiene pero es de risa, el sistema es un cachondeo que puede fallar como una escopeta de feria), para llevar el buscador de productos que te saca el listado de los mismos a toda velocidad del Corte Inglés está muy bien nodejs pero para otras cosas no.

[#13 ktzar]

#8 Pretender mantener la sesión en el servidor de aplicaciones es algo que no tiene mucho sentido si haces algo que va a tener una mínima carga. Es una aproximación que no escala bien, a no ser que andes con cookies de sticky sessions en el balanceador de carga (se dice así?).

Es cierto que el grave problema de NodeJS es que muchas veces se usa para generar pequeños programas escritos por gente que aprendió a programar con "jQuery"... Pero es una tecnología que ha madurado muy rápido y con la que se pueden hacer cosas espectaculares a una velocidad que antes era impensable.

"la seguridad de nodejs que es nula", en concreto, ¿el qué? No creo que haya habido muchas más vulnerabilidades en la pila http de node que en la que implemente Jetty o Tomcat.

Casi cualquier tecnología vale para todo, otra cosa es que sea la más idónea. No creo que haya nada que no se pueda hacer en NodeJS que sí se pueda hacer con la pila que describías antes. Y, además, cada vez soy más de la opinión que hay menos y menos cosas para las que Java sea la herramienta ideal. Implementar lógica de negocio en Java es un suplicio. Cada vez tengo más claro que el problema es la orientación a objetos, es una abstracción errónea.

[#14 delawen]

#7 y #8 Los dos tenéis razón, pero cada uno en un caso de uso diferente.

#13 Si necesitas guardar datos personales de tus usuarios, ten mucho cuidado con los serverless. Porque si es una infraestructura que va saltando de país según la demanda, podría pasar que los datos personales de tu usuario también salten de país según la demanda, cosa que por ejemplo en Europa está prohibido y te podrían meter una multa de las de tener que cerrar la empresa de golpe.

No es sólo que tecnológicamente se pueda, es también los problemas de seguridad y privacidad asociados a no tener un servidor quieto con sus datos quietos y sus sesiones quietas.

[#15 ktzar]

#14 Es un muy buen punto. En mi ex-empresa implementamos nuestro sistema serverless (básicamente un proxy con AutoScaling a mini-módulos NodeJS almacenados en S3) dentro de AWS para que eso no sucediera y todo se sirviera desde Europa.

Todo depende, y mal usado te puede salir más caro que una flota de servidores (por ejemplo, para procesar datos a un ritmo estable 24/7). Pero cuando hay cosas que hay que hacer de cuando en cuando, en función de eventos, el poder tener tu lógica de negocio de forma serverless y despreocuparte de servidores, provisioning, configuración, autodescubrimiento, y mil cosas más, es una pasada.

Y vaya, no hablo de editar tu código en el mini-editor de AWS Lambda, serverless es compatible con control de versiones, unit testing, diferentes entornos... Quizás ese es el problema que mucha gente le ve, que a primera vista es para scripts pequeños que escribes en la misma consola de AWS, cuando se puede automatizar el despliegue de código automáticamente...

Joder, lo que me cuesta hablar de estas cosas en español ya...

[#17 delawen]

#15 para que eso no sucediera y todo se sirviera desde Europa.

Incluso dentro de Europa, los datos no pueden volar alegremente. Por eso lo digo. Que salga de Europa es aún peor, pero que viajen dentro de Europa también puede ser un problema.

Que vamos, yo en el trabajo también uso hosting de terceros sobre los que desplegamos diferentes contenedores Java (sí, Java, sigue teniendo sentido en según qué casos para procesos complejos). Entiendo el concepto de serverless y se lo ofrecemos a nuestros clientes. Pero ni es para todos ni es para usar a lo loco.

[#16 Desactivado]

#13 La sesión y sus datos (por ejemplo todo lo que se va haciendo en una web de una banco con sus operaciones cuando estás logado) se mantiene en BBDD o en otra instancia de una JVM (se llama memory-to-memory aunque no se usa mucho porque es poco estable) en el propio servidor de Aplicaciones pero igualmente es gestionada por el servidor de aplicaciones, si el servidor de aplicaciones se cae (se cae la JVM con todos tus datos de sesión) otro ocupa su lugar y coge los datos de la sesión de BBDD o de la JVM habilitada para ello.

Tú de lo que hablas es para el caso de que se caiga el webserver, no el servidor de aplicaciones

Sobre la seguridad del nodejs vs un servidor de aplicaciones

"The core of Node is JavaScript, so Node inherits any concerns there might be with JavaScript. However, the execution context of V8, the JavaScript engine Node uses, is entirely different than a browser because it executes on the server. That difference adds some unique surface area [for attacks].

Mark Stuart, a senior UI engineer at PayPal, advises developers to use good security defaults and scanning of modules. "Node is still JavaScript, so eval and all the terrible things on the client side still exist on the server side," Stuart said. (The eval function evaluates code represented as a string but poses the risk of running malicious code.)


http://www.infoworld.com/article/2607982/node-js/article.html

Más

JavaScript Frameworks Supported by Checkmarx

While not a JavaScript framework itself, a majority of Node.js modules are written in JavaScript and developers are able to add and write new modules in JavaScript. Node.js has an event-driven architecture that is used in many popular real-time web applications which include communication tools and in-browser games and is the most leading cross-platform runtime environment for server side applications written in JavaScript. Trusted by some of the biggest names on the web, including GoDaddy, Groupon, IBM, Netflix, etc., Node.js can also utilize code written in Edge.js, Lua, Julia and COBOL.

Vulnerabilities associated with Node.js include application layer DDoS, attacks which can bring servers to their knees, brute-force attacks and business logic attacks.


https://www.checkmarx.com/sast-supported-languages/javascript-overview-and-vulnerabilities/

jetty es para lo que es, es rápido, más que el tomcat y te libras de tener un apache por delante pero no lo pongas en un entorno con aplicaciones críticas

[#19 Desactivado]

#18 Léete mi comentario de #8 y #16

[#18 mmm_]

#3 A mí esto me suena a "esto es lo que yo uso y es lo mejor porque es lo que yo uso y quien use otra cosa lo hace obviamente MAL".

[#30 Desactivado]

Estoy de "inventos" en la web hasta la coronilla. Cada 6 meses sacan un invento que viene a revolucionar una mierda y que promete el oro y el moro a base de aumentar la complejidad lo que no está escrito. Está muy bien experimentar en tu casa, pero como dice #3, los experimentos con gaseosa.

[#34 AndyG]

#3 Tu comentario no hay por donde cogerlo. Échale un vistazo a docker, kubernetes y todo el ecosistema alrededor.

[#31 impalah]

Mantener tus propios sistemas es muy bonito e interesante. A mí me gusta también tocar hierro y el olor de un CPD por las mañanas.

Pero cuando has de cuidar del dinero me voy de cabeza a soluciones "de la nube". Con el volumen de datos con el que trabajo (más de 10 millones de registros generados por hora, que han de ser procesados cada 5 minutos máximo, para tener informes fiables con decenas de agrupaciones posibles, con tiempos de respuesta de menos de 5 segundos) mantener un cluster de servidores de bases de datos se iría de presupuesto, y con cosas como Amazon Redshift te lo dan todo hecho y no te has de comer la cabeza para exprimirle hasta la última gota a cada servidor.

Cedes tus datos y te haces dependiente del servicio que te ofrecen otros... pero a cambio te sale por una fracción muy pequeña del coste de hacértelo tú mismo. Hasta que tus ingresos te permitan pagarte tu propio CPD y tus técnicos para mantenerlo operativo, personalmente, me parece una solución adecuada.

Por otro lado, que he visto críticas a nodejs, y alabanzas a Java (no me gustan ni uno ni el otro)... vamos a ver, si eliminas los bugs que pueda tener la máquina virtual en la que se ejecuta el código, los problemas de seguridad suelen ser debidos a un mal diseño o una mala implementación del código. Si contratas a gente chapucera y la pones al cargo de partes críticas del sistema, luego no te extrañes de que te salga una puta mierda.

Si en vez de enseñar lenguajes se enseñase a programar, las cosas probablemente saldrían mucho mejor. Y lo digo desde mi experiencia auditando código realizado por supuestos "senior". Cortarles las manos sería incluso amable.

[#51 Ricky]

¿Cómo veis las aplicaciones "12 factor", como las que se despliegan en Heroku?