Tech that DOESN'T WORK for Start-ups and Mid-sized companies

Подписаться 585 тыс.

Просмотров 19 тыс.

50% 1

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

Опубликовано:

4 авг 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 87

@pritamsinha5479 10 месяцев назад

I always say this to my developers: Build first. Optimise when required.

@amanali9501 10 месяцев назад

During my internship at an early stage startup ,my manager advice this to me.

@akash-kumar737 10 месяцев назад

Yeah one piece of adivce I would like to add is go with old and tested tech like SQL over NoSQL.

@arunabraham9382 10 месяцев назад

In a way that may be true. But always follow a quality foundation that make use of extransible and maintainable codebase

@vdiitd 9 месяцев назад

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.

@pritamsinha5479 9 месяцев назад

@@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.

@saagnikadhikary6582 10 месяцев назад

@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!

@nithinbhandari3075 10 месяцев назад

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)

@umair.ramzan 10 месяцев назад

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.

@dn5426 10 месяцев назад

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.

@saurabhchandrapatel 10 месяцев назад

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

@dn5426 10 месяцев назад

@@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.

@Francisco-gz5nf 10 месяцев назад

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.

@marcuadrian5136 10 месяцев назад

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.

@bhaskarkaura4507 10 месяцев назад

agreed!@@marcuadrian5136

@b5fw6jg7 6 месяцев назад

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.

@mayankmathur3257 10 месяцев назад

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!

@asurakengan7173 10 месяцев назад

It was less expensive -- it took 3 years. Isn't this a perfect example of oxymoron 😂

@rylaczero3740 10 месяцев назад

@@asurakengan7173They probably had a lot of services to dockerize.

@ggeilokowski 10 месяцев назад

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.

@paragkadam2169 10 месяцев назад

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.

@odudimusamuel4731 10 месяцев назад

Glad you said it, this is exactly my point.

@rylaczero3740 10 месяцев назад

A very useful set of guidelines if someone is going to lead tech for a startup.

@Graham_Wideman 10 месяцев назад

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.

@ayepushkar 10 месяцев назад

Thanks! Got a good checklist/ set of guidelines.

@naeemkhan4534 10 месяцев назад

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 ?

@wennwenn1422 10 месяцев назад

This guy finally learned that not everything has to be distributed. His videos were always about that without warning viewers about complexity.

@darshandev1754 10 месяцев назад

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

@Petyr25 10 месяцев назад

Agreed with all except NoSQL. Definitely depends on the use case.

@GauravKawatrakir 10 месяцев назад

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.

@dgoenka1 9 месяцев назад

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

@krishan.kumar.mourya 10 месяцев назад

Nice points to consider with perfect examples.

@nameisvamshi5129 10 месяцев назад

very useful information... Thank you very much

@gkcs 10 месяцев назад

Glad it was helpful!

@anirudhtd7193 10 месяцев назад

Spectacular video chokefull of information.

@phaneendhraajaythota1025 10 месяцев назад

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.

@rjaparri 10 месяцев назад

Absolutely bang on and something I wish more startup leaders understood!

@sangamsahai9823 10 месяцев назад

Loved this !!

@prathamgandhi2308 10 месяцев назад

What about using containers when all your developers are on different platforms using different OSes and your production server is on different platform?

@sohansingh2022 10 месяцев назад

please make more such videos!!

@jvmadhav1987 10 месяцев назад

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.

@nischaltyagi7115 10 месяцев назад

Really insightful, Maybe learning about large scale systems has created this bias in us

@rylaczero3740 10 месяцев назад

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.

@gkcs 10 месяцев назад

I think so. The hype gets added through interviews too.

@Graham_Wideman 10 месяцев назад

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?

@rylaczero3740 10 месяцев назад

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.

@Graham_Wideman 10 месяцев назад

@@rylaczero3740 OK thanks for that. I see there's a Wikipedia page for "Lakh".

@Graham_Wideman 10 месяцев назад

@@rylaczero3740 .. and the sentence I quoted translates to 10k to 100k users. That makes sense now!

@lolplayfelix-_-2713 10 месяцев назад

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)

@vaibhavpathak6721 10 месяцев назад

I agree with you actually

@nikhiljugdan724 10 месяцев назад

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

@darshandev1754 10 месяцев назад

@@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

@shrin210 10 месяцев назад

If implemented correctly... Is SQL really that complex than NoSql?

@darshandev1754 10 месяцев назад

@@shrin210 nope, in my opinion, denormalization (duplication of data) is way more complex

@alphabee8171 10 месяцев назад

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.

@manaslovesbirds 10 месяцев назад

5:02 Spring Modulith enters the chat

@VivekKumar-iu3mt 10 месяцев назад

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.

@shuvojit1000 10 месяцев назад

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.

@Downloadlabss 18 дней назад

Totally agree with this.

@adityaj21 10 месяцев назад

top tier entertainment

@Tanmaygaming0406 10 месяцев назад

Trust me you uploaded this video, now its a trend and people on many system design they will start including these points... 😂

@rahulpalve401 10 месяцев назад

Disagree on containers, containers made deployments and even local dev easy for us

@jmr218 10 месяцев назад

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.

@dellta2357 10 месяцев назад

I really agreeeeeeeeeeeeeeeeeed for aaaaaaaaaaallllllllllll points. no joke. I think it is very important.

@saurabhchandrapatel 10 месяцев назад

I agree

@arvindbalajee5346 10 месяцев назад

Can microservices work on both sql and nosql dbs or should i have to stick on with any one of the approaches

@rylaczero3740 10 месяцев назад

Don’t force pain upon yourself. Keep it simple, go monolith, there is nothing wrong in wanting a better life.

@darshanpahilwani9983 10 месяцев назад

Each service can have it's own database which can be nosql or sql

@darshandev1754 10 месяцев назад

@@rylaczero3740 lol

@art4eigen93 10 месяцев назад

Good advice but not good mic quality.

@throttlesandkeyboards 10 месяцев назад

First make it work, then make it right, if your company become successful then make it fast. :)

@sahilsingh5695 10 месяцев назад

so means writing shitty working code is ok until you reach a customer target...why doesn't my manager understands this

@lawalexlaw 10 месяцев назад

I use containers even for my own toy project, it's great.I am a 3 yoe engineer

@darshanpahilwani9983 10 месяцев назад

and also dear 1 lakh users can make 10 lakh to 50 lakh api requests!

@alpanakushwaha9109 10 месяцев назад

Happy Engineer's Day Gaurav🚀

@gkcs 10 месяцев назад

Thank you!

@alpanakushwaha9109 10 месяцев назад

🤩@@gkcs

@darshanpahilwani9983 10 месяцев назад

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

@rylaczero3740 10 месяцев назад

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.

@darshanpahilwani9983 10 месяцев назад

Can you elaborate further on what type of problems are not handled by the system?

@S3Kglitches 10 месяцев назад

What system lasts less than 6 months lol

@darshandev1754 10 месяцев назад

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