Deploying and running services on Function-as-a-Service (FaaS) compute platforms like AWS Lambda has some compelling benefits for appropriate use-cases (short running workloads), including true (low-latency) elastic scalability, at finer granularity, with significant cost-savings based on scaling to zero.
At the same time, the Spring application framework (and more recently Spring Boot) has long encouraged and helped accelerate building modern, flexible enterprise apps that run on the JVM, that are easy to test, by abstracting away generic code (‘plumbing’) for integrating an app with its libraries and APIs; using familiar design/programming patterns (IoC/DI, proxies, Template methods etc); and providing valuable features (declarative transaction management, environment specific config, etc).
In an ideal world we’d use all these technologies – building Java/JVM functions with the help of Spring that are deployed and run on AWS Lambda – to realise their combined benefits.
But can these technologies be made to work together effectively? Or do we need to accept that when it comes to designing and building services to run on FaaS platforms like AWS Lambda, tech stacks (programming languages and application framework) offer than Java and Spring may offer a better solution?
Message brokers are specialised pieces of enterprise middleware designed to support integrating applications in a decoupled (in both time and location) manner, using messaging channels, implemented as either queues (for single consumer) or topics (for multiple consumers). Whilst deploying and operating a broker has an additional, ongoing cost for a business, if the scale of integration in your system and the non-functional requirements warrant it, they can can provide a flexible, better performing and more scalable solution than the alternative of implementing message queues in your database, especially, as is often the case, the latter is already overloaded.There are a considerable number of proven message brokers available today from a variety of vendors. Before committing to building your integrations on a particular broker, you should give careful consideration to how well it satisfies your requirements. I recently went through such an evaluation exercise, and ended-up choosing Amazon Simple Queue Service (SQS). While we haven’t regretted this decision, I did learn a few things along the way. In this post I’ll share a list of the functional and non-functional (technical) requirements that you should consider as part of evaluating a message broker, and also my opinion on how SQS measures up to other brokers in each case, and the trade-offs.
When building a message consumer you need to handle the various errors that will inevitably occur during message processing. If you’re using Amazon SQS as your message broker it provides some built-in support for error handling that you can utilise. But, if you want to handle all types of errors efficiently you should also add your own custom error handler. This post explains how you can do both these things, including how to classify message processing errors.
My team and I design and build a lot of REST APIs during the course of our work, to expose functionality and data to client systems, and to integrate our back-end services with one another. I was therefore interested in learning more about Amazon’s recently launched API Gateway service. This is a short post summarising the role and major features of Amazon API Gateway based on my own preliminary research and trialling. I also briefly cover what the service is not designed to support, and consider possible future use-cases.