Lessons for setting up Cloud Services for startups and new digital businesses
Happy Tuesday, everyone! :)
I will be following mostly on an inspiration first come first serve basis for the posts here but keen to hear any feedback and topic suggestions! Just DM me and I’d be happy to hear it also if you want to write something together! Happy to say this one was kindly reviewed by one of the best software engineers I had the pleasure to working with Lucca Leme Marques! Thanks for the expert advice!!
Today’s post is inspired by the #AWSSummit I attended here in London a few weeks ago. Big events have always A LOT of noise, so much going on, but I’m figuring out that if you are intentional into what you want to get out of the event — be it knowledge in a specific topic, talking to an expert, getting to know a few companies or sharing content yourself, it is always much more rewarding.
Besides the AI prompt engineering session I attended which I commented briefly on a past post that pretty much remembered us about the basics and that AI models can be way more powerful if we have clear definitions of content, format and context on the tasks we ask it to do, there was another very helpful session, which is the topic for today’s post: AWS/Cloud setup MUST DOs for startups.
Although the talk was of course focused on #AWS features and the experience I will be sharing is also from having worked with AWS for a few years now, I would say these are pretty much transferrable for most of the other cloud providers, which of course one would choose based on a bunch of factors such as capacity needs, cost optimisation, and other specific features. Without getting into this discussion, which touches many technical aspects that software engineer leaders would be more qualified to recommend, the advice below is digestible for #businessleaders, #founders and #productleaders and focuses on general things one should not disregard when setting this up for the first time:
1. Set up cloud and server budgets, this will help you keep a cost-focused mindset on this while not trying to save when you don’t have to and risk compromising performance;
2. Leverage business support — these tools have dedicated support teams for different levels of urgency, from production issues to minor disruptions and reaching out to them rather than getting your team to troubleshoot for many hours can come very handy;
3. Make sure you use whatever tools they have to manage permissions, user roles and make sure each developer has permissions based on their role. Also on this topic, make sure to setup MFA and separate your Root Account/Company account from any specific users. The worst thing you don’t want to have to handle, trust me I’ve been there, is to have a production issue when the cloud account, MFA and permission are all set up in an account of someone who is on leave or not in the office. This happens specially when product teams are growing fast so having these rules from the beginning removes another thing from your list of things to worry about. I was made aware by Lucca how this is actually the Principle of Least Privilege, which you can see more info about here: https://www.paloaltonetworks.com/cyberpedia/what-is-the-principle-of-least-privilege.
4. Consider if it’s better to build or buy different libraries and systems. This is another thing that probably will be better answered by your developers’ team but always know how to question the time vs cost vs effort in building these or focusing the attention of your tech team on your core product. My advice from past experience is that anything that touches your core product and you need flexibility on is usually best built in-house — as long as you have the resources to do so (team, money and time).
5. Use IaC — Infrastructure as code — this is another topic where the experts will have way more specific advice than me. However, I can attest to the importance of having automated and well structured deploy and pipeline processes to make sure the releases routines are standard among different developers, especially in big teams, and to allow flexibility to deploy hotfixes and rollbacks if possible, besides the normal release process.
6. Don’t leave unused resources running — EC2 spot instances + Serverless technologies. This is a very wise point to make that was amazingly explained at the day and of course you should optimise your resources and have a clear quantification of expected traffic and capabilities to know exactly what this is. That being said, my experience has shown me in real cases that you can never have enough resources, especially when your website and app needs to be ready for bigger than usual volumes of traffic. I used to work in projects where we had so many redundancies that might look like an extra cost at first sight but that made all the difference when you have big marketing campaigns, big seasonal events that impact you and your competitors with demand — being the one with a reliable, fast and seamless experience to the user can pay off big time when it comes to this. So, of course know your averages and expected demand but do work with a margin as big as the business opportunity you would have in a case like this.
7. Use Content Delivery Network — CDNs to make sure you have a reliable website using the best of a global network to increase availability and speed in many different regions.
8. Don’t store everything in a relational database. Having worked in a company which had mostly relational databases for everything I worked with as a data associate and product managers, I can truly appreciate how helpful it is to connect data from paid media campaigns to user behaviour data to serverside and offline conversions and events tracking. It is very useful for connecting the dots in your product, creating optimised data funnel visions and having a holistic data structure that will guide decision making very wisely. However, I must admit that for some information this might not be the simplest way to store information, so I guess the key takeaway for me here is always ask your team and discuss together what are you using the data for and how do you plan to integrate this in the future. Then assess together what type of database you need to avoid having an architecture more complicated than needed.
Although this is not a technical post, I believe it is a very important one so that technical decisions can be made while also taking into account business objectives, forecast of growth and roadmap planning — as it is very important for these things to be working together, especially if technology is at the core of your company and product!
As always, I would love to have feedback and additional input on these topics!
