When a major company shares a case study about saving $1 million annually by moving from AWS cloud to an On-Premises setup, it always grabs the attention of the DevOps community.

It sparks the years-old debates about cloud-native vs. on-premises and Serverless vs. serverfull.

E.g. using on-demand Lambdas and DynamoDB VS always-on Docker containers and PostgreSQL/MySQL, deployed to Kubernetes.

Now, it’s easy to jump on the hype train of the next article that suits your ideology better.

• Maybe you have a longer engineering background of developing traditional applications using containers, monolithic applications, and SQL databases — you might be more biased and inclined to support such a Cloud to On-Premises migration.
• But if you are coming from the Serverless world, and you prefer the simplicity of NOT managing servers and predictable pricing (pricing that goes hand in hand with usage) — you might be a bit more supportive of the Cloud-native infrastructure. And there’s no right or wrong answer. It’s just engineering perspectives.

A common problem, especially for large organizations, is that such decisions are usually based on this — engineering perspectives, rather than business use cases.

E.g. can the app benefit from the flexible scalability and predictable pricing of being cloud-native? Maybe you should pick that option then. Does it need to be on 24/7 and can’t tolerate cold starts? Maybe an always-on server is the better option here.

And remember — the grass is always greener on the other side. But once you step into the weeds — you quickly realize — that serverless and serverful are both far from perfect options, same as cloud-native and on-premises.

In an ideal world, you would combine the strengths of both sides. So the next time you are thinking of architecture for your app — think about how you can leverage both.