Infrastructure

Infrastructure is majorly ruled by Cloud. The first thing to understand before you start running your applications on the cloud is that you should be able to host your website from your local machine. You should know how to set up a simple website from Linux installed on your computer. Plus one, if you understand how to do that with Mac and Windows too. These are basics that will tell you a lot about the internet and hosting applications in general.

Cloud is just someone else’s computer. Please understand the basics. No matter how much I stress this, someone is still going to get an AWS Associate Architect certificate and be completely clueless about how to convert a computer into a server that securely hosts an API to serve/receive data.

Scaling is easy with cloud but it comes with a cost. If you are in a small company making a consumer app and it becomes a hit by a burst of users and you didn’t have monetization in place. You could be out of business if you were using managed vertical scaling solutions. Cloud price estimation is hard because of how pricing works in cloud providers. For heavier workloads be very careful even during testing.

Usually, in the ideation phase, you scale by adding more juice. You do not spend time over-optimizing queries, indexes, and algorithms. That falls under premature optimization and most of the time, you will re-write most of your queries and logic. Doing it early on would slow you down. At the start costs are minimal and scaling by adding more power is cheaper. If you are on the cloud, it’s easy to scale up and down when necessary. Keep stack simple and do not go for services that scale indefinitely. In the case of the cloud, find something that will crash if there is a sudden unexpected burst of usage during testing or production.

If you expect a burst in usage, then you better know what you are getting into. Burst usages are best handled in cloud instead of on-prem machines or some VPS from hosting services. If you are launching your app as a startup, be prepared for the number of users you expect through the platforms you launch on. Plan ahead or launch could become a mega failure. This has happened with big organizations but they can sustain it. Have good monetization or funding in place so that even if you have to scale servers you won't go bust.

At a certain scale and/or when you have consistent usage, one option is to consider switching away from the cloud to some VPS. It can save a good deal of money. It won’t be feasible if you have built your entire architecture as cloud-native. Now you know, why cloud companies are hell-bent on promoting cloud-native architectures. In most organizations, switching away from cloud won’t happen because the industry is still high on it.

At a medium scale, you should start optimizing some of your code and usage as well. That will give you the best bang for your buck instead of increasing the number of instances. I have seen in many VC-funded companies that this is not the case. Since the money does not comes from the founder’s pockets and they need to show good KPIs fast, optimization is considered a slow way of improving things. In such a company, always put an option to optimize but don’t pull your hair out if no one seems bothered. Protecting your own sanity as a software engineer is important if you want to play the long game.

If your company or CEO is comfortable being a steadily growing profitable company, they will be all in for optimizing workflows to reduce costs. Do not for managed scaling services. Handle scaling yourself. Control scale-up and down rules with load balancers. Instead of using serverless AWS RDS Aurora, use a machine that you know the capacity off. Upgrading a machine in RDS is trivial. Managed scaling infra won’t complain or show any sign of bad code. If you manage scaling yourself you might detect that a sudden burst in usage could be an issue in code. Going back and fixing code would save costs instead of letting the compute scale indefinitely. Moreover, managed serverless services cost more than their non-managed counterparts when running the same load.

All the big corporates should have their own data centers. Cloud is just a rip-off^2 for them and you shouldn’t host your data in someone else’s system. Make your own cloud if you are too inclined. Cloud providers have strict rules on what you can host on their cloud. If one day they decide that your company is going against their terms of use they can shut you down. It’s as risky as developing a giant tech business on someone else’s platform. You could be held hostage or shunned and put out of business.

I have a small website that lets people crop images. I get reports from AWS that it is a Dropbox phishing site and it’s not acceptable use of AWS’ services. I keep telling them that it’s not the case by any stretch of the imagination. Imagine that you build a business that is quite similar to Dropbox but not a phishing site. If you are not able to convince them they can shut you down and not listen to you. This has become more normal than you can imagine and it’s only going to get worse. Google bans accounts, Twitter bans people, PayPal can snatch $2500 from your balance if they want to. Too much reliance on someone else’s platform is dangerous. Knowing it as a business owner is far more important than as a software engineer. I am sharing because some of the readers now would know what they subscribe for when they do.

A lot of points I mentioned don’t hurt engineers much. It is good for the developer economy. Nonetheless, these points are going to help in the long term to make a big and clear picture of what we do. There is a possibility that cloud’s bubble bursts and a cloud burst happen.

I have a good amount of hands-on experience with AWS. I will share a bit about that. Do not use AWS’s bleeding edge or the latest managed services. Keep your options open and opt for services that you can easily find alternatives in other clouds and also outside the cloud. Not because you will have to do it but because the core tech is solid.

Some managed services might look like they are the silver bullet. They are not. You will likely get stuck because of some bug in their service or a lack of feature in which case you would either do nasty workarounds or costly migrations. When AWS Lambda came out it had many issues, especially around the cold start. Serverless was all the hype and I remember people started using AWS Lambdas to host entire consumer-facing apps and they were quite often surprised by lambdas’ quirks. AWS Cognito had innumerable critical bugs back in the days. Another time, we used AWS AppSync, and when knee deep we found out that subscriptions can’t work on the local machine amongst other problems. DX was a nightmare. We switched to the good old Apollo Server.

While selecting a technology, remember Lindy’s law. It’s hard to go wrong with it.

This post is from a series of related posts about software engineering. It is part of an attempt to write a book in public. I seek your feedback. Raise your opinion. Share with people who can benefit from it. Contribute in the comments section, on social media, over a cup of coffee, or however you prefer. This will help me and the community tremendously.