AWS re:Invent 2022 - AWS Lambda SnapStart: Fast cold starts for your Java functions (SVS320)

Aug 16, 2023

AWS re:Invent 2022 - AWS Lambda SnapStart: Fast cold starts for your Java functions (SVS320)

In this session, learn about the newly released AWS Lambda SnapStart service. With new innovations, AWS SnapStart makes your Java-based function cold starts up to 10x faster, typically with no changes to your function code.

Learn more about AWS re:Invent at https://go.aws/3ikK4dD.

Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4

ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.

AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

#reInvent2022 #AWSreInvent2022 #AWSEvents

Content

0.21 -> - Hello everyone!

1.53 -> Thank you so much for coming here.

3.54 -> It's fantastic to see so many people.

6.09 -> This is just kind of overwhelming, but we'll be okay.

11.07 -> So thank you very much for coming.

12.33 -> I'm Mark Sailes.

13.65 -> I'm a solutions architect at AWS

17.28 -> and I specialize in the serverless services,

20.34 -> so API gateway, Lambda, SNS, SQS, things like that.

24.78 -> And I also really enjoy Java

28.2 -> and I've been programming in Java for a long time,

31.912 -> (chuckles)

33.03 -> ever since I've been at university.

36 -> And I work with a lot of customers

38.07 -> who are looking to adopt AWS Lambda

41.76 -> and have lots of Java applications.

44.52 -> And I really work with those companies to look at

47.79 -> how they can bring those applications from either ET-2

51.12 -> or from their own data centers

53.31 -> or from containers and bring those onto AWS Lambda.

57.37 -> And I really enjoy that work, it's really interesting work.

60.72 -> But it can be frustrating at times.

63.45 -> So if you've been one of those frustrated customers

66.75 -> who's used Java and Lambda before,

69.72 -> this is a session for you, okay?

71.82 -> So hopefully we're gonna tell you about

72.99 -> some really cool new stuff, Lambda SnapStart for Java,

77.43 -> and hopefully you'll make that journey to Lambda

79.92 -> a little bit easier.

83.91 -> So I said I've been using Java for a long time,

87.06 -> probably about 20 years now,

88.83 -> which is seems like an incredibly long time

93.33 -> and I've enjoyed it for many different reasons.

96.45 -> You know, I've enjoyed the language,

98.4 -> I've enjoyed the community,

99.84 -> I've enjoyed all of the free code

102.9 -> that I get from all the open source,

104.22 -> amazing open source projects.

106.02 -> You know, I've really built some fantastic things

108.21 -> with the code that people have shared over the years.

112.05 -> But I've noticed over the last few years,

113.91 -> but there seems to be this really renewed surge in Java

118.857 -> and I think one of the reasons for that

121.02 -> is the release change, the cadence change

124.98 -> that came to Java in the last few years.

127.95 -> So instead of having long periods between releases,

130.44 -> we now get two releases every year,

132.6 -> which I think is just fantastic.

134.58 -> So it's really born out a whole heap of new innovations.

137.37 -> So things like Project Loom

139.41 -> and Project Laden and Project Crack,

144.63 -> which is a proposed project

146.28 -> which we're gonna talk about later.

148.53 -> And I'm really enjoying this like renewed, interesting job.

151.89 -> I think it's fantastic.

155.04 -> This is a kind of a histogram graph

158.37 -> of the number of requests,

163.482 -> a low latency and a high latency.

166.59 -> And this is a really exaggerated graph

168.57 -> because I've had to put it onto a slide to show you all.

172.257 -> But what it's really showing

173.09 -> is that the vast majority of requests

176.01 -> actually happen really quickly.

178.38 -> But there's a small number of requests

180.63 -> that actually have a very long latency,

183.18 -> and that's really frustrating

184.92 -> if you're building customer facing APIs

188.01 -> or something that requires a really responsive,

192.3 -> really responsive interaction.

204.57 -> So to demonstrate this new functionality,

208.71 -> I've put together a really simple Spring Boot application.

213.03 -> So I've got a Spring Boot application

215.04 -> that takes requests from API gateway,

218.55 -> processes them in a Lambda function,

220.407 -> and then storing and retrieving information from DynamoDB.

224.76 -> So just like a lot of Spring Boots apps

227.28 -> you might be familiar with,

228.21 -> I have a controller with a bunch of NBC actions,

233.82 -> I have some business logic in a service

236.31 -> and then I have another class that calls DynamoDB

241.32 -> for the various operations.

245.25 -> And for the majority of the time,

247.44 -> I get warm starts, very fast invokes around 10 milliseconds,

253.38 -> and this is the vast majority of our calls.

257.07 -> But occasionally I'm gonna get much slower responses

262.53 -> and these can be in the order of seconds.

264.75 -> So in this example,

266.13 -> I've got a six and a half second cold start

270.48 -> and further 600 milliseconds to invoke my function.

276.15 -> And in reality, this is a very small percentage of invokes,

280.23 -> but that's still frustrating for our customers

282.75 -> who are using our APIs.

284.43 -> They always want to have a fast responsive

289.14 -> use of our systems.

290.76 -> So we really want to try as best we can

292.98 -> to reduce our cold starts

294.66 -> and have a really responsive application.

298.89 -> But before we dig any deeper,

300.39 -> let's just talk about maybe why that's happening.

303.12 -> So what is it about Java

304.83 -> that it has these specific characteristics?

308.34 -> Well, when we make a new execution environment for Lambda,

313.05 -> we're doing the same things as other run times.

315.66 -> So we're creating the firecracker instance,

318.42 -> we're downloading the code onto that instance

320.91 -> and we're starting the Java runtime.

328.02 -> But then Java is doing some Java specific things.

331.41 -> So it's doing the class loading of your classes

335.25 -> into the JVM.

337.32 -> If you're using a framework that uses dependency injection,

340.74 -> it's doing quite a lot of reflection

342.6 -> and working out what should be where and what to do next

346.02 -> and that takes time.

347.73 -> And also Java is taking your byte code

350.28 -> and compiling it to run natively on your machine.

354.18 -> So all this takes time and this is a first invoke issue

358.65 -> and this happens when you create

360.33 -> a new execution environment.

366.51 -> So before SnapStart,

367.86 -> people would spend time looking at each of these areas

370.83 -> and there'd be different optimizations that you could do

374.37 -> in order to mitigate some of these issues.

379.14 -> So people would look at the dependencies

380.85 -> that they were using for their applications

382.89 -> and maybe try tailoring them down,

384.81 -> so maybe I don't need a really complicated logging system.

388.98 -> Maybe I can use Slf4j-simple,

391.8 -> and maybe with less features,

393.33 -> I'll have a faster startup time.

396.51 -> With dependency injection,

398.1 -> there's lots of really cool frameworks

400.11 -> that do dependency injection,

402.15 -> and some of them run at runtime

403.89 -> and some of them run at build time.

405.96 -> So Micronaut, Quarkus, Dagger

408.42 -> are all dependency injection frameworks

411.48 -> that do all the dependency injection at build time.

415.2 -> And that means there's less work to do

417.739 -> at the first invoke of the Lambda function,

419.61 -> which is really important.

423.57 -> There's also ways to help the just in time compilers

428.22 -> so that they have a faster experience as well.

430.2 -> So with your Lambda function,

432.33 -> if you specify that the Lambda function has more memory,

435.84 -> it's also allocated more CPU at the same time.

439.62 -> And Java really needs CPU at the beginning of its invoke

443.58 -> to compile over your byte code into native.

447.06 -> So it really needs that CPU right at the beginning.

449.94 -> So if you are having slow cold starts,

452.64 -> adding more memory is a really, really simple thing to do

455.7 -> to have a faster performance.

458.16 -> And again, we published a blog this year

461.43 -> about tiered compilation, which is a feature of Java

465.24 -> that allows you to change what the compilers are doing when.

470.13 -> And we found that

471.87 -> actually some of the compilation activities

475.53 -> are best to be tailored down

477.54 -> so that we have a faster first invoke.

481.23 -> And then right at the end,

482.28 -> we're talking about ahead of time compilation.

485.19 -> So we can do all of the compilation of our Java code

488.79 -> ahead of time, produce a native executable

492.99 -> and invoke that instead of a Java function.

497.395 -> And really all of these optimizations

499.38 -> come down to various amounts of effort

503.67 -> to do various amounts of improvements to your cold start.

509.16 -> So we have on the left hand side

512.13 -> things that require more code, more comping changes

516.06 -> and are maybe easier, less effort to do,

520.92 -> and they'll get you so far.

522.66 -> But actually to get the really fast cold starts,

525.48 -> you actually need to make larger changes to your code.

529.74 -> And this is where we really think we can help innovate

533.125 -> and help our customers by innovating in this area

536.499 -> to provide something that's completely different.

539.4 -> How can we really produce much faster cold starts

543.87 -> for your Lambda functions?

546.57 -> So this is AWS SnapStart up to 10 times faster performance

551.25 -> for your cold starts.

554.19 -> So we really want to make it easy for you to build

557.1 -> highly scalable applications

559.38 -> with really responsive feedback.

565.17 -> How this is gonna work

567.75 -> is that when you enable SnapStart for a function,

572.04 -> so it is not enabled by default,

574.53 -> you make a config change to your Lambda function

576.603 -> at a function level.

578.85 -> When you create a function version,

582.48 -> then we're gonna take your code and initialize it.

587.49 -> And once the initialization is finished,

589.8 -> we're gonna take a snapshot of the entire virtual machine

594.84 -> that that function is running on.

601.38 -> We're gonna store that snapshot encrypted

604.14 -> in our own data store,

606.06 -> and then we're gonna load that snapshot

607.56 -> into a series of tiered caches for low latency retrieval.

617.43 -> While that process is happening,

619.86 -> the function version will be in a pending state.

622.89 -> That means that the function won't be able to be invoked.

627.39 -> Once the snapshot has been taken,

630.84 -> this will be changed to an active state

633.36 -> and you'll be able to invoke the function.

636.39 -> When you come to invoke the function,

638.19 -> it will restore the execution environment from the snapshot

642.87 -> and then the invoke will happen.

647.01 -> And in the same way today that you can spawn

650.19 -> lots of execution environments really quickly,

652.65 -> the same is true with SnapStart.

656.07 -> All future execution environments for that Lambda version

659.46 -> will be created from the same snapshot.

662.82 -> So you'll get multiple resumes as your traffic increases,

668.364 -> the more and more execution environments will be created

670.5 -> to handle the traffic as it comes in.

672.63 -> And each time, there will be a resume from the snapshot

676.41 -> and then you'll get your function invoke.

688.71 -> So let's dive a little bit deeper now.

691.32 -> We'll talk about the new invocation model.

694.74 -> So the invocation model has changed very slightly.

698.07 -> So in the same way we're still gonna,

701.22 -> when we create the snapshot,

702.33 -> we're still gonna do the same sort of steps,

704.13 -> but we're also gonna give you an extra opportunity

707.04 -> to run specific code that you want to run

710.52 -> before the snapshot is taken.

712.59 -> And I'm gonna gonna talk about why that might be important

714.69 -> a little bit later.

716.52 -> What we found in testing, it's actually really important

719.79 -> to give customers the opportunity to run their specific code

723.84 -> at specific times and that's really useful.

726.69 -> So there's gonna be a specific hook

728.7 -> before and after the snapshot is taken.

733.23 -> This is the pre and the post snapshot hooks.

742.05 -> So my Lambda function, my Spring Boot application

745.53 -> that is taking a request of a HTTP and writing to DynamoDB.

751.08 -> I moved from a cold start of around seven seconds

754.86 -> for my example application

756.63 -> to a first invoke of 950 milliseconds,

760.38 -> which I think is a really fantastic change

762.54 -> for a simple config change.

765.15 -> So this is a really, really cool improvement

767.46 -> and I think you'll really find it interesting to try it.

771.03 -> So let's just go over how you might try it

773.13 -> on your own functions.

775.86 -> So in general configuration, there'll be a new item,

779.04 -> which is called SnapStart, and it has a single option,

782.7 -> which is called Published Versions.

785.07 -> So you can go into the console,

786.93 -> it's available today and select your function,

791.67 -> configure it for SnapStart.

795.57 -> If you are using SAM,

798.54 -> this function is available today for SAM.

801.3 -> You can add the SnapStart attribute to your YAML file

805.32 -> and publish in the same way.

808.26 -> And this is what it will look like with CDK as well.

814.23 -> So let's just talk a little bit more about the versioning.

816.66 -> So I mentioned that SnapStart requires function versioning.

820.47 -> If you're not used to using versions,

822.48 -> this isn't something new.

826.29 -> If you are integrating two services,

828.87 -> so for example, API gateway to AWS Lambda,

834 -> you might be used to connecting those two services

837.57 -> with the function version ARN.

841.17 -> With SnapStart, you need to specify the version

845.49 -> that the SnapStart process has been enabled for,

849.18 -> or an alias to that version.

852.54 -> If you don't specify either of those,

855.48 -> it won't invoke the SnapStart function,

859.38 -> it will invoke your normal on-demand function.

862.95 -> So if you're trying this for the first time

864.69 -> and you don't see any change, just double check this, okay?

869.01 -> Make sure that you are invoking the function version.

875.52 -> Okay, so I mentioned the hooks.

880.77 -> Let's talk about how this will actually happen.

884.28 -> So we've got the opportunity to run code

886.59 -> before and after the snapshot process.

891.39 -> This is an example handler written in Java,

895.74 -> and I've also added an extra interface here,

899.73 -> so you'll see the resource interface.

902.97 -> So this isn't a interface that's available in Open JDK.

906.99 -> It's part of a project called Crack,

908.91 -> which stands for Coordinated Restore at Checkpoint.

913.23 -> And it's a proposed project for the Open JDK project.

917.67 -> So it's not available in the Open JDK yet.

919.89 -> It's an external dependency

921.54 -> that you add to your Lambda function.

924.93 -> Then you can implement resource

927.63 -> and you'll see that there's two extra methods

929.22 -> for this handler.

930.72 -> This can be added to your handler

932.16 -> or it can be its own class.

935.13 -> And here, very simply, I'm just printing out some messages.

938.28 -> But this could be any code that you have

940.083 -> that you want to run before and after the snapshot.

944.28 -> Okay, so why would I want to run code

947.07 -> before and after my snapshot?

949.89 -> Well, I just want to tell you

951.9 -> some of the things that you might want to consider.

954.03 -> So we're changing the way that Lambda functions are created

959.04 -> and we are now restoring from snapshots.

962.22 -> So each environment is gonna be the same.

965.88 -> So there's really two or three things

968.82 -> that you really want to think about

970.02 -> when this is, how you program.

973.389 -> So the first is network connections,

975.48 -> second is ephemeral data and the third is uniqueness.

979.86 -> Let me give you some examples just to talk through these.

984.6 -> So say I have a Lambda function,

987.75 -> which is speaking to an RDS database.

991.83 -> In my Init phase, I might eagerly connect to that database

996.96 -> so that the connection is ready

998.67 -> when I make my first queries or my first rights.

1002.75 -> If I make this connection eagerly,

1005.69 -> then my snapshot is gonna have a memory

1009.56 -> that this connection is made.

1012.5 -> When I resume from that snapshot,

1016.25 -> I could be on a different host, it could be weeks later,

1019.52 -> that network connection won't exist.

1022.91 -> So when I come to invoke the Lambda function,

1026.03 -> I'm gonna get a connection failed and I'm gonna retry.

1034.04 -> So this is an important thing to consider.

1035.99 -> This isn't a new problem.

1037.64 -> This could happen to Lambda functions today.

1040.73 -> Your network could have an issue,

1044.15 -> your Lambda function could have a different time out

1046.58 -> to your database.

1047.9 -> There could be a number of different reasons

1049.25 -> why this might happen.

1050.69 -> This is a new way that this error could surface.

1053.09 -> So it's a really good thing to think about.

1056.54 -> A lot of applications

1058.46 -> when they're making database connections,

1060.92 -> they have in-built functionality to make retries.

1065.6 -> So we found in our own testing

1067.22 -> when we've been using various open source

1069.59 -> connection pooling libraries,

1071.6 -> that they are perfectly fine with being snapshotted.

1075.38 -> Once they resume,

1076.46 -> they realize that the network connection isn't there

1078.8 -> and they retry.

1082.7 -> Okay, let's talk about ephemeral data.

1085.79 -> And by ephemeral data,

1086.99 -> I mean data that might change over time.

1089.9 -> So for this example, I'm gonna talk about Secrets Manager.

1094.61 -> So I might connect to Secrets Manager

1096.62 -> to get a database password

1098.54 -> or some other sort of application configuration

1101.09 -> I wanna keep secret.

1102.56 -> Maybe it's a password to another API endpoint.

1107.03 -> And I might retrieve that eagerly

1108.62 -> because I only need that once.

1110.51 -> So I'll grab that in the Init phase.

1113.54 -> Again, if I'm using SnapStart,

1115.31 -> that secret is gonna be saved into the snapshot.

1120.98 -> If in the future that secret is rotated,

1124.46 -> my snapshot is still gonna remember my initial value.

1129.05 -> So I could get an error,

1130.28 -> something like incorrect credentials.

1135.14 -> My Lambda code needs to be aware that that might happen

1138.86 -> and it needs to go re-fetch those credentials.

1142.7 -> And it's the same, this could happen today

1145.61 -> with regular usage of Lambda

1147.617 -> and you should be able to be aware that this may happen,

1152.27 -> catch the errors and continue.

1154.61 -> But again, this is a new way

1156.05 -> that this error might surface, so be aware.

1162.08 -> And then finally, we are creating new execution environments

1166.67 -> from a snapshot.

1169.22 -> You could well think that that might cause problems

1172.7 -> with randomness or uniqueness or cryptography.

1176.87 -> We don't want to have the same seed

1179.3 -> when we're producing random numbers.

1183.04 -> AWS has made updates to Amazon Linux 2 and OpenSSL

1192.65 -> so that they are resilient to the snapshotting process.

1195.74 -> If you're using host best practices

1199.19 -> for producing random numbers, then this is the way to do it.

1205.13 -> Something like OpenSSL, /dev/random, /dev/urandom,

1209.397 -> these are the best ways to produce

1211.58 -> cryptographically saved random numbers,

1215.3 -> and we've tested these.

1218.45 -> We've also tested that the Java 11 runtime

1223.04 -> using Java security SecureRandom is snapshot aware.

1227.78 -> So producing random numbers in this way

1231.41 -> will continue to work.

1235.49 -> If you are producing random numbers in another way,

1238.13 -> if you produce your own mechanism

1240.05 -> for producing random numbers,

1242.27 -> then this is where I would look at your function code,

1245.78 -> try testing it and if there is a mechanism

1249.08 -> where you are not producing random numbers

1251.15 -> and it's creating random numbers that are predictable,

1254.27 -> then this is where I would use

1256.49 -> some of the hook functionality

1257.93 -> to make sure that that is reset

1259.94 -> so that your random number code continues to work.

1271.31 -> We're also producing an open source project,

1274.43 -> which will use the SpotBugs plugin

1278 -> to help find potential anti-patterns.

1282.05 -> So if you are using something like java.util.Random,

1286.55 -> this is not cryptographically safe

1289.64 -> and this could be a source of errors

1293.12 -> if you're using snapshotting.

1297.65 -> Okay, so I've tested out this sample application

1304.85 -> and I've produced a small test

1308.18 -> which fires in a hundred requests a second for 10 minutes.

1312.89 -> So I'm starting from a completely cold application

1316.91 -> and I'm just firing in a whole heap of requests.

1319.88 -> So this is a real test for Lambda

1322.43 -> because it's just gonna go from zero

1324.38 -> to a hundred straight away.

1327.8 -> Before SnapStart, this was my results.

1332.84 -> So my average response time was really fast,

1335.21 -> eight milliseconds, but my tail latency, my 99.9% latency

1341.48 -> was over five seconds.

1344.36 -> With SnapStart, my P50, my average

1348.08 -> is still exactly the same,

1350.39 -> but my tail latency is much reduced.

1353.78 -> So 536 milliseconds.

1356.713 -> I think that's a really fantastic improvement.

1362.15 -> And this is where we could kind of end the talk,

1365.21 -> but this is a level 300 talk,

1367.46 -> so I think we can go a bit deeper

1369.077 -> and talk about some more interesting things as well.

1372.92 -> So let's really think about what Java is doing

1376.43 -> and what we can do with this new functionality that we have.

1382.28 -> So Java is doing class loading, dependency injection,

1384.98 -> just in time compilation.

1387.05 -> Okay, so I can produce a resource with some hooks

1395.63 -> and I can do some interesting functionality with this.

1398.78 -> So I've got my application

1400.58 -> which is making requests to a unicorn store

1403.82 -> to read and write unicorn records

1407.3 -> and this is an example of a spring style class

1412.52 -> which implements the runtime hooks.

1416.03 -> So I've got my @configuration annotation

1418.97 -> which is gonna produce a singleton of this class.

1421.94 -> When that happens, I'm gonna register this class

1425.15 -> with the runtime hooks.

1427.22 -> So I'm gonna do call, get global context register

1430.91 -> and that's how this class is known by the runtime

1434.42 -> to do the before and after hooks.

1438.35 -> And then you'll see in the before section,

1441.56 -> I've got a reference to my controller.

1443.81 -> I'm gonna make a fake request to that controller.

1447.41 -> And because I'm the application developer,

1448.97 -> I know that this is a safe operation, okay?

1451.67 -> So I know that making a dummy call

1454.31 -> to a get operation is safe.

1458 -> And what this is doing,

1459.26 -> this allows me to really execute all of the code paths

1463.79 -> in this functionality.

1465.14 -> So it's gonna execute the controller,

1468.32 -> it's gonna invoke the service,

1470.57 -> it's gonna invoke my DynamoDB repository

1473.57 -> and then it's gonna call DynamoDB with the AWS SDK,

1478.04 -> which means all of those code paths

1480.11 -> are gonna be initialized and compiled.

1483.08 -> And this is gonna happen before the snapshot is taken,

1486.26 -> which means that the next time my function is invoked,

1490.46 -> all of that code will be compiled and really ready to go.

1496.55 -> So I now go from a cold start

1499.7 -> or a P99 of 536 milliseconds

1504.2 -> all the way down to 808, 488 milliseconds,

1508.28 -> which is fantastic.

1511.34 -> So even doing nothing,

1514.61 -> I can really get fantastic performance,

1516.47 -> but also we give you the ability to look at your application

1521.75 -> and if there's any other information

1523.31 -> or other actions that can be taken,

1526.13 -> you also get the ability to do this.

1528.86 -> Okay, so this is my simple test,

1531.53 -> but we've had luckily some of the customers

1533.96 -> as part of the beta program

1535.52 -> who have also been involved in this

1537.98 -> and here's a couple of quotes from them.

1539.87 -> So I'll let you read these.

1556.07 -> I think this is really fantastic.

1557.36 -> There was definitely use cases

1559.43 -> that were very difficult to achieve with Lambda.

1562.43 -> I think SnapStart really helps you to make that gap

1567.44 -> more and more easy to achieve.

1570.83 -> And just one more from Bill.com.

1584.15 -> This is a really high throughput system,

1587.78 -> six and a half million invocations per day,

1593.18 -> and improved cold start performance by 95%.

1597.32 -> I think that's fantastic, really cool.

1601.37 -> Okay, so if this is maybe interested

1604.04 -> or renewed your interest in Java

1605.78 -> and renewed your interest in Lambda,

1608.09 -> we'll also gonna tell you about another open source project

1610.13 -> that I'm involved in.

1611.69 -> This is called Lambda Powertools for Java.

1614.75 -> Lambda Powertools is an open source project

1619.28 -> that really helps developers

1622.07 -> implement Lambda best practices as easy as possible.

1626.21 -> And we have a set of tenets that we are really proud of,

1630.868 -> that guides the direction that Powertools goes in.

1633.26 -> So Powertools is a framework and a set of client libraries

1638.78 -> that is just AWS Lambda focused.

1640.91 -> So we don't focus on any other run times,

1643.94 -> we don't focus on containers.

1645.32 -> We're just producing the best practices for Lambda.

1651.56 -> And over the years the Powertools has been available,

1654.86 -> we've listened to the community

1656.45 -> and we've listened to what people have been telling us

1659.09 -> and what people have been finding hard

1660.83 -> and what people have been finding difficult to produce

1664.16 -> and code that they've been producing over and over again

1666.92 -> and they wish that they could have from a framework.

1669.98 -> So we've produced a whole heap

1671.3 -> of different functionality for Powertools.

1681.65 -> If you're interested in Lambda SnapStart

1684.26 -> and you'd like to take this away and try it,

1687.44 -> then we're gonna be updating our Lambda workshop for Java

1691.04 -> in the next few weeks.

1693.8 -> We're gonna add a whole section on SnapStart,

1697.19 -> and this is something that is available publicly,

1700.43 -> although it's not ready right now.

1702.41 -> If you keep checking,

1704 -> hopefully this will have a new section all about SnapStart

1707.304 -> and this will take you through a step by step guide

1710.36 -> of how to take an application

1711.89 -> and enable it for SnapStart and see the results.

1718.4 -> And if you like this session on Java,

1720.74 -> then I have another session on Thursday,

1722.93 -> which is called "Effectively using Java on serverless".

1725.84 -> This is a chalk talk and a real opportunity

1728.63 -> to go deep into some specific areas

1731.75 -> and ask a whole heap of Oracle questions.

1735.11 -> So if you'd like to come,

1736.16 -> I'd love to have you there as well.

1739.04 -> So thank you very much for listening.

Source: https://www.youtube.com/watch?v=ZbnAithBNYY