Member-only story
Going Serverless? Governance Is Everything
When deciding to go serverless, you need to put up some guardrails to protect yourself. If you don’t, you might find yourself in a hole you can’t get out of
A couple of weeks ago, an article started floating around called “After 5 years, I’m out of the serverless compute cult”. It is a bit….polarizing, to say the least.
If you follow my newsletter, you know I am an active member of the serverless “cult”.
The article makes a list of arguments about how serverless leads to bad practices in a variety of ways.
As I was reading it, a central theme came up in every one of his points that really could have addressed all of it.
Governance.
Governance is a set of rules and guidelines that dev teams should follow when building their applications. If we follow the guidelines put in place by the architects and dev leaders, we mitigate some of the risks associated with adopting new technology.
Anyone in the serverless space will tell you it feels like the wild west at times. But that’s not unique to serverless. It’s just new. It needs time to shake out best practices. We need to figure out what it can do.
To best describe architectural governance, we’re going to use an analogy to relate it to cars. Imagine when the Model T was first invented. In 1908, it was the first vehicle to be mass-produced, enabling thousands of motorists to hop in the driver’s seat.
There was a lot to be discovered and ironed out in the early days. The first drunk driving laws didn’t appear until 1910. The first traffic light wasn’t invented until 1930. Heck, the first seatbelt wasn’t developed until 1950!
It takes time to discover how something is used. That’s the way it was for cars, it’s the same way for serverless.
Governance Levels
As with most things, governance comes at different levels. At the highest level, we have broad-stroke governance. Things like “always practice principle of least privilege.” Governance at this level is determined by senior leaders.
