I want to go over a couple of decisions I’ve seen made, and why you should maybe consider otherwise. At the very least, this is food for thought. Whether you’ll face some of these in the future (you definitely will) or already have, I want to make the argument for why you should reconsider.
I’m mostly targeting this at pure software engineers, or CTOs at a startup who have to make technical decisions outside of software features.
1. Stick with a monolith first
If you do this, you NEED good code separation, following something like Domain Driven Design. It doesn’t need to be strictly followed, but as long as separate feature sets aren’t reaching into each other, you should generally be ok. If something needs to be shared, it can be, but then it doesn’t belong to a feature set.
Also, avoid on-prem support at all costs and stick to being a hosted SaaS company. I could go into more detail, but I hope the implications are obvious, and they will be once you think about your release process.
2. Your release comes first (CI/CD)
This is the heart of what will be the majority of your headaches if you get it wrong. One big thing I would try to do is separate your releases from your deployments, if possible. It probably isn’t practical at the start, but always keep it in mind and make that transition early. Sticking with trunk-based development and having your versions tied strictly to commits and utilizing feature flags will all save you from the hellscape of eventually needing a technical team to manage releases.
3. You don’t need more tools, work under constraint
Here are the tools you need at the start:
- Access
- CI/CD
- Monitoring
- Documentation
You don’t need more tools, and you don’t need to create workarounds for these ones either. If you do, you may be doing something wrong, or something so unique that you need to rethink your architecture.
4. You don’t have a Linux team, go serverless
To be clear, I’m not talking about Lambda or other function runners. I’m talking about something like Fargate or GCP Cloud Run. If you aren’t going to upkeep your servers (you won’t, I promise you), pay the premium and let Google or some other company handle it for you. The core lesson here is that if you don’t do something regularly, you’ll be too scared to do it when the time comes. So just don’t bother.
5. Monitoring
I’ve seen it multiple times at companies and all over the internet: people complaining that Datadog is expensive. That’s likely only the case if you’re going into microservices. Datadog’s biggest expense is going to be host monitoring for each service, and you can avoid that with Fargate’s better pricing tier, or by sticking with and scaling a monolith.
The reason I’m going to say just use Datadog is that, in my experience, it’s the best monitoring platform. Bar none. Getting users (product and the like) to use it, and having a single place everyone can go for anything involving the status of the application, makes for a significantly better user experience.
And for the engineer or DevOps person who’ll be integrating things into it, it’s easily the best developer experience too.
Closing comments
The best thing about these decisions? When you need to scale, split the team into pods and apply these principles to each pod. That way you can truly scale infinitely, and you won’t run into the problem almost every mid-sized company runs into.
More broadly, you may think it’s cheaper to roll your own monitoring or Kubernetes or whatever else, and it may be in upfront cost. But please, price in your sanity, and price in the engineering cost it takes to upkeep and upgrade it.