28 meneos
1039 clics
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?
|
comentarios cerrados
Igual que hace 20 años se llevaba tener tu propio servidor de correos y hoy en día casi nadie lo hace.
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
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?
No hay balas de plata, pero comentarios con tantas "verdades absolutas" como el tuyo chirrían un poco
En cualquier caso, no estás obligado a venderte a una gran empresa, que era lo que quería decir en #9
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.
#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.
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...
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.
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)
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.
¿los correos que envías cómo los cifras?
Yo con GnuPG
¿Para qué quieres cifrarlos si no los va a descifrar el receptor (hablamos de empresas)?
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.
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)
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.
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...
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.
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.
Google funciona completamente con contaieners desde hace más de 10 años
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
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.
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).
El error es intentar hacerlo todo con la misma tecnología. Cada tecnología tiene unos determinados casos de uso.