Serverless keeps growing in importance, but according to some experts, it requires a different way of architecting and testing systems.
By some measures, over half of enterprises have embraced serverless. If you’re on the “not yet” side of that equation, Prefect’s lead community engineer Anna Geller has offered multiple ways that serverless computing not only helps enterprises build more effectively, but also encourages developers to code more productively.
And yet, as Serverless Days co-founder Paul Johnston has outlined, many developers approach serverless wrong, and get tripped up in the process.
As he noted: “If you treat a serverless system as a software system, and try to build it that way, you are far more likely to struggle than you are to get the best outcome.”
But what does he mean, and how can developers avoid this trap?
SEE: AWS Lambda, a serverless computing framework: A cheat sheet (free PDF) (TechRepublic)
Why go serverless?
One of the best things about serverless, according to Geller, is that it encourages useful engineering practices. For example, if we can agree that “it’s beneficial to build individual software components in such a way that they are responsible for only one thing,” then serverless helps because it “encourages code that is easy to change and stateless.”
Additionally, she went on, serverless all but forces a developer to build reproducible code.
“Serverless doesn’t only force you to make your components small, but it also requires that you define all resources needed for the execution of your function or container,” Geller said.
By requiring such self-contained services, serverless encourages developers to worry about “choreography over orchestration, with each component playing a more architecturally aware role,” as Symphonia’s Mike Roberts has posited.
This idea of event-driven architecture is powerful but also where many developers go off the rails.
Building with choreography in mind
“Serverless systems should be (but rarely are) thought of as a large number of decoupled but very small systems, that are completely independent of each other, connected by events,” noted Johnston.
Well, that’s just how software works, right?
“Yes,” he added, “that’s ‘software’ in the general sense. But that’s not ‘software’ in the sense that most developers or managers think about it.”
Some of this dissonance between serverless and software systems thinking comes down to security – serverless requires a developer to entrust some security concerns to the underlying cloud provider – and a general loss of control because, again, even though the developer gets to focus on their application logic, the cloud provider is still managing servers on their behalf. But it’s really in the area of testing that the necessary difference in approach is exposed.
“The high decoupling element within a serverless system means that you don’t have the same requirement to test across teams,” Johnston stressed. “Each single element needs testing (this doesn’t change) but because each element is decoupled (or should be) and is small (or should be) then there should be near zero coupling between teams and between elements. If there is near zero coupling between teams and elements of a system, then… you just have to test the elements (except where there is coupling where you have to test).”
Unit testing remains relatively straightforward, but integration testing becomes harder and even more important.
“Part of the reason that considering integration tests is a big deal is that our units of integration with Serverless FaaS are a lot smaller than with other architectures,” Roberts wrote. “We rely on integration testing a lot more than we may with other architectural styles.”
This is complicated by the need to rely on the clouds for such testing, which can be an uncomfortable jump.
“Relying on cloud-based testing environments rather than running everything locally on my laptop has been quite a shock to me,” Roberts said.
And then there’s the approach to architecture (and testing) that differs.
“So, the development process [in the serverless world] becomes about building a lot of small and decoupled elements, and testing them,” Johnston said. “The wider management process becomes about understanding how those small and decoupled elements fit together.”
Choreography, not orchestration, in other words.
An insurmountable shift in thinking? Hardly. But it is different, and as Johnston, Roberts and others argue, figuring out those differences and building accordingly is key to getting serverless right.
Disclosure: I work for MongoDB but the views expressed herein are mine.