Live data from Hacker News

You don’t need to be “enterprise-ready” or “scalable”

gorelay.co

91–100 of 185 posts

Re: You don’t need to be “enterprise-ready” or “scalable”

#91
post #77

Earlier quoted context omitted.

At Google, it is very team-specific but it is generally not possible to run servers locally for testing and there generally is no staging environment, but it might be possible to bring up some part of the stack on Google's clusters. Those severs may read production data or some test data. Other than that there are static checks, unit tests, code reviews and the release process to ensure reliability.

How do you develop features if you can't run the server locally? Do you just write code, get it approved in a code review and push it to production?

Chipping in as another Googler - agree that it is team-specific, but you generally can bring up development environments (in terms of what traffic is served, closed to the public, etc.), but these aren't actually run locally.

Re: You don’t need to be “enterprise-ready” or “scalable”

#92
post #57

I've delivered custom backend business servers to a various businesses of healthy size. Almost all were deployed on rented multicore servers with gobbles of RAM from Hetzner / OVH / etc. Some running for many years already. Not a single one required to be "enterprise scaled". Granted all servers are C++ and talking to a local DB. No problems in processing thousands requests per second without breaking much sweat.

Sounds interesting. What's the DB? What framework/type of API are you exposing on the C++ size?

Re: You don’t need to be “enterprise-ready” or “scalable”

#93
Horizontally scalable data storage is generally available these days (cockroach, tidb, vitess, etc.)

Rearchitecting from unscalable to scalable data storage is notoriously difficult and expensive. Even the most famously competent companies and teams have struggled with that transition and invested millions and millions of dollars on it. Building on unscalable data storage when scalable data storage is readily available feels like planning for failure and making a huge bet that your product or system will never have widespread use.

Re: You don’t need to be “enterprise-ready” or “scalable”

#94
post #4

Though it helps if you design your software in a manner which allows for drop-in replacements to non-scalable parts of your design.

Great use-case for GraphQL, unironically.

Or just a classic database, backend, frontend three tier application?

Re: You don’t need to be “enterprise-ready” or “scalable”

#95
post #87

Earlier quoted context omitted.

Why would a team decide to use nosql to manage "a few hundred" entities? Nosql databases excel at simple lookups and gets by ID, rather than trying to sort and join pretty much ad hoc.

Why would you ever use SQL? The SQL transaction model doesn't make a lot of sense for most use cases (including essentially anything that uses the internet), and trivial usability things like being able to have collection columns without having to define a separate table all add up.

> SQL transaction model doesn't make a lot of sense .... anything that uses the internet

So decades of PHP+MySQL and Rails+PostgreSQL were simply misguided?

Re: You don’t need to be “enterprise-ready” or “scalable”

#96
post #11

Hard agree. History is littered with dead startups that designed for scale before they had enough usage to justify it. Within reason, having users knock your site over resulting in failures like the Twitter Fail Whale is a good problem to have. With that said, you need to be prepared to scale up quickly once you have this problem. There's a reason Facebook counts its users in the billions, and Friendster is a footnot…

Facebook is a great example. They did tons of things not traditionally known as highly scalable. Like one repo with the project coded in php which was largely a monolith.

And an imperative codebase which looked like something out of Matt's Script Archive. I often wonder whether a startup today could pull-off something similar.

Re: You don’t need to be “enterprise-ready” or “scalable”

#97

I was interviewing for a platform engineer role for a company that from the outside their application doesn't seem too complex. Through the interview process, I find out that you cannot run much of their app locally to develop against and their staging environment does not reflect their production enviroment well. I asked them how they develop their new features if they cannot run the whole app locally and if they in…

Yea, it’s common that one doesn’t exist. I work as a test engineer and am usually the one to build and support those environments, I’ve yet to find a company that has it all working well before I join. I actually made a killing building integration testing environments of blockchains and sticking them in CI too.

Re: You don’t need to be “enterprise-ready” or “scalable”

#98
post #35

I was interviewing for a platform engineer role for a company that from the outside their application doesn't seem too complex. Through the interview process, I find out that you cannot run much of their app locally to develop against and their staging environment does not reflect their production enviroment well. I asked them how they develop their new features if they cannot run the whole app locally and if they in…

> Is this common at other companies that you cannot run the whole app locally to develop and test against? Yes. I work in B2B banking software, so having an "authentic" environment to test against is extraordinarily complex. Even the big vendors in the space seem unable to maintain accurate facsimiles of production with their own decades-old core software, so smaller vendors stand no chance unless they adjust their e…

I worked at banks too but mostly segregated from the core business. Today I see observability tools as the solution for problems like that. Specifically tools like Lightrun where you can observe production, mitigate and fix directly from the IDE.

I wonder if other developers are familiar with this approach?

Re: You don’t need to be “enterprise-ready” or “scalable”

#99
post #87

Earlier quoted context omitted.

Why would a team decide to use nosql to manage "a few hundred" entities? Nosql databases excel at simple lookups and gets by ID, rather than trying to sort and join pretty much ad hoc.

Why would you ever use SQL? The SQL transaction model doesn't make a lot of sense for most use cases (including essentially anything that uses the internet), and trivial usability things like being able to have collection columns without having to define a separate table all add up.

That's roughly the same argument as choosing a strongly typed vs a weakly typed language. I much prefer the strong typing personally. Yes, it's more work up front. But every other person that works with the data knows what they're getting.

Re: You don’t need to be “enterprise-ready” or “scalable”

#100
As always, you cannot make blanket statements with software such as "you don't need to worry about scale".

Perhaps your application does need to worry about scale and then if you don't then you're a fool. Then you launch, succeed and collapse or get beaten by competition because the effort to scale was beyond you in the needed time.

The blanket statement that is true about software is "be wary of blanket statements about software development".

Post reply on HN