Serverless systems aren’t software systems
If you don’t understand why this is, then you’re doing serverless wrong.
The reason is that serverless systems are built on a foundation of building tiny and highly or completely decoupled systems within a much wider system.
Software systems and software engineering is predicated on interaction and interoperability.
The prevailing understanding of how to manage software development is also predicated on the idea that the solution that is created is by one team, is also interacting and interoperable with that of another team (coupled, not decoupled).
The problem is that if you have this mindset, then your understanding of testing, deployment and a range of other things within the development process are misaligned.
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.
Yes, that’s “software” in the general sense.
But that’s not “software” in the sense that most developers or managers think about it.
What are serverless systems if not (traditional) software systems then?
Serverless systems then are a highly decoupled, event-driven, distributed system, with small, highly independent pieces of software that rarely need to know about any other pieces of software.
When you think about the system like that, then the way you structure your teams and the way you develop the software is not the same as if you are developing a backend for a website on a server (even if you’re developing a serverless backend for a website).
One of the biggest differences, imho, between a normal software (or server based software) project and serverless is testing.
The high decoupling element within a serverless system means that you don’t have the same requirement to test across teams.
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).
The serverless processes
So, the development process becomes about building a lot of small and decoupled elements, and testing them.
The wider management process becomes about understanding how those small and decoupled elements fit together.
The initial design work becomes about designing the data flow for the entire system so that you can ensure that elements are right sized and designing your data layer around it.
If you design it right, you can significantly limit your testing, because your system can generate really clear error messages.
If you manage it right, your teams can deliver small pieces that fit into the wider system without recourse to any other teams.
And if you get your software development within the teams right, your testing should be clear enough to catch a large number of errors (in a small system) before you push anything into production.
And once in production, each element is independent, so it is easy to update each element without harming the overall system, and when a bug occurs, it is easy much faster to fix.
The title “Serverless systems aren’t software systems” is intended to get you to read the content.
Because of course serverless systems rely on software, and underneath it, they are software.
But in reality, serverless systems are not software systems that the vast majority of software developers, software managers and software professionals are used to and comfortable working with.
The issues around building serverless systems are not insurmountable. Most developers and managers get there in the end. But it is not a straight forward journey to get there, and can have some big bumps in the road.
And this is the problem.
If you treat a serverless system like “just another software system” or “it’s just like X we’ve done before” then you may well have issues delivering against it.
There are a few people who grasp how to deliver these systems very fast, and often they come from an enterprise, and a banking background (in my experience), and not a startup background.
The management of building a serverless solution does appear to need either different skills, or the need to adjust your understanding of how to deliver a solution.
Learn and adjust before going serverless
The reason my title says what it says is simply to say that 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.
Learn your tools.
Learn why they exist.
Learn how they can best be used.
Adjust accordingly.
Building serverless solutions can be amazing.
Building serverless solutions can also be really hard, and sometimes an experienced person (like me) can seem like they are telling experienced professionals that they don’t know what they are doing.
Building serverless solutions is a new skill.
Stop treating it like an old one.
There are some transferrable elements, and some transferrable skills.
But if you are determined to do it your own way, and it doesn’t quite work, then don’t blame “serverless”.
[This blog was created from this original tweet thread]
