RubyRussia 2019: Nikolay Sverchkov about serverless
At the RubyRussia conference on September 28, Nikolai Sverchkov will give a talk on Serverless is Ruby Future. Ivan Solovyov discussed in an interview why this trend is interesting, and why rubists should pay attention to it.
Tell me how you came to Ruby?
He started programming at the university. All practice was in C ++, but I did the last term papers and thesis in Ruby. Why I chose Ruby, I won’t say for sure, probably because the language at that time was in the wake of hype. Nobody knew at Ruby University, much less taught. But after graduation, I wanted to write in Java. Then it seemed to me that Java is special, the coolest developers, a kind of higher caste of programmers, and I wanted to be one of them. My first job interview was in Java junior, and I successfully failed. But he was able to get a company where Ruby was needed. Maybe it's for the best! Only a couple of years moved towards Elixir. Now I work in Evil Martians, doing backend.
Your report on serverless. How did you start working in this direction? Is the entrance to technology difficult?
He began to study in his spare time. I had a real, but not related to the main work task. Then he began to use serverless in the company's projects. The entry threshold is quite low, I think that it is only slightly higher than that of Heroku. Writing your first “Hello, world!” Will be very simple - there are a lot of articles, tutorials, extremely rich documentation from Amazon. And then, of course, then there will be difficulties. There are pitfalls, I will talk about some of them in the report.
Should beginners dive into serverless and use it in production?
I think yes! But no need to rush to implement everything with serverless. First, you can look at your application and find in it a small piece of business logic that you can put in a separate service. If this new microservice has a simple communication interface, then with 99% probability you will be able to implement it using the same AWS Lambda. Ideally, if this is a stateless piece of business logic, then you don’t have to think about how to save the results, think about the artifacts of the execution of your lambda function. As an example, sending a letter can be a good first task. In my report, I will separately raise the question of what spectrum of tasks the serverless model of computing is best suited for.
The main recommendation is to separate the business logic code from the lambdas themselves. This is a variation of the painfully familiar rule “thin controllers, thick models”. First, it will be easier to test this way. Secondly, if in the process you understand that serverless is not suitable for your task, you can easily migrate to a proven solution, for example, replace the serverless input layer with a regular web server. In this regard, very good Jets . This is a Ruby Serverless framework that allows you to write an application that out of the box can be deployed to both AWS Lambda and a regular Amazon EC2 instance.
Tell me more about this Ruby framework?
Jets is one of a kind. Despite the fact that there are other serverless frameworks tailored for certain languages, Jets is the most functional. Now he has more than 2500 commits in the master. The framework uses a lot of familiar conventions for a Ruby developer, it’s such a “Ruby on Rails on Serverless”. But this has its drawbacks. Since with a serverless computing model you pay for the execution time of the code, the initialization and loading of a large number of heavy dependencies is expensive in the literal sense of the word. Disclosure of this topic will also be given time in my report.
What platforms are most common for serverless now, what are their differences, which one is better to choose? As I understand it, you are now stomping for Amazon Web Services, since most of the time you talk about it.
You ask why I often use the word “lambda” in our conversation? I think the story is like with Karcher or Xerox. There are brands by the name of which it is customary to call a whole niche of products. In 2014, Amazon was the first to provide public access to a serverless computing model - AWS Lambda. Everyone else: Microsoft with Azure Functions, Google with Cloud Function, IBM with IBM Cloud Functions, is still mentally in the role of catching up. Although the serverless market is booming, AWS's service prices are often higher than competitors. So new releases, such as Google Cloud Run , can turn the game overnight. If we conduct a more detailed analysis of platform comparisons, then I would recommend watching a video of Ruslan Serkin from DataArt from the DUMP 2019 conference .
What do you think, in what direction will serverless develop?
Oh, this is the most interesting part of my report! I can do without spoilers - come listen! Instead, I can talk about serveless and production. In April of this year, I was at the RubyConfBy conference in Minsk, at which the author of the same Jets spoke. At the afterparty, we discussed serverless development and why, if there is support from major industry players, we do not see the mass distribution of lambda functions. The advantages of the model are obvious, the ecosystem is transparent, but there is no widespread trust on the part of the IT community. As a result, we came to the conclusion that serverless is now a kind of shadow player and the situation is somewhat reminiscent of the one that was with Docker at one time. It has long been believed that Docker in production is suicide. Now we see that containerization is the main tool for software distribution. I think that in the future, serverless will do the same. More and more people will trust him.
Will serverless kill monoliths?
This question can be rephrased as "Will the microservice architecture kill monoliths?" Because serverless is an ideal microserver - it is small, it is stateless and has a minimal interface for communicating with the outside world. Just as microservices do not kill monoliths, so lambdas do not kill monoliths. All three architectures have a certain range of tasks to which they are ideally suited. And vice versa - there are tasks where, for example, serverless is impractical to use. Look for details in my report.
What to do with vendor lock? For example, you developed a lambda for Amazon, but decided to move to Google.
Migration between platforms is painful if you do not use some kind of framework, for example, serverless , which provides an abstract API over cloud providers and allows you to deploy the same function in both Amazon and Google. If you, roughly speaking, do everything with your hands, then yes, it will be a little painful.
What to do with common lambdas when using code? For example, some common components, some utilitarian functions, and so on.
There are still no best practices on this subject. And the question can again be reformulated in "How to fumble a common code between microservices?", Because the meaning is the same. There is an option when you hold the reused logic somewhere in shared, and in the function themselves connect it. This approach will work well, for example, with Go, where at the output you get one executable file. Another option is to get rid of component connectivity and allow duplication. Probably worth a try and see what works best. The only thing I can advise is not to try to make universal lambda functions. At some point, it might seem to you that one uber function would be the perfect solution to the problem of code duplication. But over time, you will realize that this is the road to nowhere. You will get a certain “monolithic version of serverless” with all the problems of the first and second architecture.
We will discuss in more detail after the report on RubyRussia!
Come and you, registration is still open, the conference will be held next Saturday, September 28th.
There will be not only reports, but also stands of the best companies:
Organizer - Evrone
General Partner - Toptal
Gold Partner - Gett
Silver Partners - Valarm , JetBrains , Bookmate, and Cashwagon
Bronze Partner - InSales
Tell me how you came to Ruby?
He started programming at the university. All practice was in C ++, but I did the last term papers and thesis in Ruby. Why I chose Ruby, I won’t say for sure, probably because the language at that time was in the wake of hype. Nobody knew at Ruby University, much less taught. But after graduation, I wanted to write in Java. Then it seemed to me that Java is special, the coolest developers, a kind of higher caste of programmers, and I wanted to be one of them. My first job interview was in Java junior, and I successfully failed. But he was able to get a company where Ruby was needed. Maybe it's for the best! Only a couple of years moved towards Elixir. Now I work in Evil Martians, doing backend.
Your report on serverless. How did you start working in this direction? Is the entrance to technology difficult?
He began to study in his spare time. I had a real, but not related to the main work task. Then he began to use serverless in the company's projects. The entry threshold is quite low, I think that it is only slightly higher than that of Heroku. Writing your first “Hello, world!” Will be very simple - there are a lot of articles, tutorials, extremely rich documentation from Amazon. And then, of course, then there will be difficulties. There are pitfalls, I will talk about some of them in the report.
Should beginners dive into serverless and use it in production?
I think yes! But no need to rush to implement everything with serverless. First, you can look at your application and find in it a small piece of business logic that you can put in a separate service. If this new microservice has a simple communication interface, then with 99% probability you will be able to implement it using the same AWS Lambda. Ideally, if this is a stateless piece of business logic, then you don’t have to think about how to save the results, think about the artifacts of the execution of your lambda function. As an example, sending a letter can be a good first task. In my report, I will separately raise the question of what spectrum of tasks the serverless model of computing is best suited for.
The main recommendation is to separate the business logic code from the lambdas themselves. This is a variation of the painfully familiar rule “thin controllers, thick models”. First, it will be easier to test this way. Secondly, if in the process you understand that serverless is not suitable for your task, you can easily migrate to a proven solution, for example, replace the serverless input layer with a regular web server. In this regard, very good Jets . This is a Ruby Serverless framework that allows you to write an application that out of the box can be deployed to both AWS Lambda and a regular Amazon EC2 instance.
Tell me more about this Ruby framework?
Jets is one of a kind. Despite the fact that there are other serverless frameworks tailored for certain languages, Jets is the most functional. Now he has more than 2500 commits in the master. The framework uses a lot of familiar conventions for a Ruby developer, it’s such a “Ruby on Rails on Serverless”. But this has its drawbacks. Since with a serverless computing model you pay for the execution time of the code, the initialization and loading of a large number of heavy dependencies is expensive in the literal sense of the word. Disclosure of this topic will also be given time in my report.
What platforms are most common for serverless now, what are their differences, which one is better to choose? As I understand it, you are now stomping for Amazon Web Services, since most of the time you talk about it.
You ask why I often use the word “lambda” in our conversation? I think the story is like with Karcher or Xerox. There are brands by the name of which it is customary to call a whole niche of products. In 2014, Amazon was the first to provide public access to a serverless computing model - AWS Lambda. Everyone else: Microsoft with Azure Functions, Google with Cloud Function, IBM with IBM Cloud Functions, is still mentally in the role of catching up. Although the serverless market is booming, AWS's service prices are often higher than competitors. So new releases, such as Google Cloud Run , can turn the game overnight. If we conduct a more detailed analysis of platform comparisons, then I would recommend watching a video of Ruslan Serkin from DataArt from the DUMP 2019 conference .
What do you think, in what direction will serverless develop?
Oh, this is the most interesting part of my report! I can do without spoilers - come listen! Instead, I can talk about serveless and production. In April of this year, I was at the RubyConfBy conference in Minsk, at which the author of the same Jets spoke. At the afterparty, we discussed serverless development and why, if there is support from major industry players, we do not see the mass distribution of lambda functions. The advantages of the model are obvious, the ecosystem is transparent, but there is no widespread trust on the part of the IT community. As a result, we came to the conclusion that serverless is now a kind of shadow player and the situation is somewhat reminiscent of the one that was with Docker at one time. It has long been believed that Docker in production is suicide. Now we see that containerization is the main tool for software distribution. I think that in the future, serverless will do the same. More and more people will trust him.
Will serverless kill monoliths?
This question can be rephrased as "Will the microservice architecture kill monoliths?" Because serverless is an ideal microserver - it is small, it is stateless and has a minimal interface for communicating with the outside world. Just as microservices do not kill monoliths, so lambdas do not kill monoliths. All three architectures have a certain range of tasks to which they are ideally suited. And vice versa - there are tasks where, for example, serverless is impractical to use. Look for details in my report.
What to do with vendor lock? For example, you developed a lambda for Amazon, but decided to move to Google.
Migration between platforms is painful if you do not use some kind of framework, for example, serverless , which provides an abstract API over cloud providers and allows you to deploy the same function in both Amazon and Google. If you, roughly speaking, do everything with your hands, then yes, it will be a little painful.
What to do with common lambdas when using code? For example, some common components, some utilitarian functions, and so on.
There are still no best practices on this subject. And the question can again be reformulated in "How to fumble a common code between microservices?", Because the meaning is the same. There is an option when you hold the reused logic somewhere in shared, and in the function themselves connect it. This approach will work well, for example, with Go, where at the output you get one executable file. Another option is to get rid of component connectivity and allow duplication. Probably worth a try and see what works best. The only thing I can advise is not to try to make universal lambda functions. At some point, it might seem to you that one uber function would be the perfect solution to the problem of code duplication. But over time, you will realize that this is the road to nowhere. You will get a certain “monolithic version of serverless” with all the problems of the first and second architecture.
We will discuss in more detail after the report on RubyRussia!
Come and you, registration is still open, the conference will be held next Saturday, September 28th.
There will be not only reports, but also stands of the best companies:
Organizer - Evrone
General Partner - Toptal
Gold Partner - Gett
Silver Partners - Valarm , JetBrains , Bookmate, and Cashwagon
Bronze Partner - InSales
All Articles