Getting Started with Serverless Technologies | Vadym Kazulkin

89

---

Vadim Kozulkin discusses serverless technologies and AWS in the context of Java.

Vadym is the Head of Development at ip.labs GmbH, a FUJIFILM Group subsidiary based in Bonn, Germany. With over two decades of experience in the Java ecosystem, Vadym specializes in designing and implementing highly scalable and available applications, focusing strongly on Serverless and AWS Cloud technologies. He is also a co-organizer of the Java User Group Bonn meetup, an AWS Community Builder in the Serverless category, and a frequent speaker at various meetups and conferences.

Takeaways

• Serverless technology abstracts away infrastructure management, allowing developers to focus on business logic.
• AWS provides various offerings to support serverless, including AWS Lambda.
• Java is a good choice for serverless due to its strong community and open-source projects.
• Java faces challenges with cold starts in serverless environments.
• Serverless computing provides instant scaling, but there are limits and considerations for each service.
• Cost in serverless infrastructure depends on factors like API requests, Lambda invocations, and memory usage. Developers need to understand the cost and pricing of serverless services.
• Observability tools in the serverless space can be expensive.
• Comparing the total cost of ownership is important when considering serverless.
• Security in serverless is a shared responsibility.

Connect with Vadym

• Website: https://dev.to/vkazulkin 
• LinkedIn: https://www.linkedin.com/in/vadymkazulkin/ 

Connect with Vit

• Website: https://vitlyoshin.com/ 
• LinkedIn: https://www.linkedin.com/in/vit-lyoshin/ 
• X: https://twitter.com/vitlyoshin 
• Other: https://linktr.ee/vitlyoshin 

Timestamps

00:00 Intro

05:42 What is the Serverless Technology?

11:16 How Does AWS Support Serverless?

13:50 Java in Serverless

17:13 Benefits and Challenges of Using Java in Serverless

22:18 How Can Serverless Help with Scalability of Applications?

26:17 Performance Considerations in the Serverless

28:45 Understanding the Cost and Pricing of Serverless Services

38:24 The Total Cost of Ownership Considerations

42:40 Estimating the Cost of Serverless

44:18 Security in Serverless

48:25 Advice from Vadym Kazulkin

Transcript (Edited by Vit Lyoshin for better readability)

Vit Lyoshin (00:03.976)

Hello everyone, welcome to the Vit Lyoshin Podcast. Today’s guest is Vadym Kozulkin. He’s the head of development of ip.labs, and also an author, speaker, and a member of the AWS Community Builder group. He also co-organized a Java User Group in Bonn, Germany. Welcome, Vadym. Nice to have you here.

Vadym (00:31.259)

Thanks for having me, Vit. Yeah, looking forward to what we will be talking about.

Vit Lyoshin (00:38.888)

Yeah, sure. So, I invited you to talk about serverless technologies, AWS, and Java. But before we jump into the topics, can you please tell me a little bit about yourself and your journey, how you became a technology expert, and the work that you do now?

Vadym (01:05.915)

Yeah, thanks. Sure. You introduced quite well what I’m doing. I grew up in Ukraine in Kiev where I also studied. Then at the beginning of the century, I moved to Germany. I started more or less as a Java developer in the classical data center environment, building monolithic applications, as probably everybody did 20 years ago.

We had specific needs in our company, ip.labs. We are dealing with the software for designing and purchasing of photo products, like photo books, and calendars. So basically everywhere where you can print the photos, and this is of course a spiky business. You have campaigns during the year, but after the summer vacations or in the Christmas season, people are purchasing more and more.

And we kind of faced some scalability issues that required us, it was back seven to eight years to rethink how we operate our software, and then kind of started my journey to migrate the application to the cloud. It was maybe we’ll be talking about basically first of all lift and shift plus some things that just will help us with the scalability. But later we just more or less jumped into this journey of cloud native services or serverless services.

And, basically, we are trying to be as serverless as possible in our company. Not always possible, but at least that’s more or less the first strategy. And of course, Java kind of struggled and still struggling there. And so we also needed to embrace other programming languages to just fully utilize this potential of serverless like JavaScript, Node.js, and all these derivatives like TypeScript.

But for me, Java has always been a passion and I have this passion for AWS serverless and also Java and I research, try out ways how Java can be utilized within function as a service environment on AWS.

So this is basically kind of the situation. I now currently developing a bit less because I have more managerial role, but in order to stay technical and relevant and to be able to speak with people, I use this opportunity to develop still and write blogs and articles, and also to try out the concepts and not only hearing about something because you know the developers, they can see if somebody just understands what you are talking about or not. And that’s why it’s just, yeah, experience helps me but I need to try things also out by myself.

Yeah, that’s basically it.

Vit Lyoshin (04:05.96)

Okay, cool. That’s what they say, right? You need to walk your talk, so otherwise people think you’re just talking and you don’t really do anything. With your role, it may be hard.

All right. Can you explain what serverless technology is in very simple terms?

Vadym (04:35.131)

I think it’s useful to start with the whole evolution that also led to this, that serverless became popular. So basically, we always saw the race of abstractions dealing with the infrastructure and all those components. So there are so many layers like networking, storage, server virtualization, operating system, runtime, and only then comes our application on top of everything else.

And of course, the question is how much time do we deal with all those things besides your application, which is your core logic. And basically, the idea is that you would like to write the business logic, and everything else is probably not something that differentiates you. That’s why we saw that you need to manage everything in the private cloud.

But, with public cloud providers like AWS or Azure, I’m only expert in AWS. So we always saw this raise of abstraction. We had this infrastructure as a service where you just simply can get a new server API calls. So that the whole virtualization server storage networking is more or less hidden. We have then the race of abstraction with a platform as a service or containers, all that stuff that even operating service and utilization and everything else is abstracted away.

The idea behind the function as a service is that even if we get the server and networking and storage, then at least we need to install lots of tools or we need just to install our programming language. We need to install maybe a web application server and manage it. With function as a service, basically get this environment or at least building block for free, if we are talking about function as a service, we get the environment and we deploy our code and it can be executed.

The one special thing is that the one environment is only capable of executing one function in a time. Then the environment will be returned back. And in the case of Java, for example, or talking about AWS Lambda, which is function as a service offering for AWS, you will receive, a kind of managed Java version. And you simply deploy the code there and it will be executed.

But of course, it’s only weak explanation of what serverless is. It is only a function as a service. For me, the biggest power of serverless comes out, then you have different serverless offerings. This one function as a service is for executing business logic, but you also need other blocks like managing the API gateway, the other user request comes in, or you need the database. That’s also very complex stuff to manage the database, scale database. The whole scaling aspect is very, very crucial.

So for me, if I’m speaking about serverless, it’s important to have the ecosystem of these building blocks, like Lego blocks, and you can put them together without too much thinking about the infrastructure management or not thinking at all about scalability, think that it will be scaled instantly. You don’t need to think about some scheduling policy, which will be maybe very slow. Then you need more and then it’s not there. So this is more for me, it’s basically about building blocks.

There are also very interesting discussions about pay-pay value. Maybe we’ll be touching on this. Is it important to pay only if the service is there? And not to pay if it’s idle, like our business is more or less, we don’t have too many orders in the night, for example, so why should we pay for the infrastructure. But it’s a much more different topic.

But yeah, this is steadily rising of abstractions is what led to the kind of popularity of the serverless technology, but also the thing that Microsaurus architecture became popular and then dealing with infrastructure and the Microsaurus application is even more complicated. We have so many servers that need to be scale out. So this is nearly impossible. That’s why this popularity. But of course, there are lots of trade-offs. Yeah, it’s not that you get something for free. The complexity is shifted somewhere else. Yeah, maybe it will be one of the questions where we can talk.

But basically, the thing is that you can maybe more focus on developing the code and less on operational aspects.

Vit Lyoshin (09:27.528)

Okay, it’s like an invisible layer basically that takes care of a lot of infrastructure things for you, and you as a developer just need to focus on business logic basically, right? Writing the application code and using those blocks, as you said, takes care of underneath of an application, whatever is needed to support it, like skeleton or backbone or whatever we can say.

Okay. So how does AWS specifically support serverless? Are there any special, unique things that they help with? Why do you stick with AWS?

Vadym (10:19.227)

So, I personally think that all major cloud providers have offerings that are quite similar. They have different names. What is Lambda is kind of function as a service? It will be on Azure functions, and on Google functions. So basically many cloud providers offer basically the same. Managed the API gateway. Managed function as a service to deploy the function in a specific programming language like Java, or Python with some recent version.

Also, managed databases that can be relational databases. It can be also noSQL databases like in the case of AWS’s DynamoDB, their own offerings. You will always have some fully managed notification service, some fully managed queue. This is basically the things are where they are.

For us, it was basically the decision based on, we are based in Europe and AWS had their kind of data centers or the regions basically here. And so that’s why we had then, back then, seven-eight years, the feeling that we will be quite supported there. And so that was kind of that decision.

But basically all cloud providers are very close. There can be some unique things. Basically, Microsoft has unique things about Office and Microsoft offerings. And now probably something like managed OpenAI services because they heavily invested in OpenAI. So like conversational programming. I expect the things coming from there. But also AWS has now called Whisper.

Vit Lyoshin (12:18.152)

I see. So it was just a convenience for you. Amazon was there first and they had good support and infrastructure in Europe. That makes sense. Well, that’s how you win markets, right? You jump in first.

Let’s talk about the choice of Java for serverless. And why would somebody choose Java?

Vadym (12:44.219)

This is probably a very difficult question. If you have nothing and you are thinking about how to select a programming language. Basically, if you start the company, it’s a different story. I see a lot of advantages to have some technology that supports back and then front end at the same time, like Node.js and all that stuff.

But of course, sometimes you have your code already, and you have your expertise in the company. If you are the company that writes the business logic in Java, you have a Spring framework for full-fledged web development. And now your challenge is how to get into the cloud. And you would like to reuse as much as possible or try to think about reusing the code. Then, of course, you would like, you will prefer to stay with Java.

This is basically how I think it’s really cool community, a lot of really powerful open-source projects out there. Probably I have too much in that community and I don’t see something similar with other programming languages. There are always some open-source frameworks, but there is plenty of choice in the Java space. And of course, I think that the biggest investment that the company makes is in knowledge.

Yeah, and if you already have your Java developers and the offerings are there, then why do you need to reskill? You need to upskill people in the cloud technology and then now throwing away the programming language can be quite expensive. So this is kind of my thoughts. But of course, if you just probably start a small company, then I could imagine that you will stick to something like JavaScript, Node.js, and all that stuff.

Vit Lyoshin (14:26.056)

I see. Okay, so just in your case has happened that you already had experts in Java and also built your older version in Java, and just like you said you’re just lifting and shifting and it was easier to stick with it but otherwise people could use something else.

Vadym (14:58.683)

Yeah, that’s it. But as we started to explore serverless, that was quite different because we faced some challenges with adopting Java on Lambda-like function as a service. So that was the situation that we really needed another programming language back then, five to six years ago. We were asked to write a monolithic application for lifting and shifting it, we stayed with Java. We still have plenty of Java code. But back then it was, at least for the public-facing application, Java had its unique challenges with AWS Lambda. So we needed also to look for other solutions. But now after two or three years, there are offerings that will support. So the companies who are now thinking about the migration, they are, I would say, in a better place to stay with Java completely.

Vit Lyoshin (15:57.384)

Okay, so let’s talk about then what would be the advantages of using Java for serverless or benefits or maybe some challenges too from the other side.

Vadym (16:13.083)

So the benefits, I basically explained them. This is a community with a lot of open-source projects. So you’re basically using all these frameworks, they lead just to increasing the developer productivity. 

But of course, especially with the serverless, there are these unique challenges that basically you, with a function as a service, you have a short-lived environment. So the function is executed and then comes back, the environment is then kind of returned for the new function. But it’s quite expensive in case to create this environment. Yeah, because this is the environment you need some service that more or less starts the environment, then the Java virtual machine needs to be started, then the code needs to be downloaded and deployed.

This is what is called a cold start in serverless applications. Not specific to Java, but Java is designed as a language for more long-lived applications like the application living in the in the web application. So it takes maybe several seconds to start, but then the application leaves maybe for weeks. Yes, we are ready to pay. But with the short-lived functions to pay the price of three to five seconds, it leads that there is kind of delay in the response in case the new environment is created. That’s the important thing.

If there are enough environments to solve your requests, you don’t have the problem. But in case you deploy, for example, the new function, then the environment needs to be created for this. It’s a new code. It needs to be downloaded and executed. Another situation, is if you have, for example, five requirements, but the sixth request is now coming, then one environment is missing. It needs to be created by the cloud provider.

All this is this cold start thing especially with Java as a programming language, but the same will be with C# and other languages. It’s quite significant. So just one of the topics that I investigated and at least as there have not been any solutions to that, this cold start, which may happen in 1% of the cases plus-minus, is just three to five seconds which adds to the execution of the function of the business logic itself.

This is something where there are studies that if the user waits for the response for more than one or two seconds, then the user may drop. Yeah, and this is this cold start problem, especially with Java and so on. It led to the situation, especially if it’s a public-facing application that it led to the problem. If you have some kind of asynchronous processing, it just doesn’t hit you. Then In 1% of the cases, you will pay several seconds for the cold start. It’s not a problem. But for the public-facing applications, and there are many, if you need to register yourself or to log in, this is synchronous public. This is a synchronous invocation. You cannot process without being sure that the user was successfully logged in and has sufficient rights, and all that stuff. The same, maybe, is for ordering, at least partially.

So this is where Java at least struggled from the beginning. It’s one of the reasons why people sometimes abandon Java and even more if they use frameworks like Spring in their initial form because they use dependency injection annotation processes or things happening during the start time of the application which then increases the cold start. So it was kind of the situation that all the paradigms, how we developed applications, like for long-living applications, all this framework, they were not sufficient in the serverless world.

You need to turn this upside down. You need very quick start. All this caching behavior, all that stuff, all this garbage collection, all these things that are very natural and normal in the long-living environment but it costs your processor time. It costs all the stuff for the short-lived living Lambda function. It was kind of not beneficial at all. So that’s why kind of a different approach was needed, how to deal with all that stuff. Currently, there are these approaches and that makes me optimistic that Java will now be even more popular in this oralist world.

Vit Lyoshin (21:00.392)

I see. Okay, that’s great. So you mentioned a little bit about the need for scalability for your application, and that’s kind of one of the reasons you went to serverless. How does serverless computing help with the scalability of applications?

Vadym (21:20.731)

This is one of the properties of the serverless that is instant scaling. So that will be scaled automatically. The API gateway scales for you when there are many requests per seconds available. The same is true with the function as a service. You can scale up to X environments in parallel instantly. The same is true for databases, queues, and so on. But of course, nothing is kind of infinite. You cannot scale for free.

Also, the cloud provider needs to plan the capacity and all this stuff. That’s why it’s very important. So for every service, it’s not only AWS, but every service in each cloud provider has its limits. They call it, AWS calls it quarters. So you need to understand how in the case of its Lambda functions, the source, how many instant environments you can have?

For example, the default value is in our region in Frankfurt, 1000 per account per region. So basically instantly you can only have 1000 functions executing in parallel and you need to see, can you increase this limit? This limit is increaseable, but there are limits that are not increaseable. For example, you can start right away from 1000 functions, then you can scale up to 10,000 for example, per account, but with certain steps per seconds.

And sometimes you can increase, sometimes you can’t increase. So you need it just before you use some service, you need to go to the quarters or documentation where this quarters are listed just to understand the scaling behavior. And think of, is it enough for my use case or not? And then of course, is the scaling behavior adjustable? Then you can send the request to AWS in that case, describe your use case and maybe they will adjust it for you.

But it’s kind of, I think it’s a big misconception of the cloud itself. It just doesn’t matter serverless or not that everything scales infinitely, but it’s not. Otherwise, it’s simply a huge burden to the cloud provider. So they need to plan the capacity just to build the right size of the data center or data centers.

Everything has its limits and it’s important just to think a bit in advance. Probably if you start a new application, you won’t have millions of users. But you need to check where you are, how the services are scaling. Sometimes you have alternatives that are better scalable, but they are more expensive. You don’t want to start with them.

But basically this, at least as long as you understand that, and this is one of the, I initially spoke about that the idea behind serverless is to more focus on the business logic. Nevertheless, it shifts this complexity that developers need to think about scalability properties of all these services anyway. So it’s not that you just do something and it will magically work for all scenarios. No. The good engineering knowledge is still required in thinking, architectural thinking, how just maybe to turn something from synchronous to asynchronous processing with a queue in between, something like this. So this still remains. Yeah, this complexity still remains. So the scalability is there. But you need to understand how scalable is each service that you use.

Vit Lyoshin (24:59.112)

Yeah, okay, I see. So when I think about scalability, it’s more about volume, right? But then there’s also a performance at the individual level of function, like you’re saying. Are there any considerations for increasing the performance of those functions, if you will? Just maybe from your experience. I know there may be some, you know, a lot of cases how you can do it, but maybe from your case.

Vadym (25:36.443)

That’s a really difficult question, just thinking about how to answer that. Because the functions themselves are kind of independent, but of course, you can use the common layer like the database and all that stuff anyway. So basically, you need to think about what you can cache, and what you can’t cache, so there are also caching services in between. So all that stuff that’s, I think, relevant in a normal world where you don’t do serverless is also relevant here.

You can cache on different levels. And you can cache on API gateway level, just then the request is coming in case you are requesting something statical and nothing is changing. You can kind of cache it on the CDN level or something like that. And, can cache on the function level. You can cache the results from the database queries in the function itself, just not asking the database if you are quite sure that this can be at least cached for a certain period of time, and then invalidate the cache.

So this is basically the normal engineering best practices are also valid here. But of course you need to think if you, for example, take the function, you resolve the function of a certain amount of memory. So you need to think just, okay, too much caching can also consume memory. But this is the same as also in the server environment. You just cannot cache endless.

Vit Lyoshin (27:17.64)

So the same consideration as for normal application or whatever, old-day application or whatever it’s called, right? 

Let’s talk about the cost. What is the impact of running serverless infrastructure on the cost of the application?

Vadym (27:45.531)

So basically, of course, you need to understand the quotas or limitations of all services, you need to understand the pricing model of all services. This is something like API Gateway will charge you probably per request. You need to understand how much one request costs. And there is of course some package deals starting from 1 million requests, it can be cheaper. The same is also on the database side and also on the function as a service site where you basically, in case of Lambda, you are paying for number of Lambda invocations.

That’s one factor and another factor is a gigabyte per second. So memory execution. If you have half of the gigabytes that you pay the half of this. So this is basically the trade off. So maybe I can precise, you asked about the performance. There is one thing that is different.

For example, in case of functions as service Lambda, the only one parameter that you select is the memory. You don’t select the CPU cycle. You will get it proportional. And this is kind of cost performance factor that comes together. You need to figure out what will happen if I will double, for example, the memory. If I will get function executed in the half of the time, then I pay the same, but the response returns quickly.

There are tools that you can test especially for function as a service, what’s the best price performance trade-off. How much memory I should give and how quickly I will return response. But basically these are both factors of the price. In this case for Lambda. Then you need to run multiple tests to figure out what’s the best trade-off.

But basically, of course, especially with the serverless technologies, there is a feeling of risk that you don’t control your pricing. Because the more requests, the more you will pay. You can, of course, apply alarms that you will be alarmed in case that the cost will go up unexpectedly. And of course, you can have DOS attack, and then all services will then process more requests, and the price can become unbounded.

And I think many are not very comfortable with that situation. You have a feeling it’s out of your control. And this is especially true. And I also see that serverless at scale can become expensive. If you are in the startup having not too many users, you will probably don’t see much in the bill.

Our first application, serverless application to create products, photo products, manage photo products, it cost us several dollars per month. You don’t even notice because there are not too many users creating them. That’s not real users that are basically support users or our partners, but not the real traffic.

This is something where I think you need to understand the cost. So developers also need to understand the cost. They need to understand the pricing of these services and the scalability of the services. It’s quite interesting how many things the developer would need to understand with serverless, because you don’t have any system administrators there. You have team developing, and the whole team need to understand and deal with all that concepts.

But the most expensive thing from my experience is the observability tools, monitoring, observability tools in the serverless space. They are really quite expensive. Sometimes even the observability kind of tracing that you can deal with errors and see because in the serverless world you have so many teeny pieces, one service calling the others and in case you have a problem you would like to have the whole trace and understand where it is. But these services, are really, really, really expensive.

Sometimes you pay more for observability as for the whole rest of the serverless services together. This is, I think, true for all microservices currently that this is very complex thing to trace this invocation between serverless. And then you need to think about maybe only analyzing, like pushing this metrics not for all requests, but for example, 10% of requests. But then you risk in case something is occasionally happens that exactly your request isn’t there. That’s also then the trade off. How much do you want to spend? How much risk would you like to take with that? Because this is sometimes at highest scale, it may become a problem.

And I see that the people are really asking cloud providers also AWS. Can you provide kind of enterprise level pricing for serverless, meaning on the high scale, maybe some price reduction, because it always starts really, really cheap, and then it becomes more and more expensive. And then it’s a big trade-off.

Also what’s important with serverless, you need to think what you are not doing. It’s not only infrastructure, it’s also upgrades and all the security things that comes with the upgrade, you patch all the security stuff. And of course, it’s immense value if you don’t spend time with that. The cloud provider or managed service provider is doing that for you, but it has its price in the end. So there are companies saying it’s too expensive. Then you ask, are you doing this, this, and this by yourself? And then you hear, yeah, we are not paying attention to security anyway. And then they don’t appreciate that somebody is taking care of you.

This is something that you need to understand the whole benefit of the staff. What does it mean to manage service? What’s the work to be done on your behalf? And then it sometimes may be relative. And then of course you will have the highest pricing, but you offload so many things that you need then to compare. It’s called total cost of ownership.

If I now have more time to do something else to produce value, maybe it’s worth paying the price to the cloud provider and having time on the developer’s shoulder to produce something new, quick and all that stuff. And this is maybe one of the things that I see in the benefits of serverless or at least with one star that you are capable to do within the team itself.

You don’t have some team of the system administrators that you need to ask to release and then they have their own priorities. You can deliver the software from ground up to the production within the team. And this, of course, increases speed or time to production.

There is a star because the complexity comes with the server application. They are heavily distributed systems. And this brings tone of technical complexity that developers need to deal with and they need to be skilled in design of distributed system. This is the skill that comes from the experience. You cannot start with it. You need to experience the things, small things are breaking and the rest of application is working.

This is something that we had to deal with because our first application, as we started migration, it was basically monolithic and then you don’t have these tiny pieces and it was easier to operate, at least we thought it was. But this is kind of this trade-off price, performance, understanding and all that stuff. But from my personal experience, I see that the serverless or at least thinking about these aspects made engineers better engineers because that was our biggest problem.

The data centers, developers didn’t understand operations at all. There were some servers, some storage, and they had unlimited capabilities, as we thought, because we didn’t know these capabilities. We simply did something, it should run, but it wasn’t in some situation, it didn’t run. And now with that, we need to pay attention because we know the things will go wrong and how to deal with that. It’s just another thing you need to upskill people. But generally, I personally see that the developers are quite happy to deal with that things. Because they’re constantly learning, and this is one of the motivations for them.

Vit Lyoshin (37:09.672)

In contrast, when you don’t have serverless, you have to deal with cost for data center or your own server somewhere, right? You also probably have to hire people to maintain all the systems, upgrades and licenses and all that stuff. So if you calculate all that cost and what you pay for serverless, at the end of the day, serverless may be the same or even less, maybe a little bit more, but you also get better performance, hopefully, or like you said, you free up some time from your team members to do some other stuff. So you really have to, as a manager of technologies or whatever, like CTO or CIO, whatever the role is, they really have to compare and contrast this and make the decision for the business.

And, there are also benefits, like you mentioned about scalability, for example, right? You can ramp up services really quick, really fast. If you have your own data center, you may be limited there.

I remember a long time ago, I started with the company. It was a small startup and we actually had to, I don’t think even cloud really existed back then, or maybe it existed, but wasn’t so popular. So we were building our own racks in data center. And we literally had like dozens of servers laying around on tables and our sysadmins were installing software, doing some configuration on each and it was taking like, you know, a few days for each server and then driving them on tracks to the data center and installing everything. That was quite a project.

I remember they were dealing with this. But now it’s like push a few buttons and you have a bunch of servers sitting in the cloud for you, ready for you to work. That’s cool.

Vadym (39:06.587)

Yeah, this is what you first mentioned, the total cost of ownership. You need to compare things. Serverless makes cost transparent. You see what each service costs you in the end and even what each function as a service, Lambda function costs you. And then you can think of the optimization. So cost optimization can become one of the tasks like performance optimization. If you see the potential of something is not efficient, you can prioritize it because it’s visible. This is one of really benefits.

And, what you are telling now, so what I observe and people observe with serverless, at least if you are just a bit familiar how to deploy, you need to write infrastructure as a code to deploy it. But basically, sometimes we had an idea what to try out. And yeah, literally one hour later, we deployed the code.

We don’t need to ask anybody for permission with serverless. Simply write code. We are skilled how to write this infrastructure as a code just to deploy it in an automated way. And we can simply test and validate the idea. Of course, you can do mostly the same also with managed containers. As long as you are not managing containers by yourself, the scaling behavior, you can do the things also they are, but you maybe have to take care how to build Docker image and all that stuff, CI/CD on that.

So we’re simply deploying only code. So at least for trying new things out and especially important for the startups or the companies working the startup way that you simply try to validate idea, not to think and overthink. That’s really cool.

I also see now a lot of enterprises dealing with serverless like Lego, and many companies doing even a post an L from Netherlands, the huge post company processing millions of parcels. They are going completely serverless because in this world of competition, the speed matters. And sometimes you will use speed and go to market. But you need to understand, think about costs. You need to make them visible and work on that.

CFOs and all the kind of people, they are not feeling comfortable if you cannot tell them how much the thing will cost. They will chase you. Anyway, it’s understandable. It’s their money. It’s the company’s money. You cannot say, yeah, I think, but I don’t know, $10 or $5 million. I don’t know. It’s not the answer. You need to approximate at least. But then they need to give you business requirements on how many users do they expect. Otherwise, you can’t answer the question. So this is kind of going in both directions.

Vit Lyoshin (41:56.184)

Yeah, like chicken and egg, right? They don’t give you business requirements. They don’t know themselves and they expect you to estimate the costs. That’s the challenge always between dev and business. Even estimating simple tasks, but estimating cost of serverless environment. It’s even more complicated. Yeah, that’s funny that you mentioned it. It’s actually the real challenge today.

Vadym (42:24.795)

Yeah, but you can start with something. I mean, you can say, OK, I can approximate for 100 users. And if they say, OK, for 100, it’s cheap, but for 2 million, it’s expensive. Then we can say, OK, if we have 2 million of users, then we have success. Then we will earn enough money to think about optimization. But now the speed matters. Let’s get this 100,000 users, and then we will talk.

Vit Lyoshin (42:53.48)

Yeah, exactly. You start small, you build up and then you earn more money and you can afford it and you pay for it. Okay, cool.

Let’s touch on security a little bit. You kind of mentioned it already, but how does AWS specifically or serverless in general ensure security or help manage security concerns for the applications?

Vadym (43:21.371)

So for me with serverless, so many layers are managed, then for all managed layer, the cloud provider, in that case AWS, is responsible also for the security. And that’s a cool thing because there are so many things in between.

But what remains is the security of the application itself. That’s the responsibility of the developers and will always be. This is nothing that somebody can help you with, have a lot of other tools just to check for static, dynamic vulnerabilities, package management, especially in the Java world, you have so many open source project as dependencies that you don’t control. People can release security vulnerability and you simply update the version and you have it. So you need this tool. So the application security remains on your shoulders and everything else, and I think it’s more than 90%, is on the cloud provider.

They ensure that the servers have the newest version of the operating system. And if there is some known vulnerability, it’s on behalf of them just to fix it and roll out the fix, even that you even don’t notice that. Yeah, the same is also true, for example, serverless with Java. We don’t even know what the version of the Java runtime is, but we don’t know the minor version. It’s now Java 21, but is that 21.03? We don’t even know.

But we need to be sure that in case some vulnerability will be reported in this Java, then Oracle will fix it. And then the cloud provider will run then the fixed version on behalf, so that I don’t need to take care. I can’t even change something, but I need to have trust that it will happen. And I have trust because I know that for AWS, that security is priority number one.

We also had very huge security finding two and a half years ago with log4j, and we saw the reaction of the community. Also AWS relied heavily on that version with security vulnerability and within two days, they rolled out the fix over the world. So this is something that I really appreciate. And on top of that, the cloud providers also released the tooling that help you even with application.

For example, in Lambda function, there is an AWS inspector. There are so many tools in the security, they constantly check the deployed Lambda functions if there are vulnerabilities. So even in the deployed version, we can check it on our side during the development, during the building phase, but they can help you also if it’s deployed, that they also look from this because otherwise the people just kind of checking for vulnerabilities, the hackers can discover it also from this side. Basically, it’s the shared model of the security, but I see huge benefit also offloading this complex stuff to the cloud provider.

Vit Lyoshin (46:49.992)

I see. Okay, that’s cool. I was kind of expecting that they would take care of most or many security things and monitoring stuff like that and maybe testing something. So yeah, that’s great.

Okay, coming to an end. What would be your advice to somebody who’s curious about this, interested in these technologies? How they can learn more, how they can stay updated on this, are there any resources they can go to and check more.

Vadym (47:26.075)

So basically we talked about the problems or challenges with Java and so on but we didn’t talk too much about the solutions, but maybe I can give you links to my blog posts or the series, the whole series I’m writing or was writing about how to solve that. There is Snap Start that helps you with the cold start of Java function. There is also GraalVM native image, which basically is for the ahead of time compilation. which helps you with that. So this is the one topic, just how to improve things for Java and serverless specifically.

Basically, if you would like to learn now, there are so many resources out there on YouTube. So plenty of things, but generally I can advise if you are in the AWS space, to attend AWS Community Days meetups. There are so many around your corner for sure, so many. There are also serverless days, at least several of them happening around the world. So if you just want to start with something, plenty of things, especially AWS, they have so much documentation. They have so many teams with so-called developer advocates who advocate for specific services. Yeah, you can reach out to them. They are on Twitter. Everywhere.

They can give you resources, recommendations about some specific service, and all that stuff if you can’t find that on your own. So today it’s plenty of information. I think the cloud is here since 15 years ago and I think since 5 or 10 years, it’s more or less become more like common knowledge. Now I see companies asking.

So it’s now more, I think many companies simply start now within the cloud because it’s easier. It’s not a unique thing as it was seven or eight years ago that there were some pioneers. Just like with the electricity. It’s just that it becomes generic. And this knowledge also becomes generic.

So I expect maybe in 5 to 10 years, there will be more engineers familiar with the cloud that they don’t even know and understand the problems of the private data centers. And we’ll look into the people who experienced that like, okay, you’re a poor guy, you had the time, but I don’t have this luggage of things that I will not be using anymore. But it’s always the pace of how things change is now so big that I think everybody in our industry is probably working differently every three to five years or needs to adjust.

My mom was also programming, but she programmed 10 years with the same programming language, basically the same. It’s now nearly impossible to have this kind of stability and probably nobody wants this kind of stability.

AI is coming, all that stuff is around somehow impacting us or the pace of change is now really incredible, which makes also the thing also exciting.

Vit Lyoshin (51:03.432)

Yeah, it does, for sure. Hopefully it will simplify life for developers as well. I know it’s coming to the product world and business world as well to optimize, to provide some tools and services to help people make decisions, to analyze things, or maybe not really analyze, but anyways. And for developers as well, there are co-pilots, there are automated testing tools. There are all sorts of analyzers or whatever. Yeah, so I hope it will become easier and easier and developers can really focus on the hard problems to solve versus just configurations and writing repeated things or whatever. 

All right. Thank you very much for your time today. I think it was great. I asked a lot of beginner’s questions, just because I’m clueless about this stuff, but now I have a better general understanding and will look more into this topic. This is interesting. Thank you very much for your time.

Vadym (52:10.651)

Yeah, it was a cool conversation.

Vit Lyoshin (52:16.328)

I hope we can talk more in the future. Thanks, Vadim.

Vadym (52:25.115)

Yeah, thanks.

Vit Lyoshin (52:26.536)

Alright, bye.