Tech that DOESN'T WORK for Start-ups and Mid-sized companies
Vložit
- čas přidán 11. 06. 2024
- Tech advice is like refactoring. It's easy to talk about, but hard to implement.
In small companies, picking up low-impact projects can derail the entire organization. In this video, we look at what are the worst pieces of tech advice for startups, and how to avoid them.
At the end of this video, you should be able to detect superficial hype-fueled advice from a distance. The overall idea of the video can be summarised in two acronyms: KISS and YAGNI.
The video explains the above with examples :D
00:00 Who is this for?
00:51 5. Containers
02:20 4. NoSQL
04:35 3. Microservices
05:59 2. Quality Obsession
08:00 1. Automation
11:13 TLDR
11:38 Thank you!
System Design at InterviewReady: interviewready.io/
Designing Data-Intensive Applications Book: amzn.to/3SyNAOy
You can follow me on:
Github: github.com/InterviewReady/sys...
Instagram: / interviewready_
LinkedIn: / interview-ready
Twitter: / gkcs_
#Startups #NoSQL #Containers
![20 AWS services you should know [as a Software Engineer]](http://i.ytimg.com/vi/tNbMyQGGyYM/mqdefault.jpg)
I always say this to my developers: Build first. Optimise when required.
During my internship at an early stage startup ,my manager advice this to me.
Yeah one piece of adivce I would like to add is go with old and tested tech like SQL over NoSQL.
In a way that may be true. But always follow a quality foundation that make use of extransible and maintainable codebase
That advise works only if the system is small and low use. Its a bad advise if the system you are building is going to handle millions of messages on a daily basis. I cannot tell you how many times I have come across bad code which did the work, but it became too slow to handle the volume. It had to be redesigned as a new project or even optimized during production incidents. You don't have to spend weeks and weeks on optimizing the code, but I expect a balance of optimization vs time spent.
@@vdiitd No startup should be built
for scale from day 0. A lot of things change fast and very fast. It's always better to be sure if that shiny "feature for millions of people" is even required for 10k people. Once sure, optimise.
PS : We keep the system design and code structure in a way that it could be easily extended. So, that helps.
@Gaurav, I simply love that chuckle at 4:38, when you mention microservices!
Immaculate content, with so much to ponder about. Thank you and please keep on delivering such not-so-talked-about contents. It really helps!
I would disagree with the point on containers. Having a Dockerfile lets you deploy to lots of Heroku like platforms (Fly, Render, GCP Cloud Run etc.).
Container images as a deployable artifact are great but I agree that using a container orchestrators like k8s is unneeded complexity.
In startup, no need to use containers it will be complex to manage containers, network, monitaring, debugging and clusters itself for less experienced engineers at startup
@@saurabhchandrapatel I'm not telling people to run the containers themselves, simply telling them to write a Dockerfile for their service.
There are lots of platforms like Heroku, Fly, Render where you can give them a git repo with a Dockerfile and they'll automatically deploy the service for you. Everything like scaling, logging, monitoring, building/storing images in a registry is all managed by those platforms.
6:00 A minimum amount of quality is required, like writing strict schema (in nosql).
And basic documentation.
And writing strict code, like using typeof is really required.
But nested abstraction 95% of time is not required.
Doing copy paste 4-5 times is better than creating common function. (For 90% times). Just make code flexible.
(All above are my beliefs)
Interesting. Our org actually migrated all services to dockerized containers because it was much less expensive and it was easier managing its availability. And it took 3 years!
It was less expensive -- it took 3 years. Isn't this a perfect example of oxymoron 😂
@@asurakengan7173They probably had a lot of services to dockerize.
You think development just happens in a few months? Three years if negligible if the savings or benefits are large enough. Also, it doesn’t mean they worked three years on migration non stop.
Containers are highly effective for start ups and mid size business. You can easily create highly available applications and adopt cloud infrastructure faster. AWS code deploy, and Github Actions can really help drive automation of container development. Honestly even simple bash scripts with docker compose can really elevate a startup stack to get a lot done really quickly. Containers a such a big game changer its honestly the next evolution of virtualization and makes more efficient use of compute power. To me its a must learn technology.
Agreed, the pain you get migrating your application in containers after a certain amount of users subscribing can take years, why not invest 2-3 days in the beginning of a startup to thing about containerization.
agreed!@@marcuadrian5136
Exactly! If you don't have knowledge about it then, just take help from any 1+ YoE DevOps Engineer to setup the basic stuff. Then, later on when you can hire a dedicated DevOps engineer he can upgrade without worrying about migration.
I agree on most, but I disagree on containers. Using containers makes my life easier in development work flow. Atleast when deploying small services like simple ml model and multiple deployments for testing purposes.
Everything else other than the code quality part, I agree(Its not nice to obsess over quality at the same time), poor code attracts more poor code and it leads to code rot which slows down everyone and make the system hard to change.
Glad you said it, this is exactly my point.
8:00 #1 Automation -- all good points. I think the checklist regarding "should you automate this process" should include an item about consistency of result of the process. If this is a process where doing it manually is vulnerable to missing a step or making a mistake, especially if hard to notice, then that can have downstream consequences of unforeseen severity. So not just cost or time, but of unpredictable degree. Doing manual spreadsheet reports on something (to pick a mundane process) could randomly result in errors that lead management to wrong decisions... etc etc. This topic overlaps with "5. Savings", but I'm advocating a more explicit Risk aspect discussion.
A very useful set of guidelines if someone is going to lead tech for a startup.
Thanks! Got a good checklist/ set of guidelines.
very useful information... Thank you very much
Glad it was helpful!
Nice points to consider with perfect examples.
This guy finally learned that not everything has to be distributed.
His videos were always about that without warning viewers about complexity.
Spectacular video chokefull of information.
Loved this !!
Gaurav I don't understand one thing, if these practices are not followed now, like example code quality. What will happen when the code grows? Mircorservices? When user grows? Asking purely in terms of techincal perspective? Then do the companies re write whole code or what is the process ?
Awesome! can you also make this at a more fine grained level, like may be choosing something more feature rich (eg Nest) vs something simpler but limited (eg Vanilla Express) in favour of faster development - may be my example doesn't apply, but you get me i guess
Agreed with all except NoSQL. Definitely depends on the use case.
Absolutely bang on and something I wish more startup leaders understood!
agreed on all points,
I believe these points only come as revelation after a developer builds a product from scratch
I haven't met an experienced developer arguing for microservices, or containerization on a MVP
please make more such videos!!
Altering table 20 times and increasing table size (Colums). This is happening in my current project. Now we have a huge JSON object which is travelling in between services. Using SQL is not always a good choice for everything. Better to use combination of SQL and NoSQL.
Really insightful, Maybe learning about large scale systems has created this bias in us
We, software devs have tendency to be attracted to high complexity solutions rather than finding simpler ways to look at the problem. This creates hype about newer technologies which mostly just add more and more complexity without addressing underlying problem.
I think so. The hype gets added through interviews too.
i agree with most of these except for nosql and containers
for small companies nosql (if implemented correctly) can be a way to reduce complexity in systems that dont need relational data. and containers are a cheap way to add security (obviously doesnt paint the whole picture but for a small company it is good that if they have an rce vuln in their backend, that the entire server isn't compromised)
I agree with you actually
I would say most use cases absolutely NEED relational data. The amount of complexity that you create when trying to build relational systems in NoSql is far greater than SQL complexity
@@nikhiljugdan724 right, even in a mildly complex system, even when using nosql, its difficult to denormalize the data to simplify querying, because it leads to update and delete cascades
never found nosql to be a simplifying force
If implemented correctly...
Is SQL really that complex than NoSql?
@@shrin210 nope, in my opinion, denormalization (duplication of data) is way more complex
code quality, obsession is bad but having good practice in general is not. There's one game that i often enjoy to play, it's been a while since release and became very popular. They later decided to rewrite the whole game since it was "spaghetti code" . Development time that could have been spent on a lot of creative ideas was drained to start from scratch. Sure it improved somethings a bit, but again reliving same experience in HD won't make them memorable. Even now the community is still waiting for the updates. Also not to forget that bad code in general will inspire future new devs to learn those practices as well.
What about using containers when all your developers are on different platforms using different OSes and your production server is on different platform?
I agree with all the points except on Code Quality. If the new features are developing fast and customers are growing, then releasing a bug free code would be possible only if the code quality is good. We may go fast initially but bad code will slow us down in long run.
May be for the first time I disagree.. containers are best way to setup env.. Automation you need to asses when and what to automate. NoSQL is just convenient for me.. and I agree with microservices.
5:02 Spring Modulith enters the chat
What's the terminology is Guarav using at 6:00 (from transcript) "If you have a mid-size company, I'm talking about 10,000 to one lack users," -- what does the word "lack" mean in this context?
10 lac/lakh users = 1 million users, so 1 lac is 100K users. Instead of millions and billions, lac/lakh and crore are mostly used in India. 1 lac = 100K, 1 crore = 100 lac.
@@rylaczero3740 OK thanks for that. I see there's a Wikipedia page for "Lakh".
@@rylaczero3740 .. and the sentence I quoted translates to 10k to 100k users. That makes sense now!
Trust me you uploaded this video, now its a trend and people on many system design they will start including these points...
😂
What do u mean, containers are useless. I should just yarn start my nodejs server? Sorry being a developer of the post docker world, I don't really know how deployment worked before this.
There are other ways to demonize your application process. You can search for pm2. It's a great way of running your apps, it even lets you scale horizontally. And it supports nodejs & python out of the box.
I agree
I really agreeeeeeeeeeeeeeeeeed for aaaaaaaaaaallllllllllll points. no joke. I think it is very important.
Disagree on containers, containers made deployments and even local dev easy for us
Can microservices work on both sql and nosql dbs or should i have to stick on with any one of the approaches
Don’t force pain upon yourself. Keep it simple, go monolith, there is nothing wrong in wanting a better life.
Each service can have it's own database which can be nosql or sql
@@rylaczero3740 lol
I love how many disagreements there are in the comments. Many of them are valid, highlighting how complex these decisions can be.
1. I disagree with the points on containers & automation since I've seen too many benefits in those areas with small teams to discount them. Guard rails are good and I'll never say no to getting time back
2. Partial disagreement on microservices because of the occasional need for something that is far removed from a company's core value prop. If an engineer can't easily handle this then they should probably stick to a monolith.
Good advice but not good mic quality.
top tier entertainment
so means writing shitty working code is ok until you reach a customer target...why doesn't my manager understands this
I use containers even for my own toy project, it's great.I am a 3 yoe engineer
First make it work, then make it right, if your company become successful then make it fast. :)
Happy Engineer's Day Gaurav🚀
Thank you!
🤩@@gkcs
and also dear 1 lakh users can make 10 lakh to 50 lakh api requests!
I dont agree with any of the points though you're in a more experienced position than me but that's not how things work . Why do humans evolve is because they want to be better , same is for software engineering. and if you consider requirements i dont think most of the people even utilize their mobile phones to full potential but still it keeps getting better ask yourself a question why do even people need foldable phones ?! Basic requirements of people are fulfilled with basic features i dont think there is even a need for a software product to be developed further if the requiremets are met and fulfilled
You are not correct in some places, my friend. All requirements are never handled fully by the system because software complexity explodes and it is to keep a check on this complexity, most only do a subset of requirements.
Can you elaborate further on what type of problems are not handled by the system?
What system lasts less than 6 months lol
when you have a greenfield project, you test out your approaches, data model evolves, features get added, code rewrites are done, if you have multiple devs then your system's state changes greatly over the span of a week, let alone 6 months
but there are multiple factors here, I'm not saying you can't have a non changing system for 6 month, or years