Cost of running online service
When people compare things like on-prem vs cloud or vps vs serverless they tend to compare just the initial cost and the running cost. Very few people I've met are fully aware of things like maintenance cost, hardware deprecation, flexibility, scaling and all the hidden costs which you only find out after a few months/years of running your service online.
Each solution has it's fit, you just need to know the distinction. For me it goes like this:
On-premise solution
If you don't have problem with larger initial investments, you need full control over your hardware because of fine-tuning algorighms and/or you are highly-regulated you should probably go with on-premise solution. If you chose this don't forget that the initial investments won't go just to hardware, but also into building the server room, securing the server room (you probably already have something in place if you are regulated), on setting up the network and server operating system and services. You will probably need to hire special guy which will maintain your servers and network and monitoring (or maybe two guys). Also don't forget that if you will need to scale you will need to buy new hardware, set it up, connect it to the existing network etc. You will be responsible for SLA (Service Level Agreement) and uptime if you have any customers. If your business is crucial you should probably also build multiple server rooms in the case one is on fire so your business can continue - ideally at least in different city. Also be prepared to exchange your servers and network hardware from time to time - either because you need more compute or because of various failures. To be honest this does not sound like fun at all and doesn't even sound that cheap.
Cloud computing and VPS
If on the other hand you don't have large initial investment ready but you still want to start your project you can try cloud computing and VPS. This means that cloud provider is responsible for the hardware you need. You are still responsible for managing the software like operating system and security updates but at least when you need more hardware you can lease it from cloud provider. Each good cloud provider will probably have some automated hardware failover. Also each good cloud provider should be able to provide you with reliability and high availability. You will most likely be able to run your service from one availabilty zone and have a standby replica in another availability zone or even region. These things cost you extra money but at least you don't need to manage them yourself. Some of the businesses cannot host any of their services in the cloud because of the high regulations but nowadays there are options for such businesses as well. Here I am talking more about small and mid-size businesses which shouldn't have problems with running services in cloud where everything is encrypted at rest and in transit. There are also options like VPC (virtual private cloud) which ensures your data won't get to the internet but stays in private networks. You can even connect to the private network from your on-premise network securely through VPNs or other means.
People in this category realized that cloud is not that bad. It could be cheaper to pay cloud provider for the hardware maintenance but it seems that general consensus is that you will still need a special guy which is called DevOps because someone needs to manage all your Kubernetes clusters, right? Well, this is mostly true when you migrated to the cloud or started using it still without full utilization of all the services it provides.
Kubernetes is great if you need multi-cloud - if you are highly regulated business and you need to ensure you can continue running your critical business infrastructure even if entier cloud provider goes down. Fortunatelly it is always just critical infrastructure which needs to run all the time. So you can have small portion of your business deployed to multi-cloud (even if multi-region is most of the time sufficient) and anything else you can simply degrade when there is some cloud provider level outage. This is something which too few people realize. And I am not arguing with worldwide financial and healthcare institutions here - I am still talking about small to mid-size companies.
When you think that Kubernetes is the solution which you definitelly need and you are OK with paying extra special guy just for the DevOps. Also you are OK with developers not to care about how their workloads runs (usually DevOps and developer people don't communicate on daily base - the consensus can be achieved but it is rather an exception than a rule) then go for it. At least please be honest with yourself and forget about multi-cloud architecture - you most likely don't need it.
If you are afraid to stick stick with one provider because of the pricing or because of some new feature the other providers could introduce you can be calm as every provider adjust their pricing and introduces new services according to what other providers introduce.
Stick with one provider and try to learn how to leverage their native services so your cost can go down - don't just do lift & shift, you always should use cloud native services.
Cloud computing and Serverless
In the previous section I was defending the leveraging of cloud native services. Serverless technologies are as cloud native as it gets.
When you want to be able to scale quickly and reliable you should seriously consider using serverless technologies.
There is no cost in managing, you don't need special person to run or deploy your service. There is nothing special your developers cannot learn about developing and running serverless workloads in the cloud.
There is no initial investment for hardware or infrastructure. You just pay for what you use. It have a catch though. Serverless is easy to scale so it is very easy for someone who don't fully understand it to create huge bill. This is something which you need to guard from now on. You will need educated employees. With AWS you still can set up various guardrails so your bill won't inflate because of some silly error.
So the catch is that even if you won't need initial investment for hardware and infrastructure you will need to invest in your employees. As it should always be. You will need to allow them to learn either throuh AWS certification or through trial and error - both are great but the managed trial and error alongside with certification is the best.
You might still hire some specialist to help you with the initial setup and maybe even to educate your developers but this is not recurring cost. You can start very lean and then continue when you employ more people. You can set up the learning system for old and new employees so everything takes care of itself.
Whenever you feel like the serverless services are not sufficient for you and you need something else you can combine it with any other services from AWS. So you are not stick with AWS Lambda and AWS DynamoDB. You can use any other relational database - the only difference will be the cost and availability.
Conclusion
As I stated at the start of this article each approach has its own pros and cons and each approach is suitable for different situation.
If you are interested in serverless and want to know more about implementing it whithin your company drop me a line at ivan@barlog.sk - I will be more than happy to help you in any way.