Visiting JavaLand 2019

Last week I have attended JavaLand 2019 which was a great experience for me. Lots of different people, interesting talks and great speakers! It was my first time there and I have to admit: not only the usual conference content was great, but also the location was really unique – it’s located in Phantasia Land, an amusement park in Cologne, Germany.

I gained a lot of new ideas and thoughts which I want to share with you here. This is not a super-detailed summary of each talk, so don’t expect a complete lecture. Instead, I want to give you an idea of some talks, so you can dig deeper if you think it’s interesting for you. The reason is quite simple: Doing something on your own will bring the best learning experience.¬†(smile)

My Lessons Learned (or: TL;DR)

Based on the talk program and content, you can see a rough direction where the Java world is heading to and what’s currently going on there. Most of the talks I’ve visited have been around the following two topics:

  • Microservices, Microservices, Microservices: You should know what microservices are and how you can use them. Especially transactions in microservices are tricky, hence there were actually two talks about this topic. A common suggestion was to read the book¬†“Microservices Patterns“.
  • Domain Driven Design (DDD): If you don’t know what it is, you should have a look at a few articles online or read the¬†blue book about DDD. There is also another book “Implementing Domain Driven Design” which covers a more practical approach and was recommended in a lot of talks as well.

Besides that, a lot of talks focused on testing topics (e.g. testing with Docker containers, CI/CD), on recent Java/JDK updates (e.g. license change; GraalVM to convert Java to native code) or on anything related to the Java world (e.g. how to run a business on open source code).

My Top 3 Talks

It’s a hard decision to present the best three talks, because there were a lot of good talks. I’ve decided to present talks where a) I’ve learned the most about the topic, b) which were presented in a good way and c) where you can also benefit from.

Web-API-Design in Java (by Stephan M√ľller)

Slides: click here

First statement of the talk: the API is the UI of a developer. I really like this quote. He continued to show the five different ways how to build an API: 1) REST, 2) GraphQL, 3) Server-side events, 4) web sockets, 5) Event Feeds. The main thing to remember is: REST is good to be used for cases where you have data with certain boundaries, i.e. you just return well-defined data, whereas GraphQL is really helpful if your data is interrelated und you need to do a lot of connections between them. In that case, you can save a lot of HTTP requests by doing one request to your GraphQL backend. The remaining talk was covering best practices. From documenting your API (e.g. using Open API Specification), correct error handling (e.g. never return a stack trace!), data validation (e.g. using Java Bean Validation) over security (e.g. don’t use BasicAuth, instead use JWT) to versioning of your API (e.g. using the URL or an Accept-Header with a versioned media type).

Read more: API Design Guidelines collection

I have to admit: I’m already using a lot of the presented best practices. But it’s always good to double-check that again from time to time. Are you using everything of that? For the German speaking people here, I can highly recommend the book “REST und HTTP” which is related to this topic. I’ve read it and it covers a lot of good recommendations with really good examples!

Microservices and Transactions (by Lars Röwekamp)

Slides: click here

The talk started by presenting why starbucks does not use two phase commits. The real world is often not transactional, so why should you? Do you really need transactions? Can you solve the problem on the business level instead? Often this is the case! If transactions are really necessary, then use one of the following strategies:

  1. Think about your service boundaries again. You can merge services if it makes sense, but try to avoid building a new monolith again. (smile)
  2. Use a gateway service for transactions using¬†XA (eXtended Architecture)¬†and a two-phase commit protocol. (I think I haven’t heard about the term “XA” before, but I do think it’s a bad idea to use a centralized gateway service to manage all transactions across different microservices)
  3. DIY two-phase commit XA gateway – simple conclusion: don’t do it at home.
  4. Transactions using the¬†SAGA pattern. (I have to admit I haven’t heard about this pattern before) The basic principle is that you distribute business transactions into multiple technical ones, for example “create pending order”¬†‚Üí “check & reserve credit limit”¬†‚Üí “approve order with reserved credit limit”. In case of errors you have to stop and cancel (read: reset/redo) the previous operations. There are basically two ways to achieve this:
    1. using a choreography, meaning implicitly controlling the flow through events
      1. Problem: increasing complexity + your business code is distributed over your architecture
    2. using an orchestration, meaning explicitly controlling the flow by calling services directly with one master service → easier reset possible in case an error happens
      1. Problem: higher challenge to coordinate everything

Recommendation: use choreography if the process is quite simple (e.g. less than 5 steps), otherwise use orchestration. However, it’s not as easy as it might sound. For example, what happens if a microservice dies while performing the transaction? How can it catch up again and maybe resume the previous work (if required) ? Hence he’s suggesting to use a framework to support you with that, for example¬†Eventuate Tram Sagas.

There was another talk about this topic, called “Lost in Transaction? Data consistency in distibuted systems” by Bernd Ruecker, the founder of¬†Camunda¬†(a workflow engine to support such cases).

Btw. a book recommendation by Lars: “Microservices Patterns“.

Hitchhiker’s Guide to Serverless (by Lars R√∂wekamp)

Slides: click here

Using serverless in your app can lead to many different points of failures. Failures in your code, in the integration of functions or in services where you have no control of. Hence it’s necessary to use proper monitoring and testing of your functions.

Monitoring:

  • DIY: build your own tracing and monitoring solution, e.g. using serverless functions, and store data in different services, so you can analyze them as needed
  • Use cloud services: use already provided services like X-Ray or CloudWatch to monitor your metrics or inspect the runtime behaviour of your functions
  • Use external services: in case of a multi-cloud strategy you have to use services independent of your cloud provider, e.g.¬†logz.io¬†or¬†dashbird¬†or ELK-tracing.

Monitoring Tips:¬†monitor asynchronously (i.e. a user shouldn’t notice a higher latency because of monitoring), also monitor business relevant metrics (e.g. sales volumes, etc.¬†‚Üí if this decreases unexpectedly, then you know something is wrong in your system)

Testing Tips:

  • make sure to separate business logic and infrastructure glue code
  • write unit tests (e.g. using JUnit), write integration tests (e.g. execute functions locally and mock certain services ‚Üí¬†saves you money), write end-to-end tests (e.g. by running your cloud locally or at least in a separate dev environment which you can shutdown as soon as the tests are done to save money)

If you have further questions to this topic, let me know about it! I hope you enjoyed this short summary of my JavaLand 2019 experience.

Caching in AWS Lambda

 

Me presenting Caching in AWS Lambda

In every software application, there are usually two main reasons to cache data: a) to improve performance and b) to reduce costs. Caching in AWS Lambda is not different. Instead, the reasons for caching might be even more important in this context. This blog post explains why it could be necessary for you and shows how to implement different caching options. It’s based on a talk I gave at the AWS User Group Stuttgart meetup in December 2018. You can find the slides here¬†and the code is provided in this GitHub repo.

Continue reading

Remove old CloudWatch log groups of Lambda functions

Remaining Old CloudWatch Log Groups of Lambda Functions

Remaining Old CloudWatch Log Groups of Lambda Functions

Do you recognize this view when looking into your CloudWatch log groups? Each AWS Lambda function has an associated CloudWatch log group. However, there is no cleanup process available as soon as a relationship between a CloudWatch log group and Lambda function expires. In that case it’s necessary to remove these old log groups manually. In this post I’ll show you an easy way to always have a clean set of CloudWatch log groups by automatically removing old log groups.

Continue reading

My first time on a bigger stage

On the 7th of September, I gave a talk at Atlas Camp 2018 in Barcelona. You can watch it here on YouTube. It was my first time on a bigger stage and about 80-100 people listened to my words Рamazing! With this blog post I want to say thanks to all who helped me achieving this and share some lessons learned with you.

Continue reading

Shut down CloudFormation stack resources over night using AWS Lambda

A CloudFormation stack evolves over time and usually costs increase as well. You’ll probably not only have one stack, but instead have at least a production and a development stack. Even one development stack per developer might be common. This means the total costs increase even more. In order to prevent this, you might want to shut down CloudFormation stack resources over night to save costs. A neat way is to use AWS Lambda functions for this. You schedule them to execute after and before a regular working day to shut down or start up the stack resources. This blog post describes the steps to accomplish such a setup to decrease costs for developer stacks.

Continue reading

Creating Different Environments With AWS CloudFormation

Recently, a question on stackoverflow.com popped up which asked for different environments with AWS CloudFormation. Here, I want to present my answer and give some more information about this topic. The code for this blog post can be found in my GitHub repository where I also have some more CloudFormation examples.

Continue reading

Use Jersey and Spring in AWS Lambda

AWS Lambda is actually made to be used by implementing small functions which can be started quickly. So your code artifact should be as small as possible for a fast startup time. However, in the Java world there are nice frameworks like Jersey and Spring which can help you writing code for an API a lot! Unfortunately these frameworks can take up to a few MB and blow up your artifact, but you might have your reasons to use them in AWS Lambda, e.g. because you’re migrating an existing project to AWS Lambda. So let’s see, how you can use Jersey and Spring together in AWS Lambda! The code can be found in my GitHub repository lambda-jersey-spring-example.

Continue reading

How to reduce your CloudFormation template size

Recently, I came across a limit which I haven’t known before: CloudFormation just allows a maximum size of 51,200 bytes per template. If you have ever reached this limit, you might have encountered this error message:

So, what are the possible solutions to reduce a CloudFormation template size? In my opinion, there are two relatively easy solutions to overcome this problem: using a preprocessor and/or using AWS::Include.

Continue reading

Starter Projects For AWS Lambda Using NodeJS And Java

Today I want to show you three starter projects for AWS Lambda using CloudFormation and SAM – Serverless Application Model. I always like if I have some boilerplate code and can get started quickly without copying code or project structures from an existing (and mature) project. Therefore I thought it’s good to have them in one repository. You can find them on GitHub. The projects can be used for NodeJS and Java. Also one project contains both: usage of Java and NodeJS Lambdas in one CloudFormation template.

Continue reading