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

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

gorelay.co

Post reply on HN
Print view View original

151–160 of 185 posts

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

#151

Post by raffraffraff »

iovrthoughtthis wrote: post #141
raffraffraff wrote: post #133

Earlier quoted context omitted.

So how do you square they circle "Don't design to scale but scale up quickly when you need to"? You can't rewrite your stack just because you took on a new customer that is suddenly killing you. I don't think that it's stupidly hard to get basic things set up for scaling at the start. These don't apply to everyone but: - use a cloud provider, they let you grow - write infrastructure as code (terraform, pulumi, cdk),…

i didn't see the words "it depends" anywhere in this thats the whole point of engineering, picking/building the right solutions for the problems and context some stuff just needs a vps, a php file and an sqlite db and it will scale other stuff might need container orchestration or anywhere in-between (or beyond). it should depend on the context though and we should be prepared to change strategy as needed

I did say "These don't apply to everyone but:" and then gave my generic list of stuff that works for a lot of people.

I get that some people can just run a single go binary or whatever. The ones that don't, need to set themselves up to grow easily when they need to. Having some sort of basic plan or framework that doesn't take more than a week to set up is due diligence, and hiring (when your need to) will be much easier.

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

#152

Post by maccard »

jsiaajdsdaa wrote: post #24
wereHamster wrote: post #19

I'm working on a project where the backend devs decided to use Cassandra to manage a few hundred entities. Due to different access modes they had to denormalize the data into multiple tables and we're constantly running into consistency issues. A fucking sqlite db with a few tables and indexes would do just fine. Also, the tool has maybe a dozen DAUs. But it's web scale, so, yeah…

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.

At a few hundred entities, it doesn't really matter what tech you choose, so you should probably choose whatever is closest to hand.

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

#153

Post by cersa8 »

dominotw wrote: post #101
dub wrote: post #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 availab…

I am suprised how niche these newsql databases are. Is it because they are expensive? why wouldn't everyone use those.

I've experimented with migrating from PostgreSQL to CockroachDB and YugabyteDB. It makes sense that a newsql DB is slower but compared to to a local PostgreSQL cluster it was unacceptably slow. You lose features and are now dependent on a heavily VC funded startup that may not make it.

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

#154

Post by cutler »

jasonkester wrote: post #120
cutler wrote: post #96

Earlier quoted context omitted.

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.

Absolutely they could. And they should, because doing so will get you launched quickly. Instead, todays shops all start out with javascript front ends and 40 layers of backend complexity to accomplish the same thing.

I'm not sure. The bar for UI has been raised significantly since Facebook launched and mobile has changed the game to such an extent that you need a presence on 3 platforms out of the door (iOS, Android & web) to even stand a chance.

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

#155

Post by lifeisstillgood »

mieubrisse wrote: post #117
halfmatthalfcat wrote: post #53

Earlier quoted context omitted.

I haven't found a wholistic integration testing framework where you can effortlessly mock out upstreams as running services , so that you don't have to ham-fist integration testing code into your app or rely on actual, live upstreams which are probably prone to breakage anyway.

Shameless plug: this is exactly the spirit behind what we're building at Kurtosis! ( https://www.kurtosistech.com/ ) You get an isolated environment running real services connected to each other, so if you have a container with your mock then from your app's perspective it will look just like the actual upstream.

I have looked at your docs and don't quite get it. Is the idea that I have say 10 microservices that app-in-test will / may use, and then I set up the 10 instances (somehow all in one container?) and then can test that.

I think that seems sensible, but how is that different to 10 containers ? Is the issue something about simpler network management inside a container?

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

#156

Post by shardullavekar »

invalidname wrote: post #98
bob1029 wrote: post #35

Earlier quoted context omitted.

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

We are working on Videobug - it records code execution on production and plays in the developer IDE. Our Show HN here: https://news.ycombinator.com/item?id=31286126

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

#157

Post by danjac »

john_the_writer wrote: post #41
fasteddie31003 wrote: post #34

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…

I'm in that boat. We have a "microservice" code base, and spinning up the whole "app" is a Herculean task. Even if you do manage to get it all running, getting the multitude of database with useable data adds an odyssey to your day. We have some parts automated, but ops cannot keep up with all the changes in the micro apps. Back when I worked on a mono-rails app with a React front end, getting things up and running w…

The worst cases are startups adopting microservices. I get where they are a solution to a large company with multiple teams hitting the pain of monolithic development, but a team of half a dozen adopting microservices is a big red flag.

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

#158

Post by hiharryhere »

grinich wrote: post #145
dt3ft wrote: post #13

Earlier quoted context omitted.

I developed SAML/SSO integration for an application used by the Swiss UBS which initially relied on individual accounts, not even AD. Tricky stuff.

Small plug for http://WorkOS.com (where I work). It’s an API for easily adding SAML, SCIM, and more. Currently being used in production by Vercel, Planetscale, Webflow, and +200 other apps.

I can vouch for this - I’ve just rolled out workos with three enterprise customers in the last 6 months. Super simple, great docs. Had been putting off SSO for years hoping something would come along and solve it for me.

E.g I know nothing about Azure AD but I just emailed the WorkOS setup link to our customer’s IT team, they followed the instructions and it just worked. No back and forth.

Can’t recommend enough.

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

#159

Post by housecarpenter »

lmm wrote: post #125
cutler wrote: post #95

Earlier quoted context omitted.

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

> So decades of PHP+MySQL and Rails+PostgreSQL were simply misguided? To the extent that transactions were the point, yes (though there may not have been many alternatvies for a datastore to use when Rails was getting started). In the case of PHP+MySQL of course MySQL transactions were disabled by default in that era (up until 2010 in fact).

I'd be interested to hear why you think this, or if you can link to something that explains this perspective.

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

#160

Post by roflyear »

cutler wrote: post #96
roflyear wrote: post #64

Earlier quoted context omitted.

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.

I believe so. But, most startups like to use insane tech for fun, or something - though in my experience all it does is kill productivity.
Post reply on HN