Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Startup Anti-Patterns

itamarnovick.com

Post reply on HN
Print view View original

71–80 of 102 posts

Re: Startup Anti-Patterns

#71

Post by lelanthran »

Joel_Mckay wrote: post #69
lelanthran wrote: post #66

Earlier quoted context omitted.

> Best advice, answer the simple question "will random people buy this when no one is looking?"... if you have to explain/sell a product/service more than 5 seconds, than that business model likely isn't sustainable. For B2c, maybe. B2B is very different - they aren't going to make up their mind in 5 seconds and you aren't going to have a product that can be explained in 5s.

>B2B is very different - they aren't going to make up their mind in 5 seconds If not, than one is explaining/selling again, and you will only ever have 2.7%*(time/sales_pitch_time) customers. Letting client/customers dictate the terms of a product/service often will just turn your business into a staffing agency. B2B is actually more risk, as any deal exceeding 12% of revenue sets a timer on how long your business wi…

> If people can't summarize what they do in 1 sentence, than they likely have a fuzzy definition for a business project goal.

I broadly agree with your point, but disagree with this sentence. IME a 1-sentence business goal is almost certainly too fuzzy to be useful. There's nothing actionable about "We help you survive audits and readiness for regulation $FOO", which is frequently the business goal.

Re: Startup Anti-Patterns

#72

Post by sroussey »

1saadcodes wrote: post #30

Some seem to treat microservices as a sign of good engineering when it's often just premature complexity. You can always split a monolith later, but you're stuck maintaining that complexity from day one

You can have microservices inside a monolith. It has the advantage of always deploying in a synced state.

Re: Startup Anti-Patterns

#73

Post by derriz »

plmpsu wrote: post #58
HeavenFox wrote: post #50

Earlier quoted context omitted.

well... no, splitting a monolith once it has grown past the point where services make sense is incredibly difficult. My last employer spent a couple of years doing it and ultimately gave up. There is just way too much interdependency to split it up cleanly. So the key here is good engineering leadership to recognize when that point arrives, and push the company to start the transition. And indeed, microservices solve…

That's assuming you don't separate concerns in your monolith into modules with clear boundaries and dependencies. If you did that from day one, splitting a module off to a different service is easy.

I don’t agree. The technical device we use for creating clear boundaries, useful abstractions and managing dependencies in monolithic code is the function/method/procedure call.

The history of distributed software is littered with the corpses of attempts to make the RPC look like a function/method call (I worked for a CORBA vendor decades ago). But these two techniques are so different on a fundamental level they are not substitutable except in the most trivial cases. The compute and elapsed time RPC overhead which makes perfectly good local abstractions completely impractical across a network. And then there are the differences in terms of failure modes, concurrency and synchronicity.

So even a beautifully designed and layered piece of “monolithic” software with a code base costing of coherent and clean abstractions will not be easy to port to a microservices/distributed architecture.

Re: Startup Anti-Patterns

#74

Post by cpursley »

tikhonj wrote: post #31
brinepot wrote: post #28

Yep, seen too many startups jump straight to Kubernetes and microservices before they even have a validated product. Ouch.

I worked at a startup that did this and it was... totally fine? Like, we hired a guy who knew how to set Kubernetes up, he spent like a week or two setting it up, and then it was totally solid and the development experience was great. I was building some of the core product-specific logic and it only made my life easier. Which really just goes to show that the "legible" aspects matter far less than the illegible aspe…

Let me guess, VC funded start with plenty of cash to splash around and play with tech, beef up those resumes?

Re: Startup Anti-Patterns

#75

Post by alpineman »

bigcat12345678 wrote: post #57

I have done the startup thing as a failed founder and I myself call these startup patterns or antipatten mostly useless. One who enjoyed them (myself included) are destined to fail and then would concluded the same. The so-called pattern and antipatten are useless for startup, is just like parenting guides are useless for new parents. The complexity and novel problems are so large in volume that only basic instinct f…

That and luck plays a much bigger role than most would like to admit

Re: Startup Anti-Patterns

#76

Post by onion2k »

1saadcodes wrote: post #30

Some seem to treat microservices as a sign of good engineering when it's often just premature complexity. You can always split a monolith later, but you're stuck maintaining that complexity from day one

With microservices they're obviously complicated, and that's better. There's a complexity in monoliths as well, but it's hidden complexity. That gives developers a false impression that things are simpler.

For example, in microservices if you want some data that another service owns you have to define what it is, write an API, and handle all the fun of network problems. But once it's done you have a nice contract for getting that data.

In a monolith you can just reach over and take what you want. If you know there's a function for getting something you can use it. If you know the instantiated db connection has permission to view a row, just query the db directly. If you want to pipe some data somewhere just add it to the session object and it magically appears where you need it. And so on. You can go so fast! But then someone else does the same thing, and over time your monolith gets slower and slower, and needs more memory, and you find yourself having things on a god object that really shouldn't be there but it's hard to change because the behavior is threaded through everything.

Both of these problems are relatively simpler architectural issues, but it's always preferable to have well-defined complexity over accidental complexity. If you can define how code goes into a monolith and stick with those rules then a monolith is great. Most people can't, and I've never seen a company with multiple teams manage it.

Re: Startup Anti-Patterns

#77

Post by antonvs »

> Designing for investors

That entry isn’t published yet, but… this can be a viable tactic as part of a larger strategy. I’ve seen people raise significant money by designing for investors, and it got them to where they wanted to be.

Re: Startup Anti-Patterns

#78

Post by onion2k »

plmpsu wrote: post #58
HeavenFox wrote: post #50

Earlier quoted context omitted.

well... no, splitting a monolith once it has grown past the point where services make sense is incredibly difficult. My last employer spent a couple of years doing it and ultimately gave up. There is just way too much interdependency to split it up cleanly. So the key here is good engineering leadership to recognize when that point arrives, and push the company to start the transition. And indeed, microservices solve…

That's assuming you don't separate concerns in your monolith into modules with clear boundaries and dependencies. If you did that from day one, splitting a module off to a different service is easy.

If you can manage that then there's no real benefit to microservices though. The reason for splitting is to solve the problem of failing to separate concerns, so a team that can't do that well is better off building microservices from the start because the alternative for them is building a monolith that will be hard to split.

Re: Startup Anti-Patterns

#79

Post by dimaaan »

onion2k wrote: post #76
1saadcodes wrote: post #30

Some seem to treat microservices as a sign of good engineering when it's often just premature complexity. You can always split a monolith later, but you're stuck maintaining that complexity from day one

With microservices they're obviously complicated, and that's better. There's a complexity in monoliths as well, but it's hidden complexity. That gives developers a false impression that things are simpler. For example, in microservices if you want some data that another service owns you have to define what it is, write an API, and handle all the fun of network problems. But once it's done you have a nice contract for…

You don't need network boundaries for good architecture. Split monolith into modules with an interface

Re: Startup Anti-Patterns

#80

Post by strken »

wredcoll wrote: post #53
strken wrote: post #33

Earlier quoted context omitted.

Big companies mostly seem to use the microservice(s) per team model. If your whole company is two founders, one account manager, and an engineer, you only have one team. It can make sense to have more than one service for purely technical reasons. I once worked on a friend's startup where we built a separate ingress microservice so we could scale it independently from our monolith. There's no organisational benefit t…

Microservices are a solution to business/team organizational issues. Never technical ones.

I think the example I gave is a good counterpoint:

- you have a monolith, and it handles normal API traffic patterns

- you have a workload that involves different hardware needs e.g. extremely high throughput relative to the rest of the system (video streaming would be an example), GPUs, high memory requirements with low CPU or vice versa, etc.

Solution is to deploy a service that only handles the specific workload. Whether or not this is a microservice probably depends on your point of view but I'd argue it's at least close.

Post reply on HN