Is Serverless Making Infrastructure More Complex?

Or have we only just started to care about infrastructure in the first place?

Big AWS diagrams are sometimes used to prove the alleged complexity of the average serverless application.

But here’s the thing: very rarely were such diagrams even seen in the pre-serverless days. It just wasn’t done.

I’m not saying that they didn’t exist.

But they weren’t as freely circulated within a company. Some lofty old school architect might have had a few diagrams in his office, but developers and most everyone else would have been kept away from them.

These old school diagrams would have been far too complex but also completely irrelevant to the developers. No one in the team could have possibly hoped to understand how the whole thing operated. And so, developers were happy to write their code, while the Ops team remained firmly in charge of servers, caches, and databases, etc. Everyone safe in their little silo.

That’s no longer true with serverless.

This is one of the biggest achievements of serverless: everyone can understand how the whole thing operates and (given reasonable guardrails) everyone can own every part of the application, including security and infrastructure.

Because of this dramatic simplification, the promise of true DevOps (that is, having the same developers building the application and handling infrastructure) finally has a chance of being fulfilled.

This results in an increase in the team’s agility and ability to deliver value rapidly.

Free from depending on a separate Ops team, waiting for infrastructure to be built and deployed. Free from being unable to understand how the whole system hangs together.

Serverless puts the developers back in charge.