After working on several cloud migration projects, I have noticed a pattern. While the cloud is often sold on the promise of innovation, the reality for developers is more about automation and, most importantly for business, managing costs. From my perspective, it is easy to get pulled in by the marketing and end up with a solution that is more complex and expensive than it needs to be.
One thing I have seen is how cloud providers can heavily influence a project’s architecture. For example, if you are building a simple web application on AWS, the “standard” path often leads you to API Gateway, Lambda functions, and DynamoDB. While these services are powerful, this approach can lock you into a specific vendor’s ecosystem from day one. A simple web application should be simple, regardless of the programming language, and should not require a deep commitment to one provider’s proprietary services. The focus should be on solving the problem, not adopting a specific set of tools that might not be the best fit and at the end it can be much more expensive.
I have also learned to be skeptical of the performance and scalability claims made by cloud providers. Often, these impressive numbers come from case studies of their biggest customers with massive scale and very specific needs. In many of these claims, the information about costs is usually hidden.
Your use case is likely very different, and you might not see the same benefits. That is why it is so important to ignore the hype, start with a simple and clean setup, and always keep a close eye on your costs. The best strategy is to build what you need now and only add complexity when it is truly necessary.