Hey great post! Thanks for sharing so many details. Just one question: how do you approach profiling in production? Specifically in those cases where copying whatever slice of data from the prod DB would be too much to handle.
The architecture behind a one-person tech startup
211–220 of 334 posts
Re: The architecture behind a one-person tech startup
#212Re: The architecture behind a one-person tech startup
#213Re: The architecture behind a one-person tech startup
#214Earlier quoted context omitted.
Document everything in excruciating detail - I go so far as to record all the commands I run; and when complete o destroy the machine and start again (or use a separate system) and verify that I accurately recorded every step. You can add additional text about why you did certain things - and then store the data in a wiki or checked into git or similar so you can find it when you need it.
That's all great advice. What I find though is I don't do it enough for it not to change under me. Example: 1. Did a project on digital ocean, just ubuntu and node 2. Year later, Did a project using meteor, spent way too much time trying to get it all install with Vagrant (so all info from 1 was not useful) 3. Year later, Changed meteor setup to use docker ... so had to learn docker (so all info from 2 was not useful…
Just stop hopping. Anything youvet tried would be fine to stick with.
Re: The architecture behind a one-person tech startup
#215The author almost seems to apologize for having a django monolith. But it's worth realising that one purpose of code organisation in larger companies is to mirror the team organisation. That's a constraint on code that can interfere with the best technical architecture. You can do better with a monolith in a one-man team!
> one purpose of code organisation in larger companies is to mirror the team organisation.
Sometimes, the organisational structure drives the code structure (Conway's law [0]). I've seen real world consequences of this, where the disconnected system stovepipes in a large organisation reflected the team structure of the organisation's purchasing function. The purchasing teams didn't speak to each other, so neither did the systems they purchased. The systems had separate support contracts, incompatible upgrades, and each one was a wholly distinct integration target, if you were a third party.
Re: The architecture behind a one-person tech startup
#216As a one person company I find it not just helpful but a core principle to minimize the number of stacks/tools/services being used. Overhead of task switching and learning curves.
Re: The architecture behind a one-person tech startup
#217Reminds me of Listen Notes: https://www.listennotes.com/blog/the-boring-technology-behin...
Re: The architecture behind a one-person tech startup
#218Earlier quoted context omitted.
If you're just now looking in to GAE, you should likely be using Cloud Run instead. My company is busily migrating everything there and reaping the benefits.
So, this what scares me: in 5 years someone using GAE would be busy with two migrations: classic GAE -> flexible GAE -> and now cloud run?..
GAE Flex is super old at this point and I've never personally met someone who migrated between them (they're pretty different offerings imho). Moving between either GAE to Run has been pretty seamless though.
Re: The architecture behind a one-person tech startup
#219My one-person SaaS architecture: It’s a Rails monolith deployed on Heroku. I’d rather have the time to build new features for my user base than spend it learning how to use k8s or wrangling AWS through its abysmal console website.
Do you think you're better than the OP because you're using a simpler stack?
It's about solving every problem in due time.
Starting with an easily scalable infrastructure, if the need for a scalable infrastructure is either unproven or distant, is not the best use current resources. It's more cost-effective and beneficial to use an out-of-the-box tool like Heroku and spend our time building the product that people will actually be paying for.
There might come a time where the hosting costs on Heroku are getting frighteningly high, but even then it's something that might not be high priority. If the profit impact of building and maintain a K8 infrastructure is less than the profit impact of building a new feature and securing more users, then by all means, let's continue paying Heroku and focus on what makes the business more sustainable.
The time to convert from a simple setup like Heroku to a scalable system like K8 is when that change has the biggest net impact on the company's operation.
Re: The architecture behind a one-person tech startup
#220Earlier quoted context omitted.
I oversimplified a bit. I have a low-traffic "admin" interface that's rendered server-side. The people using that are my direct customers and are the only authenticated users (they auth in a traditional in-app way). I also have a high(er)-traffic frontend on a CDN which is used by their customers. User writes there are purchases/payments handled by third(fourth?)-party SaaS.
Many sites have low write:read ratios and don’t leverage that fact in their architectural choices. Availability for maintainers is often less critical than for consumers, and your life is better if you build that in. My current employers still haven’t learned this lesson and think caching fixes everything.
Not sure I am following you: why shouldn't we use cache?