NOTICIAS SOBRE LINUX
28 meneos
1023 clics
Aplicaciones web sin servidor, o casi (arquitecturas serverless)

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?

| etiquetas: serverless , aplicaciones web , linux
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.
#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.
#2 dándole los datos sensibles de tu empresa a Microsoft y a Google, y encima pagando por ello.
#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?
#9 en el mejor de los casos puedes cifrar lo que tienes almacenado en el servidor, pero el tráfico es en abierto.
#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
#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.
#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.
#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. :-)
#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 ;)
#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)?
#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.
#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).
#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…  media   » ver todo el comentario
#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.
#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.
#2 Bueno es de que no lo hace casi nadie...
#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…   » ver todo el comentario
#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 :-P
#4 Que sea en una empresa de las que puedes andar en zapatillas y pijama sin ducharte por sus instalaciones :troll:

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…   » ver todo el comentario
#6 Pues... no me convences. :-P

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…   » ver todo el comentario
#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 '{print $1}' | xargs docker rm

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

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…   » ver todo el comentario
#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…   » ver todo el comentario
#35 docker en pañales????

Google funciona completamente con contaieners desde hace más de 10 años
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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.
#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í
#47 y me rebatirás lo que quieras y yo te pondré ejemplos como este 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
#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.
#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

techbeacon.com/containers-reality-check-why-theyre-still-not-productio

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…   » ver todo el comentario
#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
#54 Pues suerte, en serio
#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 ¯\_(ツ)_/¯
#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
#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 :-(
#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
#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.

schd.ws/hosted_files/cloudnativeeu2017/e2/Kubernetes-From-Dev-To-Prod-

Ahí desmonta las gilipolleces de compliance, escalabilidad, y ahora que lo mencionas motorización (porque por supuesto no existen los sistemas de motorización).
#44 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

…   » ver todo el comentario
#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.
#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
#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…   » ver todo el comentario
#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,…   » ver todo el comentario
#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…   » ver todo el comentario
#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.
#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…   » ver todo el comentario
#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.
#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…   » ver todo el comentario
#18 Léete mi comentario de #8 y #16
#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".
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.
#3 Tu comentario no hay por donde cogerlo. Échale un vistazo a docker, kubernetes y todo el ecosistema alrededor.
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…   » ver todo el comentario
¿Cómo veis las aplicaciones "12 factor", como las que se despliegan en Heroku?
comentarios cerrados

menéame