AWS Lambda – querying and updating the Lambda runtime with the AWS CLI

In a previous post I used jq to parse the responses from the aws cli for Lambdas to search for or parse the results for specific property values. Querying Lambda properties can also be done via the aws cli itself without using jq (although using jq is significantly more powerful).

If you’ve received an email from AWS about runtimes that are reaching End of Life, the emails usually contain an example use of the cli showing how to query for specific runtimes, for example:

aws lambda list-functions --function-version ALL --region us-west-1 --output text --query "Functions[?Runtime=='nodejs14.x'].FunctionArn"

The long term solution for upgrading a runtime should be to redeploy and test with the latest runtime and then redeploy your production value after testing. It is possible for a quick fix to update the runtime of a deployed Lambda directly via the aws cli. Once you’ve identified which Lambdas need to update, use this command to update:

aws lambda update-function-configuration --function NAME --runtime RUNTIMENAME

A commitment to unit testing can result in easier to maintain code in the long term

The benefits of religiously following a strict Test Driven Development (TDD) approach (always write tests first before code) is a hotly debated topic. No experienced developer should ignore the fact that testing is essential, but there are debatable pros and cons for whether writing unit tests before, during or after has the most benefit.

If your team has a commitment to unit testing there is valuable side benefit to your code quality that can arise by itself but is usually encouraged by more experienced development teams. Overly complex code that doesn’t have a clear or single responsibility, is tightly coupled with other code and/of is excessively long, is hard to test. Complex code is hard to understand and maintain, it’s usually also the source for more defects compared with simpler and easier to understand code. Effective teams always look for areas where they can become more efficient and make their lives easier, and simplifying code to make it easier to test brings these additional benefits with it.

By adopting a mindset that code should be structured so that it is easier to test, you instantly gain from the benefits of simpler code that’s easier to maintain. Win-win all round.

Building a Maven based Spring Boot app with multiple app classes with main() methods

I have a Maven based Spring Boot project with 2 Application classes. One is my main Spring Boot app, the other is a standalone example app. When attempting to build with ‘mvn package’ I get this error:

[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:2.6.4:repackage (repackage) on project xample-client: Execution repackage of goal org.springframework.boot:spring-boot-maven-plugin:2.6.4:repackage failed: Unable to find a single main class from the following candidates [kh.aprs.botexample.APRSISBotExampleApplication, kh.aprs.clientexample.APRSISClientExampleApplication]

The 2 apps listed are my 2 apps, but only APRSISBotExampleApplication is the one I want to get packaged, so I need to tell Maven which is the the main app. This is configured with the <start-class> property, configured in a properties section like this:

<properties>
 <start-class>your.package.YourApplication</start-class>
</properties>

This is described here.

Calculating elapsed minutes between LocalDateTime instances

There’s many ways to this, like getting epoch millis, calculating the difference and then converting back into the units you need. With java.time apis and java.time.temporal.ChronoUnit you can calculate the difference between 2 LocalDateTime instances easily in one step with:

long elapsedMins = ChronoUnit.MINUTES.between(start, end);

I was looking for a refresher on how to do this and found my own post from 3 years ago in a Google search here (funny when that happens).