A couple 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 writing, you know I am an active member in 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 risk associated with adopting a 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.

But as you get closer to the dev team, you get more detail and nuance.

The next level is conformance governance. Standardizing on how things are done. This contains more detail than the level above it. This tier of governance might suggest things like "use REST APIs secured by OAuth2.0". This level is generally determined at a department or development group level.

The final level is detailed governance. This is the fine-grained detail that determines how your apps are built. You might see governance rules like "never use an asterisk in an IAM permission". This level of governance is determined by individual dev teams.

Governance comes from within.

The three tiers of governance should come from within your company. Don't expect somebody else to make it up for you. These are specific details that pertain to your company and your individual development team.

Driving laws are the same way. You have the broad-stroke governance laws at the federal level. These are very high level and generally define safety standards and regulations.

You then have conformance governance at the state level. Things like speed limits and insurance minimums.

Finally, you have detailed governance at the county/local level. These include details about fines and fees if you were to get a traffic ticket.

Traffic laws vary wherever you go. Some places even drive on the opposite side of the car!

The point here is that there is no "one size fits all" approach to governance or serverless for that matter. You must find what works for you and your team.

Types of Governance

When I first got involved with governance, it felt like it was just a bunch of "no, no, no". It appeared to be rules to keep the dev teams in their lanes and keep them from doing anything crazy.

Governance is there to help you

While it might feel like governance is restricting, its sole purpose is to help you. It provides mechanisms to make code familiar and consistent, so if you switch teams you can pick up quickly and focus on gaining domain knowledge rather than learning all new patterns and workflows.

There are many different types of governance, but some of the most common you'll find (and need when you start with serverless) are:

• Best Practices - A set of patterns or style guides that provide conformity to all code being written. This provides a unified experience and consistent outcomes. These are considered official recommendations that allow exception use cases.

  • Example - All GET endpoints that return lists should return a 200 status code and an items array with the result

• Standards - Definitive guidelines for how operations should be done. Slightly different than best practices in that these are more than recommendations. These are the preferred approach to solving a problem.

  • Example - All endpoints must be routed through a custom domain for legibility and discoverability

• Mandates - Rules that must be followed when building software. There is no flexibility when it comes to bending the rules.

  • Example - Authentication must use XYZ provider to provide SSO

Each one of the above have their own weight to them. Meaning they range from generic guidelines to must-do efforts. Providing a range of governance rules ensures the people consuming them don't feel strangled with restrictions.

Serverless Lookahead

You might be asking yourself "how is any of this specific to serverless?"

Good question. It's not.

Serverless doesn't have any unique problems compared to other new technologies (with a few exceptions). But the worry that crops up in people adopting serverless is the lack of best practices and standards from the community. Since it's so early in the serverless space, there are no defined standards.

People have a bad time when their expectations that this new technology has the foundation of something that's been around for decades. Define your own standards. Give back to the community.

There is so much work being done in the serverless space right now. Hundreds, if not thousands of blog posts, videos, and white papers are being published every week showcasing the community's work.

Take what people are doing and adopt it. Share your adoptions, help contribute to these standards. There is no official serverless authority. What we see being developed as best practices are being contributed by people just like you and me.

So don't hold your breath waiting for someone to define your governance rules for you. That will be a while. But do take the time to establish governance rules on your own. See what the community is doing and modify them as necessary. Do what works best for you and your peers.

Conclusion

There are many types of governance you should implement from the beginning of your serverless journey. Allow some time to build expertise and use those experiences to drive your models.

Put guidelines in place to build consistent software. Focus on providing a range of rules from mandates to general suggestions. Leave no stone unturned - every detail helps. From security, to repository and microservice structure, to service usage guidelines, the list goes on and on and every minute detail is important.

Building, establishing, and maintaining governance will be your key to success when adopting serverless (or any new tech stack). Remember, governance is there to help, not hinder. If the impression your team is getting is that the governance is too much of a hindrance, it might be time to re-assess.

Happy coding!