Live data from Hacker News

You are not Google. You are not Netflix

programmerfriend.com

51–58 of 58 posts

Re: You are not Google. You are not Netflix

#51

Earlier quoted context omitted.

Machine learning may have been used and abused as a meaningless buzzword but kubernetes in particular and container orchestration in general is a well established and proven infrastructure technology. If you are not operating a monolith and you need to automatically deploy and scale your service then you have no technically-sound argument to not use this sort of infrastructure.

the question is if an early stage start-up with 4-5 devs where they typically already struggle to get basic CI in place ... and where 1 of the devs loves K8 and the others don't really know it (but don't object because it's nice to have it on the CV), whether they should really already focus on orchestration and scaling before they even have a MVP. I'm not against k8 per se, but its complexity isn't something to igno…

> the question is if an early stage start-up with 4-5 devs where they typically already struggle to get basic CI in place ...

Nowadays it's super easy to setup a CICD pipeline. The basic settings and intro examples alone are enough to build and publish container images to a container registry.

> and where 1 of the devs loves K8 and the others don't really know it (but don't object because it's nice to have it on the CV), whether they should really already focus on orchestration and scaling before they even have a MVP.

That doesn't make any sense. Developing services to run on kubernetes is a software architecture problem, one which only affects some minot dev level details such as supporting env variable settings. Devs can be entirely oblivious to kubernetes and still be effective.

> I think we have reached peak k8-hype last year when F. Campoy

That's largely irrelevant and misses the whole point. Just because some people present some gimmicky take on a technology it doesn't mean the fundamentals are not good. Kubernetes allow distributed services to be deployed transparently across multiple providers (thus you are not held hostage by a seller), and allow services to automatically scale horizontally with demand and within resource limits gracefully degradate after that point. That doesn't go away if someone decides to reenact Inception with buzzworthy technologies.

Re: You are not Google. You are not Netflix

#52

I think this article is basically right, but I want to provide a personal perspective on this: This is why I have found that I prefer working on a widely used product at one of these big companies. I find the most enjoyment in thinking through how to make products work acceptably for huge numbers of users, or how to pick the needles I need out of enormous data sets, or how to structure a codebase such that hundreds o…

Yeah. Since working at a place that does have to think about problems in these terms, I find such YAGNI stuff much less compelling.

Guess what, some of us actually are gonna need it. And if you don’t begin with the future in mind, starting out with something “simple” can result in some very not-simple situations down the line.

Re: You are not Google. You are not Netflix

#53
post #6

> A developer’s skill is measured in one parameter: how well he writes code. While this could be a valid viewpoint, one thing I’d caution against is that this type of measurement inevitably leads to the commoditization of developers. Rating skill on a single point will lead to “you’re only worth what this metric says you are worth” and eventually to constant competition between developers instead of cooperation. At l…

Actually I’ve found that a lot of development is actually about image projection, or how good you make other people think you are. This is especially true with non-technical folks, who don’t know 1/2 of what developers do anyway. Our office’s “rockstar” dev has his 3 widescreen monitors tilted vertically and he uses a split keyboard. He’s so quirky and leet.

Not everything is an affectation.

Re: You are not Google. You are not Netflix

#54

I worked on the floor with two teams. One (ours) built our apps and infrastructure the correct way. JIT. Get it working, get it working correct, get it working fast. And given the scale, it did wonders. The other team talked big and gave demos to higher ups and their higher ups and their higher ups. Web scale baby. And with that came the galactic infrastructure and all the buzzword needed in order to run it. About 6…

I don't believe I'm familiar with JIT in this context? Just in time development?

I think YAGNI is a more common term.

Re: You are not Google. You are not Netflix

#55

Earlier quoted context omitted.

Sorry. No, I wasn't referring to JIT Manufacturing... It was merely a tongue-in-cheek to mean just build what's needed right now in front of you, then get it working at scale once there's an actual needs to scale. This is in contrast to starting from day one spending most of your time thinking of scale, then building everything so that it can infinitely scale (along with the complexities that come with it), only to f…

> just build what's needed right now in front of you What's needed right now, but that doesn't take a complete overhaul when it's time to start growing.

It requires a very savvy developer in order to succeed. I have seen the massive technical debt this approach can give.

Re: You are not Google. You are not Netflix

#56
post #48

Earlier quoted context omitted.

> When I mean JGID, I also meant not make it a steaming pile of shit :) the tldr of my post is that people often don't know the difference. We also have grown a culture of people promoting "YAGNI", and its easier for some people to dismiss basic ideas with YAGNI. Yeah, adding 5 language translations to your project on day 1 - YAGNI. Storing passwords in plaintext? You need something more than that.

All the rules of thumb seem to have massive categories of exceptions where they don't work, and that makes me suspicious of applying new ones that I don't fully understand. DRY up your code... unless the two code paths look similar but aren't the same. YAGNI... unless "it" is a database backup, a load balancer, or test coverage of your signup flow. KISS... unless your problem is complicated enough that a simple solut…

and yeah, you should be suspicious of doing anything that you don't understand. this is all knowledge work, and there's some implicit notion that when you make a decision you have some level of understanding. the bigger the potential impact, the more understanding you should have.

Re: You are not Google. You are not Netflix

#57

Earlier quoted context omitted.

Out of curiosity - Which database is this? and is it really taboo to have views joining against multiple other views? If the underlying views were performant- I'd assume the query optimizer would do the right thing(at least 90% of the time). EDIT: I guess it depends - Just did more research and found this [1]. As long as the views don't do unnecessary heavy lifting or joining unnecessary tables, it should be fine. [1…

I think SQL views are a bit of a code smell. They're really only useful in my opinion as a hack, where creating a rather gruesome abstraction within the database is easier than changing the query layer. I'm currently working on a service written by a bunch of hipster developers who, wrote raw SQL in Python. And they wrote views, lots of really difficult to understand views that are self-joining (on JSON fields no les…

> lots of really difficult to understand views that are self-joining (on JSON fields no less!)

HOLY TAMOLE! You might have my story beat there. That's one level I didn't have to deal with. My sympathies!

Re: You are not Google. You are not Netflix

#58
post #38
post #28

Earlier quoted context omitted.

Could you elaborate more? I'm a bit confused. The first one seems to do the wrong thing because there is no mention of any stakeholder at all. Getting it working first is great though. The second one seems to do the right thing by demoing to stakeholders first. Then, it goes on to make it web scale with buzzwords (which doesn't seem good). The best combination seems to be: 1. demoing to higher up and 2. JIT (I'm not…

When faced with building a simple web page, Team 1 spends a couple of days producing a single static html page and builds on it as necessary. Team 2 spends 6 months showing upper management architecture diagrams and flashy mockups. They blow a million dollars on cloud hosting their load balanced web servers. They've got Kafka, ElasticSearch, triple redundant SQL servers, and a 12 person team to run it all. But when a…

lol, reading your description made me think you were there too... but you said $1M rather than $6M :)
Post reply on HN