Cloud Native App Development

Cloud native app development is a pain. Potentially rewarding, but a pain. At least, if you're looking at an application which wasn't written with the cloud in mind. And, I suspect a good number of people come at this the same way I did. Which is to say; while I looked into documentation, training and tutorials sooner or later you need to bite the bullet and do something practical. And that usually involves looking at an existing project.

The thing is, anything but a pure "born in the cloud" implementation will cost you dearly or come with significant drawbacks.

I know that there are benefits. Someone else manages the infrastructure and the data is often replicated. But, the cost does not match the value for a smaller development team.

Take for instance my example. I have an application with 2 services, a front end and a SQL database. One of the services basically just does data duplication for me, so I can cut that one out if I'm hosting it somewhere with built in data replication. Both the front end and back end are containerized apps. So, I have access to some cheaper options in the form container apps. So far, so good. Now, that pesky SQL database? Well, that bad boy is about 2-3 orders of magnitudes of cost more to run than everything else, and that is for a pretty weak solution. It gets DRASTICALLY more expensive to get up to a tier of service which provides an adequate solution. Bear in mind, this application has about 5 users total with a peak load of 2 active users handling maybe 10 transactions an hour.

This is smaller than small. And, I was only this close because I got lucky and already happen to know Docker quite well and had rebuilt my app explicitly such that containerization was an option. Without that, I may have needed to spin up a VM. And that might have ended up being just as bad as the SQL costs.

Now, while I am griping, I do understand. SQL wasn't designed for the cloud originally and getting the kind of performance I'm expecting (something better than 5-10s for the server to spin up again after a brief period of inactivity)  requires dedicated provisioned hardware. Reserving hardware even when I'm not using it. So, I TOTALLY get why it is more expensive. That being said, there is no option which is all of SQL, in Azure and reasonably priced for people in my situation.

The $16/month CAD it costs for the cheapest vCPU DTU based pricing is the closest thing I could accept for this use case. But, it suffers from the cold start issues I saw with the Serverless options. Going up to anything provisioned instantly jumps up in price into the realm of hundreds of dollars a month. 

Also, I will point out that the free credits and 12 months of extra free services go along way to allow you to struggle through this and discover the bitter truth for yourself. And while that sounds like a scathing indictment, that isn't how I mean it. It really is pretty amazing.

If I were to rewrite the application (and I may just do that), I might keep the front end running locally. This would keep the larger of the 2 containers out of the registry which would be a plus. Also, the front end can fail. I don't care as much about that piece of the equation. 

Next, I would move my data to Cosmos DB. This is a database build with the cloud in mind and it doesn't suffer the same way SQL does (from what I've read at least). It also has some number of free transactions and for my load would cost pennies a month even without freebies.

Lastly, I would do away with the server piece and rewrite it as an Azure Functions App. Now I lose all costs associated with my container registry. While not expensive, it is certainly nice to eliminate un-necessary storage costs. And similar to CosmosDB I get pay by the second billing for a service meant to serve cloud native apps, and any potential costs go down accordingly.

So yeah, cloud native app development is pretty awesome. But there are some pretty huge caveats for existing applications.