I've been at $BIGCO for a while now and have lost track of all the innovation that's happening outside because of the proprietary stack we have to work in. What is the tech stack you'd chose for your startup assuming you want to use some sort of cloud provider and aren't going serverless? Looking for something that's not self-host / buying a cheap VM off of digital ocean and setting up the whole thing yourself. I hate to say the word, but "cloud-native".
Some things to think about:
- Source control (git in some form? where is it hosted? github? mono repo?)
- CI / CD
- Kubernetes? Or plain old VMs?
- DB - Full relational DBs? Midway like Spanner? Or full key-value like DynamoDB?
- Service framework
. What do you use for auth specifically?
- GraphQL or no?
- Caching solutions?
- Service metrics + dashboards? Do service frameworks emit metrics out of the box? (requests, errors, latencies etc.) or do you have to DIY?
- Messenger? (Slack vs Teams vs Chime vs Google Chat)
- Bug management + Sprint management?
- Anything else I'm missing?
Thanks!
I will say as far as Auth that if it's going to be important to your business and you are planning on having a ton of users then you should either choose a platform with it baked in or you should leverage a provider such as Auth0. Auth0 cost-benefit will be positive for almost any business except one that registers a ton of low-value users.
For databases, we seriously considered cockroach, but went with postgres. For source control, we use self-hosted gitlab.
For CI/CD, we use Go and bash exclusively. Our entire back-end/api is Go and we use Go templates on the front-end. Front-end is almost entirely straight html and css. There are handful of front-end javascript http calls if the customer has js enabled, but js is never required.
Auth uses jwt. The Go standard library makes it pretty easy. At $BIGCO, I did use Auth0, but it got very expensive.
We dont really need GraphQL, so that one's a no for us. For service metrics, we capture KPI data server-side and have an admin section/views for the business managers.
Our team is distributed - mostly US, but a few overseas. Slack for comms. Business managers and CTO prioritize support-tickets/feature-requests and they get assigned to developers. No formal sprints; just bundle features together into a release and test it.
Hope you read enough of this comment to avoid going this way, and prevent your team from going with this "defacto" way of doing things.
The above stack, which is what many companies are doing, is a total mistake in my opinion. It creates a LOT of work which is not related to your business.
It also involves a TON of discussions about how to do things, what state management library you will use, what router library, what ORM (oh wait, we favour no ORM in this language because ORMs are bad blah blah), what validation library you will use in the backend, what validation library on the frontend, a bunch of different testing frameworks (some for the backend code, some for the frontend code), a way to do CSS-IN-JS or similar, etc.
Moreover, those decisions are not something you can decide and be done with it. Those decisions come back every X months to bite your ass, because they get deprecated or their developers just moved to something else and just ignore you when problems arises (it's ok, they're not paid after all..). So you end up with some part of your system that now are unmaintained[1] [2]. In this world, things get quickly out of fashion, such as using classes for React components. Now despite they say in their docs it is perfectly fine to still use classes, this community is driven mostly by fashion, so nobody will want to use classes and a lot of time will be invested in rewriting perfectly working code into whatever the new trend is.
Then you have the equivalent crazyness at the infrastructure level. Teams of engineers playing with Kubernetes (because it is the React of the infra folks), which is a very low level tool, upon which they will build an TON of custom tooling and scripting and processes, etc,etc and cross your fingers so that they never leave your company because if they do, you'll be in a very bad situation. If you're lucky, you will end up with something which is about 25% of what you get from AppEngine, or any other similar service, except that an order of magnitude more expensive (because of the salaries of the people building this).
Let's not talk about all the work required to coordinate different services, document APIs from Backends For Frontends (TM), gRPC for communication between services because, hey, REST is overkill and non-performant, GraphQL which is the current trend and might not be tomorrow, etc.
I'm not saying all of this is useless and wrong for every situation. Those tools are great and serve in the RIGHT context. If you're a big company, with tons of employes, it is better to have to do more work if that allows you to split the work across people.
In a startup, or a small/mid sized company, there is nothing that beats a full stack solution such as Ruby On Rails. The libraries are stable and maintained because they're being used by a lot of companies. You have almost every decision already made for you, you might like it or not, but the set of decisions included in it are guaranteed to work well together. It is a lot more unlikely that some part of it will go unmaintained, you don't need to build an API for a separate frontend, you will get frequent updates, you have clear patterns and recommendations for how to do things. Deploy this on Heroku until the price goes to the salary of one or two engineers. That's a LOT. Would be more expensive to have somebody building a half assed version of it in-house. If it gets expensive, move to AppEngine or any similar, managed service. As long as you keep it using SQL and Docker you can move anywhere.
You might have more difficulty hiring people which, nowadays, want to work with Rails and do templates, etc. But the benefit is that you will need a lot less people for building an equivalent product. And probably you will find yourself with less people hyped by building kubernetes microservices on React with Monorepos and RXjs redux on top of Rust because "that's the defacto" and "ruby doesn't scale".
Please, CTOs of the world, let's get back to sanity. I just can't stand anymore seeing the time we're wasting with all of this.
Of course, at some point you will be a big company and then it might make more sense to do some of this. But think twice about all the trade offs until you get there.
Hope it helps.
[1] https://github.com/vercel/styled-jsx/issues/688 [2] https://github.com/ReactTraining/history/issues/804
GitLab for repository management. Our platform (https://iko.ai) has a plugin architecture with a tiny core that practically does nothing except load the plugins. All features are plugins. Each plugin is a repository. This simplifies things for us as we can experiment, add features, and kill features, without messing a giant codebase.
>- CI / CD
GitLab.
>- Kubernetes? Or plain old VMs?
Both. We use VMs, but have things that use Kubernetes for specific tasks.
>- DB - Full relational DBs? Midway like Spanner? Or full key-value like DynamoDB?
PostgreSQL.
>- GraphQL or no?
No.
>- Caching solutions?
No, but we tweak caching for some of the tools.
>- Service metrics + dashboards?
Prometheus and Grafana.
>Do service frameworks emit metrics out of the box? (requests, errors, latencies etc.) or do you have to DIY?
Both. Some emit metrics out of the box, but some parts are custom.
>- Messenger? (Slack vs Teams vs Chime vs Google Chat)
Slack for messaging. Jitsi for video. The platform itself (iko.ai) for pair programming or troubleshooting the platform itself (it has real-time collaborative notebooks we use to troubleshoot sometimes, or share reproducible example of bugs involving compute environments). I love using tools to improve the tools themselves.
>- Bug management + Sprint management?
GitLab
>- Anything else I'm missing?
Sentry, PostHog
A bunch of other stuff given that the platform relieves data scientists and machine learning practitioners from the complexity of many tools and stacks, therefore we inherit that complexity so they don't have to deal with it.
For DBs I don't see relational DBs not being the default choice for most folks.
CI/CD I'm curious about too. People seem to be migrating from Travis to Github actions.
Slack is still popular for messaging I think, but it is quite expensive. Discord is popular for people who want a cheaper option or want video chat.
Whatever you can build your mvp and iterate fastest in.
Use whatever source control you've used most often and are most proficient in - if that's CVS-RCS, use it anyway - you can always change to git when you get a second dev.
Do not even consider Kubernates unless you've used it so much you've forgotten how to configure a regular VM.
Do not learn a new database. Use whatever relational db you're most familiar with, or choose MySQL (or a variant). You won't need specialised key/value stores or time series databases until you scale past what a big MySQL/Maria/Aurora instance can handle, and you'll have learnt a _lot_ about your problem space by the that'll give you a real understanding of what data storage/query problems you have.
Pick a service and frontend framework you're familiar and experienced in and which has a big enough user base to provide decent support. Ruby on Rails, WordPress/PHP, Django/Python, whatever the relevant Microsoft equivalents are. DO NOT decide the first thing you need to do is write your own framework. That is _never_ the right answer. It is totally not true that "everybody else is an idiot". Those frameworks are familiar because they work - they solve enough of the common problems without making the uncommon parts of your project too much harder than doing it another way.
Throw away everything you don't need to get to mvp. You almost certainly don't need GraphQL or caching or service metrics or messengers or bug/project management software to get to mvp. All that can wait until after your second dev and after you've sat potential customers in front of your mvp. Probably until after you've sold to your first 10 or 50 customers. Bug reports in your email inbox work just fine until they don't, wait until they don't before you spend time solving that problem.
Just build something and ship it. It _really_ doesn't matter what you wrote it in, it's gonna be rewritten anyway if it succeeds. Many times. Proving someone will actually pay for it is a way more valuable use of your time at the beginning than carefully evaluating the advantages and disadvantages of Go vs Rust when you never used either in anger.
A "startup" is usually about building a dog and pony show about how you can solve a problem for a group of people and sell the solution to them - in a way where the size of the group and the price they're willing to pay and a plausible conversion rate makes you a unicorn/decacorn/whatever-we're-calling-it-now. You borrow or fake as much of it as you can. Customers care about you solving a problem for them, not "what your tech stack is". Investors care about customers and how much they'll pay you and how many other people have their problem, not "what your tech stack is".
Note: Some of that advice will be "obviously wrong" to you because there's details of your idea you haven't shared. If you're doing computationally expensive or data intensive work, by advice about Kubernates or databases probably don't apply. But you'll know if that applies. Do not fall into the trap of thinking "but I might need a globally distributed shared KV store when I get to 1 billion concurrent users!" when you have zero users, and no clear path to even getting your first 10 or 100 users.