Serverless Architecture is a thing that is pretty much the culmination of the containerisation of our code. It takes the process right down to the level of individual functions instead of needing to worry about servers.
And there is a problem with that (I’m not going to lie!). The problem lies around the shared resources and the testing of the solutions we use Serverless for.
Deployment of new code is relatively straight forward, and because it’s a self-contained function, then you only need to test that function right?
Well… only if that function doesn’t interact and change a shared resource.
And if it does, well then you have to check that every function connected with that shared resource is not broken due to the update to a single function.
So, while the micro-functionality is hugely helpful, it’s also hugely frustrating at times, when something changes and it affects another part of the system.
The advantage of a framework and a single codebase containing multiple functions is that you can test and check them as a whole.
The disadvantage is that you have to change everything and check everything to make a change.
We currently only have a few patterns at play in the Serverless world. We need to start to consider what the appropriate way of doing devops and QAT is within the wider context of Serverless. At present, we’re all looking at the shiny micro-functions and being all happy.
I’ve encountered issues with Serverless, that mean that reworking of things is a necessity. This is a pain, but because we’re working with micro-functions that is actually easier than with a framework. It’s a shorter timespan to redevelop and you generally have to change less code.
However, the testing of the reworked and refactored code is generally a lot harder (although not necessarily more time consuming). You have to test in isolation and then do some sort of functional test across the system, and then identify any potential issues.
To cap it all, current serverless solutions often don’t provide a testable local version or even a testable remote version. Imagine a third party API that you use giving you access to a local version of that API purely for testing? Some do, but there is definite secret sauce that they don’t want you to see, which means that only way to do it is to provide a test and a live account. Not all do though and this can cause issues. Even organisations like AWS can change their schemas and break things without it being obvious where the problem lies.
Serverless needs some new patterns
We can’t do things the same way as the “full system” patterns now. It’s actually quite complex to do this within Serverless, and while it is possible, maintaining multiple versions of third party services and ensuring that we’re not using the wrong ones at the wrong time is not simple.
We’ve got a great opportunity to do something right here. If we do that we’ll be doing a great service to the tech community and the future of the world (I truly believe that). Serverless really can provide a major opportunity to the world.
If you try to use the same procedures as the full stack solutions of yesteryear, then you can easily end up with all of your functions in a .jar file and that is what is pulled into your Serverless setup for each function. It ends up not being what it’s supposed to be and taking up unnecessary compute resource when Serverless is all about minimising compute and maximising efficiency.
We have to be careful not to copy the wrong patterns from the old days just because that’s the way we’ve always done it.
The new patterns are there somewhere. We’ve just go to find them.