Confirming the Continuous Deployment Pipeline

Lets verify that changes to our application will be automatically available when they’re pushed up.

Update the Application

Let’s start a new branch

$ git checkout -b "greeting-change"

Now update our service to return a different greeting:

@Component
public class HelloWorldService {

    public HelloWorld helloWorld(String name) {
        return HelloWorld.builder()
                .response("G'Day, " + name)
                .build();
    }
}

Commit and Merge

$ git status
$ git add .
$ git commit -m "changed greeting"
$ git push --set-upstream origin greeting-change
$ git checkout main
$ git merge greeting-change
$ git push

Review the Actions

This should have kicked off a workflow

Now execute your postman request again (you shouldn’t need to change anything)

Final Thoughts

Lambdas are kind of cool, but this implementation has a bunch of drawbacks

Large File Size – This is directly related to the fact that I am ‘cheating’ and using spring framework to abstract a lot of the implementation. The shaded jar doesn’t know what I’m using so it packs up everything. There are ways to make the artifact smaller by eliminating unused classes and libraries(by using Proguard, for example). However, because I’m using the built in spring handlers outside of the code, proguard won’t know to include it. There are ways around that (i.e. explicitly including the library), but then this just becomes more problematic code maintenance and tribal knowledge.

Lambda Interfaces – This isn’t necessarily a lambda problem because if I was going to construct a well built REST interface using spring boot I would probably have to spend the same amount of effort applying best practices. This implementation is hiding a ton of behind the scenes effort. For example, transforming an api structure to a message structure (and mapping the headers correctly) is about 3 lines in my code, but that’s because spring is doing a lot of that work for me. However, if I was doing anything even a little more complicated I might not be able to use the ‘out of the box’ solution. Take a look at the aws documentation on building a java based api gateway request handler. There’s json serialization happening, streams, etc… that if I had to implement by hand might become a problematic maintenance problem quickly.

Testing – There’s no way (that I can see) to build a component test outside of the deployment. Most of the work that we did was to convert the service into a function and that code is untestable (or difficult to test) outside of the deployment. If we write spring boot microservices using the traditional Controller structure we can write tests that execute as part of the build pipeline and we would be able to catch breaking changes earlier. In this implementation, I have to deploy to test which can add minutes to the feedback loop.

There’s probably better ways to implement lambda and this was my initial experiment. This is extremely cheap to run and was fairly easy to stand up, but if we wanted to build an entire system or application based on this, it could become problematic very quickly.

If you have suggestions on how to implement java based lambdas, please give me feedback in the comments. I would be willing to try other implementations. However, for me, the effort to build docker based microservices deployed into kubernetes is about the same (or easier) and I have more faith in the code because I have better testing.