RubyRussia 2019: Nikolay Sverchkov sobre sin servidor

28 de septiembre en la conferencia RubyRussia Nikolai Sverchkov hará una presentación Serverless is Ruby Future. Ivan Solovyov discutió en una entrevista por qué esta tendencia es interesante y por qué los rubistas deberían prestarle atención.




Dime como llegaste a Ruby?

Comenzó a programar en la universidad. Toda la práctica estaba en C ++, pero hice los últimos trabajos y tesis en Ruby. Por qué elegí Ruby, no lo diré con certeza, probablemente porque el idioma en ese momento estaba en la estela del bombo. Nadie sabía en la Universidad de Ruby, mucho menos enseñaba. Pero después de la graduación, quería escribir en Java. Entonces me pareció que Java es especial, los desarrolladores más geniales, una especie de casta superior de programadores, y quería ser uno de ellos. Mi primera entrevista de trabajo fue en Java junior, y fracasé con éxito. Pero pudo ingresar a una empresa donde se necesitaba a Ruby. ¡Quizás sea lo mejor! Solo un par de años se movieron hacia Elixir. Ahora trabajo en Evil Martians, haciendo backend.

Su informe en sin servidor. ¿Cómo comenzó a trabajar en esta dirección? ¿Es difícil la entrada a la tecnología?

Comenzó a estudiar en su tiempo libre. Tenía una tarea real, pero no relacionada con el trabajo principal. Luego comenzó a usar sin servidor en los proyectos de la compañía. El umbral de entrada es bastante bajo, creo que es solo un poco más alto que el de Heroku. Escribe tu primer "¡Hola, mundo!" será muy simple: hay un montón de artículos, tutoriales, documentación extremadamente rica de Amazon. Y luego, por supuesto, habrá dificultades. Hay dificultades, hablaré sobre algunas de ellas en el informe.

¿Deben los principiantes sumergirse en sin servidor y usarlo en producción?

Yo creo que si! Pero no hay necesidad de apresurarse a implementar todo sin servidor. Para comenzar, puede mirar su aplicación y encontrar en ella una pequeña parte de la lógica empresarial, que puede poner en un servicio separado. Si este nuevo microservicio tiene una interfaz de comunicación simple, con un 99% de probabilidad podrá implementarlo utilizando el mismo AWS Lambda. Idealmente, si es una lógica empresarial sin estado, entonces no tiene que pensar en cómo guardar los resultados, piense en los artefactos de la ejecución de su función lambda. Como ejemplo, enviar una carta puede ser una buena primera tarea. En mi informe, plantearé por separado la pregunta de para qué espectro de tareas se adapta mejor el modelo de computación sin servidor.

La recomendación principal es separar el código de lógica de negocios de las lambdas mismas. Esta es una variación de la regla dolorosamente familiar "controladores delgados, modelos gruesos". Primero, será más fácil probar de esta manera. En segundo lugar, si en el proceso se da cuenta de que sin servidor no es adecuado para su tarea, puede migrar fácilmente a una solución probada, por ejemplo, reemplazar la capa de entrada sin servidor con un servidor web normal. En este sentido, muy buenos jets . Este es un marco Ruby Serverless que le permite escribir una aplicación que se puede implementar de inmediato en AWS Lambda y en una instancia regular de Amazon EC2.

¿Cuéntame más sobre este marco Ruby?

Jets es único en su clase. A pesar del hecho de que existen otros frameworks sin servidor diseñados para ciertos idiomas, Jets es el más funcional. Ahora tiene más de 2500 cometidos en el maestro. El marco utiliza muchas convenciones familiares para un desarrollador de Ruby, es un "Ruby on Rails en Serverless". Pero esto tiene sus inconvenientes. Dado que con un modelo informático sin servidor paga el tiempo de ejecución del código, la inicialización y carga de una gran cantidad de dependencias pesadas es costosa en el sentido literal de la palabra. La divulgación de este tema también tendrá tiempo en mi informe.

¿Qué plataformas son más comunes para sin servidor ahora, cuáles son sus diferencias, cuál es mejor elegir? Según tengo entendido, ahora se está ahogando por Amazon Web Services, ya que la mayoría de las veces habla de ello.

¿Preguntas por qué a menudo uso la palabra "lambda" en nuestra conversación? Creo que la historia es como con Karcher o Xerox. Hay marcas con el nombre de las cuales se acostumbra llamar a un nicho completo de productos. En 2014, Amazon fue el primero en proporcionar acceso público a un modelo informático sin servidor: AWS Lambda. Todos los demás: Microsoft con Azure Functions, Google con Cloud Function, IBM con IBM Cloud Functions, todavía está mentalmente en el papel de ponerse al día. Aunque el mercado sin servidores está en auge, los precios de los servicios de AWS suelen ser más altos que los de la competencia. Entonces, los nuevos lanzamientos, como Google Cloud Run , pueden cambiar el juego de la noche a la mañana. Si realizamos un análisis más detallado de las comparaciones de plataformas, entonces recomendaría ver un video de Ruslan Serkin de DataArt de la conferencia DUMP 2019 .

¿Qué piensas, en qué dirección se desarrollará sin servidor?

¡Oh, esta es la parte más interesante de mi informe! Puedo prescindir de spoilers, ¡ven a escucharme! En cambio, puedo hablar sobre la inútil y la producción. En abril de este año, estuve en la conferencia RubyConfBy en Minsk, en la que habló el autor de los mismos Jets. En la fiesta posterior, discutimos el desarrollo sin servidor y por qué, si existe el apoyo de los principales actores de la industria, no vemos la distribución masiva de las funciones lambda. Las ventajas del modelo son obvias, el ecosistema es transparente, pero no existe una confianza generalizada por parte de la comunidad de TI. Como resultado, llegamos a la conclusión de que ahora sin servidor es una especie de jugador en la sombra y la situación recuerda un poco a la que estaba con Docker en un momento. Hace tiempo que se cree que Docker en producción es un suicidio. Ahora vemos que la contenedorización es la herramienta principal para la distribución de software. Creo que en el futuro, sin servidor espera lo mismo. Cada vez más personas confiarán en él.

¿Sin servidor matará monolitos?

Esta pregunta puede reformularse como "¿La arquitectura del microservicio matará a los monolitos?" Como serverless es un microservidor ideal: es pequeño, no tiene estado y tiene una interfaz mínima para comunicarse con el mundo exterior. Así como los microservicios no matan monolitos, las lambdas no matan monolitos. Las tres arquitecturas tienen una gama específica de tareas a las que se adaptan idealmente. Y viceversa: hay tareas en las que, por ejemplo, no es práctico utilizar el servidor sin servidor. Busque detalles en mi informe.

¿Qué hacer con la cerradura del vendedor? Por ejemplo, desarrolló una lambda para Amazon, pero decidió mudarse a Google.

La migración entre plataformas es dolorosa si no utiliza algún tipo de marco, por ejemplo, sin servidor , que proporciona una API abstracta sobre los proveedores de la nube y le permite implementar la misma función en Amazon y Google. Si, en términos generales, haces todo con tus manos, entonces sí, será un poco doloroso.

¿Qué hacer con lambdas comunes cuando se usa código? Por ejemplo, algunos componentes comunes, algunas funciones utilitarias, etc.

Todavía no hay mejores prácticas sobre este tema. Y la pregunta puede reformularse nuevamente en "¿Cómo buscar un código común entre microservicios?", Porque el significado es el mismo. Hay una opción cuando mantiene la lógica reutilizada en algún lugar compartido, y en la función misma la conecta. Este enfoque funcionará bien, por ejemplo, con Go, donde la salida que obtiene es un archivo ejecutable. Otra opción es deshacerse de la conectividad de los componentes y permitir la duplicación. Probablemente valga la pena intentarlo y ver qué funciona mejor. Lo único que puedo aconsejar es que no intente hacer que las funciones lambda sean universales. En algún momento, puede parecerle que una función súper sería la solución perfecta para el problema de la duplicación de código. Pero con el tiempo, te darás cuenta de que este es el camino a ninguna parte. Obtendrá una cierta "versión monolítica de sin servidor" con todos los problemas de la primera y segunda arquitectura.

¡Discutiremos con más detalle después del informe sobre RubyRussia!

Ven y tú, la inscripción aún está abierta, la conferencia se realizará el próximo sábado 28 de septiembre.

No solo habrá informes, sino también stands de las mejores empresas:

Organizador - Evrone
Socio general - Toptal
Gold Partner - Gett
Socios de plata: Valarm , JetBrains , Bookmate y Cashwagon
Socio de bronce - InSales