Loading summary
Transcript50 lines
- [00:00]
A
What if Java is too old for Serverless? Is the biggest myth holding teams back in 2025? Today, we are putting that idea to the test with someone who has seen Java succeed at a very high scale, especially with Lambda. I'm joined by Mark Sayles, former AWS engineer and internationally recognized expert on Java and all things Serverless. By the way, if you know me, you probably know that Java isn't necessarily on my list of favorite programming languages when it comes to Lambda especially. But if there is somebody who can judge my mind, that's definitely Mark. I have compiled a long list of questions so we'll cover all things Lambda and Java. And just to give you a spoiler, I'm very keen to hear when Java is the right call for Lambda and when it isn't. What are the trade offs that actually matter and what are the tools that move the needle, especially when it comes to latency and cost. And you know, we'll probably be talking a lot about Snapstart and provision, concurrency and things like that. I'm sure that Mark will also share some practical tips and those tips I'm sure are going to be valuable for both juniors and experts. So I hope you are going to enjoy this episode. My name is Tushano. This is another episode of AWS Bytes and today we are joined by Marc Sales. So Mark, thank you for joining us. And I just want to start by letting you in introduce yourself.
- [01:26]
B
Thank you very much. And it's great to be here. I've watched a lot of your episodes, they're all really cool. So it's great to be part of this podcast. So yeah, I'm Mark Sales. I worked at AWS for six and a half years and at that time I did a whole heap of different jobs in different industries, all to do with solutions architecture. And then the majority of my time was as a specialist solutions architect for Serverless. So really diving deep into serverless workloads with some of AWS's biggest customers and that was just a fantastic experience. Really did give me a lot of insight into how big companies are using Serverless, some of the scale that Lambda can handle, which is just fantastic. And then, yeah, where I found my niche, which was helping customers who are using Java that just don't have a lot of material to kind of learn from. So I spent a lot of time looking at what their problems were and then trying to work with the service teams to fix them. And that was something that I really enjoyed and something I hadn't really done before in my developer kind of LED career. So, yeah, definitely, you know, looking behind the scenes into the product side of the business and seeing how it works.
- [02:45]
A
That's. That's a great intro. Thank you for sharing that. I remember in one of our previous conversations you mentioned you had been working on something like 100 projects or close to that with AWS, and I assume many of them involving Java. So I'm sure you heard a lot that criticism of Java being around for a long time. It's kind of an outdated language. So I guess my question will be why? Well, I'm sure that's not true, that there's. There are ways to kind of dismantle that myth. But in general, why should we bet on Java in 2025?
- [03:20]
B
I really don't think we should be coming at it in that direction. When I come to a new project or come to an existing project that I'm looking at again, I don't start with saying which language should I use. If I'm working as a team lead or if I've joined a team, or if I'm an architect working with a team. I look at the skills of that team and the application that we're working with and the wider context, and that's how I'm choosing every part of the. Of the stack. You know, do we have any skills in no SQL? If we don't have any skills in no SQL, we probably won't be using DynamoDB. If we haven't got any go skills, we're probably not gonna be writing the code in Google. So I'm thinking much more in that direction. So if I'm speaking with a large bank and they are wanting to adopt serverless, I am definitely going to help them to adopt serverless, because serverless is really going to help that business to actually gain some momentum and cut some of the overhead that they traditionally spent a long time dealing with. And Java is one of those things where it got a bad reputation and it hasn't been able to shrug that bad reputation off. And I talk about it similar to the way that lambda used to have a bad reputation with vpc. If you've been using lambda for long enough, you'll remember if you had a VPC attached lambda function, a cold start would take at least 30 seconds. But now no one even considers that because it's kind of been fixed. And the same is true of Java. Um, you know, there's a lot of tools and techniques that you can use. Some of them easy, some of them hard, some of them, you know, you don't need to invest much time into. You know, it's very easy to get a cold start less than one second. But can you get the same sort of cold start as a rust function with 128 megabytes of memory? No, but that's, that's just the different behaviors of the language. And you know, teams have been using Java for a long time. They're very familiar with Java, they have all of their tools libraries written in Java. So I'm much more interested in helping them to adopt serverless rather than them having to rip up everything that they know and start from scratch.
- [05:50]
A
Yeah. And to be fair, one of the things that I really like about Lambda and FAAS in general is that you could use a language for most of the code base and then in those very small pieces of the entire software where you need, need, I don't know, some different characteristic, it might be performance, it might be something else. You can pick another language that maybe it's more suitable for that particular characteristic.
- [06:12]
B
Absolutely. This is, this is the very nature of distributed systems and being able to have something that's composable. But also, you know, Java does have the capabilities to now compile to native bytecode. So this is a technology that Oracle's developed called graalvm Native Image. So I have seen that very pattern. I was working with a large bank and they produced a lambda authorizer for API gateway that had to be low latency. So they spent the time and the effort that is required to use that technology to make sure that it was cold, starting in 100, 200 milliseconds with 128 megabytes of memory. But that use case was very specific. It didn't have a lot of dependencies. There was no, you know, external network calls. It was able to be, you know, done in such a way that it really excelled and that the time and effort spent doing that was worthwhile.
- [07:10]
A
Yeah, absolutely. And with that in mind, when you would advise teams to use Java on Lambda and when maybe you will say, actually for this particular use case, you're better off with something else.
- [07:23]
B
So in that scenario, the first question I'm asking is what sort of traffic profile are you seeing? What is the kind of ceiling on cold starts that you need? Because that's probably the biggest blocker to get something below a 1 second cold start with any meaningful application. So when I say that, I guess I mean does it need to get parameters from Parameter store or Secrets Manager? Does it need to connect to a database? Does it need to connect to any other AWS services, some sort of meaningful application like a microservice. It's unlikely that you're going to get a 500 millisecond cold start. So if you need something below that number, you either have to put in additional effort to go to ahead of time compilation or use a compiled programming language like Go or Rust or C or C. But after that I think the majority of people are building microservices and the world is built on Java microservices. I mean the amount of spring framework microservices in the world is just phenomenal. And those are the ones that I see running on EC2 servers. High availability, 10 different environments and they're just stacking up the costs every month, having to be maintained every month. And those are really the kind of targets that I want to help people migrate to serverless and have a much better life.
- [09:02]
A
Yeah, that makes a lot of sense. I think a slightly related question, what do you think is the unique selling proposition of Java when it comes to serverless and Lambda? Like what's unique about the language itself that maybe other languages don't have?
- [09:19]
B
I don't know if it's necessarily to do with serverless, but Java's unique position is that it is the language of integration. It probably, I imagine if there was any, any sort of data behind this, I'm not sure but I think it has probably the richest, longest history, the most developed SDKs for a variety of different tools. And I mean Lambda Snapstart is a really cool technology being able to have that additional phase that you can affect your lambda functions at deployment time. So you can do a lot of preparation before your application is ever invoked by a customer. Now obviously this is now usable by python.net. i'm sure it'll be rolled out to the other languages as well. But yeah, I mean Java is really the language of integration and that's where I see this superpower.
- [10:14]
A
So I will maybe rephrase that as being more kind of the adoption patterns rather than the language itself having specific unique characteristics. Maybe what we could focus on is giving people some examples of, I don't know, use cases where you have seen, where you will say proudly, yes, I think Java was the right choice.
- [10:37]
B
I mean I've just seen countless microservices where it has run on EC2 is a microservice that is an office based application and it runs from 9 till 5. I mean these are the, the bread and butter applications that have been written by, by large enterprises for, for 2025 years and it's that sort of maintainability that Java is famous for. There's no breaking changes, very easy to upgrade. And I don't see serverless being a, something that, you know, is, has to be only small companies, agile companies. You know, I think one of the real benefits is actually in, in enterprises where they are having to spend a lot of time doing the high availability, fault tolerant architectures that they're just churning out EC2s. And that's where I see the real, the real benefit is by, you know, bringing that vast volume of applications that has been built over the last 25 years and helping people to gain the benefits of serverless.
- [11:44]
A
Yeah, I would add to that that even the ability to offload a lot of the kind of security and compliance aspect just because you give that to the provider, in this case AWS with the serverless runtime, I think it will be a huge benefit to this kind of companies because they have entire departments that generally look after those things and reducing the work for those, I think will be extremely beneficial for those businesses.
- [12:08]
B
Yeah. So you know, for me that really came to light when I was working at AWS during the log four shell vulnerability. So this was when Java's largest logging framework had a critical CVE which actually scored 10 out of 10 for ability to be enacted and the effect that it could have. And the Lambda team were actually able to work with the AWS Kreto team, which is the team that distribute Amazon's version of the Java runtime. And they were able to mitigate that attack by checking whenever a vulnerable class was loaded into the runtime and strip away the vulnerable code. And you know, for me that was just an amazing capability that that team was able to bring to protect customers, you know, within days of it's being released. And being part of that team while that was happening was a real highlight of my, of my career. You know, the fact that we saved so many customers from being attacked was super cool.
- [13:24]
A
Yeah. That probably goes to show how powerful it is to be able to offload some of that responsibility to a team like the one in AWS that is extremely experienced and they have people on call. So I think it will be very, very unlikely for even a big company to be able to have a team dedicated to this kind of activities.
- [13:43]
B
Yeah.
- [13:44]
A
With that level of efficiency, I'd say.
- [13:47]
B
And just the fact that it would be easy to, you know, even if it hadn't been so transparent, you know, if it would just been an SDK change to bump to a new version of the runt time. It's just so much easier to do than having to, you know, patch run times and servers and different OSes. I mean, it was very similar when Spectre and HARP Lead came out. I was actually a customer of AWS when that happened and we were using Lambda at the time, but all of the other teams on the floor were using EC2 and they were not only having to patch the machines, but there was also a very, very real risk at that time that the, the patches would degrade performance on machines. So not only were they having to patch, but they were also having to benchmark to see what capacity they needed to add. Whereas the team that I was leading on Lambda, you know, very smugly, we didn't have to make any changes. That patch was already applied to Amazon Linux before the announcements was made. So again, you know, these are very, very attractive features to companies that use Java, which are the enterprise companies that have to be compliant.
- [15:05]
A
Absolutely, I totally agree on that. Maybe we can revert a little bit back to some of the points we touched before because I think I really like the way you tend to approach new projects and work with different teams, which is what we have been doing for most time in aws. So I will probably ask you a bit more about like, what is your, let's say, strategy, for lack of better words, like what kind of common problems and fears you have to work with and then how do you effectively end up with the entire team having a great experience and the project being successful?
- [15:43]
B
Yeah, I guess typically I get brought in when teams are having a bad time and they'll probably have spoken to their AWS account team, maybe they have some experience, but don't have a lot of experience. And basically that kind of request kind of funnels up to somebody in AWS who can handle those sort of requests. And I was kind of the topmost person in AWS handling a lot of Java Lambda questions. So, you know, typically you join a call and people, you know, really enthused about serverless and really wanting to make a really good go of it, but just needing some help on how to think about Java ephemeral environments, how to use Lambda efficiently. So, you know, very quickly you can look at their code and say, all right, okay, you've kind of understood some of it, but maybe not all of it. So, you know, this is an environment that needs to focus on starting up quickly. So do you need, you know, all of these external network calls to load in these various things? Can you change your architecture slightly to be More serverless, friendly, you know, can you get away with, you know, changing this library that doesn't really help you to this other library that's a lot smaller, a lot leaner and probably includes all of the features that you actually need. You know, just, just giving slight advice into, into cold starts because that's typically where everyone kind of panics. The, the developers try something new. They're not entirely familiar with the technology, they have a bad experience because they're uploading code, pressing test on the console, getting a cold start, changing the code, uploading and getting a cold start. And they just think that, that lambda is really slow. So, you know, typically I talk to them about their use case, what's your traffic profile, what's your existing application latency? And you're trying to understand what they're trying to achieve and then working backwards from that. And often when companies just run a benchmark or some sort of load test, they'll see that actually the performance is completely different to what they've seen in, in their development cycles. Because their development cycles are always the worst case scenario when they do some sort of, you know, 9 till 5 traffic pattern, then suddenly the P99 is like 50 milliseconds instead of, you know, 2 seconds, which is what they see during development. And then everyone kind of calms down and you know, then it just becomes an optimization conversation more than a, you know, a world ending. How is this so slow conversation?
- [18:37]
A
Yeah, that actually reminds me of something that I've seen quite a lot myself, which is new people approaching lambda not realizing the difference between the INIT phase and the handler phase and they just ignore the init phase entirely and they put all the initialization logic in the handler and then they don't realize that they are just accumulating all that extra time for every single request when it could be offloaded at the creation of the lambda instance. I'm sure I've seen that a million times as well, but I think there are lots of like tactical tips like that, that when you have the experience, you can help teams be much more effective just by spotting those things and helping them to understand them and fix them.
- [19:19]
B
Yeah, and maybe that's a UX problem with lambda, you know. You know, it's very clear that the handler is called on a customer request, but you know, for different languages it actually handles the INIT phase differently. And you know, when you think of technology, all the differences between technology, between something like an on demand lambda function and a provision concurrency lambda function and the expectations and latency but it's not particularly clear from a, from a UX or a developer experience point of view, like how you should be programming those differently for different latency characteristics. So it's easy for us to kind of understand these things after, you know, working with the technology for years and years. But I can definitely understand newcomers having a hard time with it. So very sympathetic.
- [20:09]
A
And just to get a little bit more practical, is there, I will say a specific list of tips that you can give people like, I don't know, I'm thinking stuff like which version of Java should they use and should I always use Snapstart and how to configure it correctly and maybe, I don't know, are there specific JSON JVM flags that you always would enable or maybe, I don't know, consider when to enable and which values to use.
- [20:36]
B
Yeah, mostly you're not really tuning the, the JVM anymore. That was definitely something of older versions, but since, you know, the, the newer versions, that's not really a thing. So specifically with, with lambda runtimes pre Java 17, there was a JVM flag that AWS recommended. There's a whole heap of blog articles about a feature flag called tiered compilation. But that was added by default in JVM versions after Java 17. So Java 17, Java 21 and probably the future Java 25 will all have this flag enabled by default. So at the moment, you know, there's probably no JVM flags that I'd recommend at the moment. Adding it would have to be a very specific use case where you would go into something in depth. But you know, normal microservice architectures, you know, there's no real additional JVM flags. And that's a good thing because we've worked or, you know, I worked with the Lambda team to make sure that these were enabled by default. The sort of things that I like to tell people straight away is, you know, there's a logging library called log4j and this is a logging library that's been around forever. Very, very fantastic piece of software, but now is one and a half megabytes in size. And this I think is just not a tailored solution that you probably want to be using in Lambda. So, you know, now I recommend another, another library called Pena. So if you search for, you know, Java logging library Penner, you'll find this fantastic open source library which is 50 kilobytes. It does structured JSON logging, has zero external dependencies, super fast, very low garbage collection overhead. And you know, these are the sort of things that we need to be, you know, looking out for in this community and helping people to understand that, you know, you've used to have no real consideration about startup time with application servers. It didn't really matter whether your application started up fast or slow because your application servers stayed up for a week. But now we do need to. So what are the best of breed application dependencies to help you do these things that you need to do quickly and effectively. So Pena is a drop in replacement for the most common logging abstraction in Java, which is called SLF4J. And it's a drop in replacement. So again, it's not even like you have to refactor your code. You can drop in the dependency and your application code will continue to log or log in a structured logging way and you just carry on with your life. But you've gone from a one and a half megabyte dependency to 50 kilobytes. And you know, those are the sort of considerations that you need to be looking at through your application code to say, am I really focusing on ephemeral environments? You know, is there a better way of doing this? And that is a balancing act because, you know, maybe you don't even need the super, super efficient cold starts because you have an application profile that doesn't really cause you to have a lot of cold starts. So it's all weighing up, you know, how much time you want to invest. And you know, technical people always like geeking out on optimization, so it's hard to put the tools down and get on with features.
- [24:27]
A
That's absolutely fair. Yeah, I'm definitely one of my mistakes. I recognize it's always focusing a bit too much on performance, which sometimes makes sense, but not always. Most of the time, as you said, it's more important to ship features and deliver value to the business. And then whenever performance becomes a bottleneck, you can work on it and improve it. So definitely. Yeah, I agree with that point. What about we mentioned it already Snapstart a few times. We mentioned provision concurrency. Are those things that you would always use by default or is there like a point where it makes sense to invest into those, those features, enabling them correctly and learn how to use them Correct?
- [25:11]
B
I mean, I remember distinctly a conversation with a pretty major bank. There was probably 10 people on the call and we were discussing provision concurrency and the cost of provision concurrency. I think they had a concurrency of 2 at the time. And I was just man, the time we've spent discussing this problem and the salaries of everyone in the room. I mean why are we, why are we even, you know, talking about 20, $30 a month? So provision concurrency is definitely a way of, you know, mitigating a lot of the optimizations, but there is a cost involved. I guess what people sometimes forget though is that provision concurrency can actually be cheaper than on demand. So if you are, if you do have a lambda function that has significant traffic, then you probably should be using provision concurrency because every invoke with provision concurrency is cheaper than on demand. So if you can use provision concurrency at the base utilization, you will actually save money. But it does get a bit of a bad rap as a way of kind of optimizing in exchange for cash. So I'm not against using provision concurrency, but again it's understanding how it works and a lot of the optimizations that you would do to help provision concurrency be even better help you when you use Snapstart. And I guess the time of recording Snapstart for Java is I think still free, whereas it is free for the other languages. So you know, would I use Snapstart? Yeah, absolutely. It's gonna, even just turning it on without doing any further optimizations. It is going to save you latency using Java. So I would definitely use, does increase the deployment time because now you are using, you have to use lambda versions and each time you deploy a new version you have to go through a life cycle where a lambda function is snapshotted. So when you deploy that new version, that code is put onto a separate fleet of execution environments. It's initialized, you do any work that you need to do. A snapshot is taken, it's encrypted, it's put into storage. That whole process takes time. So your deployments do take longer. So you might not necessarily have Snapstart enabled. For all of your development environments where you're wanting to do high change cycle, you probably have it on all of your pre production environments where you want to have, you know, the, the best performance and performance that's going to be applicable or similar to production.
- [28:10]
A
Yeah, that makes a lot of sense. Let's stay a little bit longer on this kind of topic that covers all things optimization. I would say like cold starts and performance, maybe cost as well. Do you prefer a specific like combination of runtime and by runtime I mean the standard supported Java runtimes versus maybe something like, I don't know, a custom image using Graalvm or something like that. And at the same time you already mentioned some libraries like the login library. But in terms of framework, like you mentioned, Spring is like almost ubiquitous in Java. But I know that there has been a lot of advancement with like, newer frameworks that tend to be, I guess, more optimized for serverless and microservices. So I'd say I'm going to phrase the question as like, what's your favorite setup when it comes to Java? If you could pick with like total freedom.
- [29:05]
B
Yeah. So for me, whether I'm building something for myself or whether I'm advising other people, I always start by saying, do you need a framework? Because if you don't need a framework, then you shouldn't use a framework. So especially for event driven architectures, it's probably unlikely that you need a framework unless you have an application that really benefits from dependency injection or you have a existing set of libraries where you are used to using dependency injection and you want to maintain similarity across the estate, which I can understand. People get annoyed when certain teams do things in a special, different way. I think people should have the flexibility to use the best approaches, but I can understand it from both sides. So if you're doing event driven architectures where you're receiving an S3 object or whether you're processing a message from a queue, I think you should definitely be challenging yourself to not use a framework. If you're used to using Spring, start with no framework and see how far you get. And then if you have to take on an application framework, then that's fine. Spring is fantastic. Quarkus and Micronaut are probably the two next most popular frameworks. And the big thing about those two frameworks is they were both kind of born at the same time in reaction to Spring, and they've both been developed in a way that reduces the amount of reflection that is used in the application framework, which is one of the features of Java that tends to lead to more latency. At the same time, Oracle was developing GraalVM Native Image, and the two things basically accidentally became very well aligned. The GraalVM Native Images doesn't really like you using Reflection, and these frameworks didn't use Reflection. So it was very easy to have an application built with Quarkus or Micronaut that was very easy to become an ahead of time compiled binary. Whereas if you were using other frameworks previously, you would have to hint to the compiler that, you know, this is a resource that's dynamically loaded, which became, you know, an awkward, awkward process. But since Spring has done a lot of work to, you know, really make sure that ahead of time Compilation is supported well in Spring, so with Spring Boot 3 and Spring Framework 7, it's really well supported as well. So really you're looking at the features of these application frameworks as a whole and picking which suits best for you and your project. All of them are very capable and all of them have a lot of support. So Spring is now owned by Broadcom. After the acquisition, you know there's a large open source team working on Spring. Oracle have been adding more developers to Micronaut and building out. The team at Micronaut and then Red Hat have been investing heavily in Quarkus for a number of years. So you've got three really good options that are well invested and will definitely stand the test of time.
- [32:33]
A
That's pretty cool. Yeah. And I think I've only used Spring Boot myself, so I cannot speak for the other frameworks, but I only heard very good things. So I'm curious, maybe eventually I will try them and see how they play with Lambda.
- [32:47]
B
Yeah. So Micronaut has been developed from a lot of people who spent a lot of time building Spring. So they looked at Spring, taken ideas and inspirations from it and built kind of their version of an improved application framework. And then the Quarkus team have built something from scratch. But it's also very standard standards based, whereas Spring and Microsoft, whereas Spring and Micronaut don't really follow the same sort of Java enterprise standards. Quarkus is a standard based application, so you can imagine migrating to Quarkus from previous older application frameworks easier. So those are kind of some considerations that you can make if you are potentially moving or migrating applications or wanting to move to a more serverless orientated framework.
- [33:44]
A
Great. Let's probably related topic. That sounds like a little bit of a change of subject. So what about testing and maybe developer experience in general? How do you generally go about testing your Lambda functions in Java?
- [34:01]
B
So I do a lot of testing locally, so I know there's probably kind of like two camps. You know, there's definitely people who love testing in the cloud and I love testing in the cloud. But I try and focus that on my for my end to end tests where I'm doing integration and unit tests, I favor doing that locally. So I'm a big fan of Local Stack and I think it supports multiple languages now, but a framework called Test Containers. And in Java it's very easy to spin up a postgres database from a Docker container as part of a unit test and integrate my code against that. And in the same way I can boot up an S3 bucket or well, actually an S3 service. And then I can create a bucket and add any items that I need to add to it. And I can do that with other AWS services. So if I want to queue in a lambda function, very easy for me to kind of write a integration test that I can integrate locally. Now obviously there's going to be stuff that I can't cover in those tests and that's where I move to the cloud for integration, for end to end tests. So things like capacity, security, permissions, those are the sort of things that I'm looking at an end to end point of view. But the rest of the application and the awkward integration stuff I'm kind of doing locally. So I have the best tools, I have my IDE of choice, I have my debugger, I can do stuff that I'm used to doing and have a lot of experience in the tools with. So that's my approach, that's what works for me.
- [35:50]
A
Yeah, actually I think I do the same, although mostly with different languages. But I generally try to push the local testing as far as I can just because maybe it's just out of habit. That's what I've been doing for the most part of my career and it's nice to have that fast reload and debugging experience. But yeah, I think at some point you have to start testing also in the cloud and you end up with kind of a mix of the two approaches for different kinds of tests. So I think that's. I will define it as a pretty standard approach. Yeah, it's sometimes a controversial topic where people will say, well with the cloud you only have to test in the cloud because that's the true reason. Real environment, right.
- [36:30]
B
Yeah, I think maybe we can agree that. I think mocking is on a decline because with distributed systems it's hard to understand what behavior the system should emit. So I think I'm using mocks less and less and you know, I probably can't remember the last time I used mocks in a test because I'm much more likely to favor integration tests with test containers and local stack. And I feel like that's just way more productive and way more useful from a testing perspective than having to work out what the behavior actually is and then, and then mock that behavior. So that would be my, my hot take. Mocking decline integration testing on the up.
- [37:21]
A
Yeah, which is I think something that I'm hearing from many people also with the inverse pyramid of testing model, which goes more or less in the same line yeah, and I find myself as well, maybe for simple cases, simple enough cases that I still see lots of value in mocking just to be sure that maybe when you have, I don't know, complex behavior in reaction to an external, whatever event provider database to make it easy for me to unit test that complex behavior. But then if I have to mock a lot because I don't know the event is very complex and it can have so many different states, then yeah, I think there is a point where it's not worth it anymore and you end up spending so much time if you want to be comprehensive and also end up with code that is very brittle every time something changes, you better have to rewrite most of your tests. So it's not like I think, yeah, there is a line where it still makes sense but then you cross that line and it doesn't make too much sense anymore.
- [38:16]
B
Yeah, I really like having the core journeys as end to end tests that run synthetically. So you know, when I'm designing systems, I'm, I'm trying to design systems in a way where I can, you know, segment data and make sure that I can send synthetic test data through the system. So if I cast my mind back to when I worked in the, the betting industry, we would have a synthetic football match being played via a test handler. So that meant that there was always events going through the system whether or not there was any real football being played. And that just meant that we were able to see if any component that we'd released had caused a breakage. Because that's the other problem with kind of time based systems or event based systems. If there's no events triggering the application, it's hard to know if they currently in a working state. So synthetic data going through the, through the system that can be segmented in some way from production so that it's not, you know, displayed on the website, I think is a really, really good trick as well.
- [39:26]
A
Yeah, but probably that requires a significant investment as well because you are effectively building like a simulation of in that case like a football match which might not be very trivial to build.
- [39:36]
B
Yeah, but I think these are the sort of things that you, you end up thinking it's a heavy investment. Well, maybe it is. But when you are able to, I mean any non trivial application, so any enterprise application that's going to have a, any sort of longevity, these are always going to be cost savings that just come back again and again. And being able to have a, you know, a constant benchmark is a really valuable thing. So I would. I would recommend investing in test tools and something that I always did as a tech leader, being able to, you know, not rely on an external dependency for testing. So if I'm integrating with a, I don't know, a data provider, I would often make a substitute that data provider so that I could change the behavior, you know, what happens to my application when that provider increases in latency or has a timeout period or some other behavior if it changes the format of their data. So being able to have really strong testing tools allows you to really test your application, whereas if you just take the happy path of their integration, often you don't see these side quests that go wrong.
- [40:54]
A
Awesome. Yeah, I totally agree with that. Now I think we are getting close to the end. I have only one final question, which is where people can find useful resources and maybe you can share something that is more appealing for beginners, something that can be more interesting for experienced people. And I know you have been investing your own time in building material, books and simulations and lots of other interesting stuff. So feel free to mention all of those things which I think are super cool and extremely useful.
- [41:24]
B
Yeah, so there is a lot of material, a lot of it is maybe not well connected. So I think more of it will be more and more connected on the, on the Lambda documentation. So that's a good place to start. Start. Serverless Land has a whole Java section with material on how to migrate and how to effectively use Java on Lambda. So if you, if you search for that phrase on Google, you'll probably find quite a lot of material. So effectively using Java on Lambda. And yeah, you know, something that I've been thinking about a lot is, you know, I've probably had more conversations about Java and Lambda than pretty much anybody in aws. I think that might be a bold statement, but I think the majority of people who I would work with would probably agree with me on that. And I started to write down all of my kind of common, common notes that I would discuss with customers and I started writing those down. I try and do, you know, 500 words a day and now I think I'm at about 10,000 or 20, 12,000 words. And I've published a ebook. So if you go to my website, sales.co.uk hopefully link in the description, you'll find a book that you can purchase. It's incomplete, so the price isn't too high, but it has a lot of good material around these sort of topics. So, you know, how do I start thinking about optimizations? How do I Get to the lowest possible cold start values. You know, what sort of considerations do I need to think about using? Observability and lambda, those sorts of things. So all of my kind of top tips in a very condensed short ebook. So easy to read and easy to get value from.
- [43:11]
A
Yeah, I'm sure that if somebody buys the book now, they will get also future releases as well, right?
- [43:16]
B
Yes.
- [43:16]
A
That the model you have in mind?
- [43:18]
B
Yeah, absolutely.
- [43:19]
A
Awesome. Then we'll put all the links in the show notes. So not just the book, but all the other tools and links to libraries and frameworks that we mentioned today. I also know that you have a few simulations about lambda snapstart priming and in general like the life cycle, cold starts and reusage and reclaiming of lambda environments. I think those two are also two other great resources for people that are starting with serverless and lambda to really understand what is the model that the platform is giving you. Like visually seeing it I think is much more powerful than reading a piece of documentation, trying to imagine in your mind like all the different phases. I think.
- [44:03]
B
Yeah, and that's why I spent time creating those things. I think once you understand the execution model of a lambda function, I think a lot of things click and then you start to understand what is a suitable use case, what is not a suitable use case. Maybe where past decisions on applications don't help future performance. I think that's the real key thing to understand as a new developer. Learning serverless or learning lambdas, should I say?
- [44:35]
A
Absolutely. And to be fair, I think most serverless environment have similar characteristics. So even if you want to go to something else later on, it's definitely useful to know the ins and outs of lambda and then post them to another provider.
- [44:49]
B
Absolutely. I mean, you know, a lot of the, a lot of the optimizations that you would do for lambda, even if you did go to a container environment, for whatever reason in the future you're gonna, you're gonna benefit from so much improvement, which means that your horizontal scaling will be faster and you'll just, your costs will be more aligned to the traffic that your application receives. So it's always a win win.
- [45:15]
A
All right, so before we wrap up, I have to give a big shout out to our usual sponsor for theorem. And what I want to say is that I work for Forthereum, so of course I'm biased. And at fortierm we work with the cloud. We believe the cloud should be simple, scalable, cost effective and we help teams to succeed with the cloud. So whether you're using containers or trying to build an event driven architecture, or Even just using SaaS and trying to scale it globally. Keep us in mind, we'd love to work with you. Check out forthereum.com where you can find everything about for theorem, some of our case studies, and of course feel free to reach out and talk to us. So that brings us to the end of this episode. Marc has been a real pleasure to have you. I think I learned a lot, so thank you very much. From myself in the first place, hopefully everyone else here listening has been learning a lot. Feel free to drop your comments, your experience. We always love to hear from our listeners and learn from them and share everything we learn and build a better cloud together. So thank you very much and we'll see you in the next episode.
- [46:23]
B
Thank you. Bye.