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

161–170 of 185 posts

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

#161

Post by roflyear »

cutler wrote: post #154
jasonkester wrote: post #120

Earlier quoted context omitted.

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.

Not entirely true for many apps. The app I work on does not need a working mobile site, because we don't think our consumers are going to use it on mobile.

However, we do very much care about our UI - and I think react at this point helps with that. But I don't think React complicates the stack too much. It may even make things easier, tbh - I don't have to test pages on backend tech, just endpoints.

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

#162

Post by roflyear »

lmm wrote: post #86
roflyear wrote: post #61

Earlier quoted context omitted.

Local dev isn't the end, it is the beginning. With it it allows you to get further than you would otherwise - and most importantly, when (not if) you do discover a problem on a lower environment (or prod) it gives you a place to try and replicate it. You run everything locally so hopefully you can make a change to mirror the problem... Not a guarantee but at least you have a good starting point. Also your local dev s…

Yep. This is one reason I've always ran linux on my dev machine anywhere that would let me - sure, there shouldn't be any difference between OSes, but otherwise it's one more place for differences between dev and prod to creep in.

As a Python developer, yes, there are differences - and those differences are sometimes a huge PITA.

The only reason I don't run Linux is due to other MS tech - Teams, Outlook, and primarily office products.

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

#163

Post by sage76 »

raffraffraff wrote: post #140
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 at a company that works like this, and it's awful. There are also anti-patterns around git branching and container deployment. The staging environment is broken every other day and production deployment requires the full time effort of a very senior engineer who cherry-picks through git commits from one branch to the production branch (there are thousands of differences between these branches). I'm honestly done…

I'm sure that paradoxically your company must have sky high hiring standards, with interviewers particularly grilling candidates about best practices?

This is not even sarcasm.

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

#164

Post by avg_dev »

exdsq wrote: post #144
avg_dev wrote: post #122

Earlier quoted context omitted.

Can you elaborate on the blockchain testing environments/CIs thing please?

Sure! So when testing you want a deterministic environment - starting from genesis, couple accounts, the ability to build or wipe state, etc… sometimes projects use multiple chains, so maybe Ethereum and Polkadot along with a bridge between them. Building this out in Docker, managing it in CI, and building a test framework to allow devs to easily complete actions like sending a tx or waiting for an event to occur in…

Wow, that's fantastic.

So basically: unit test fixture setup spanning multiple external services ("Chains?") in a scriptable build, with various common/comprehensive/programmable interaction flows, and then integrating with CI? I'm making some guesses here as I'm not very familiar with the space.

I think it's amazing that you have (had) made this into a career. I am a dev and spent a couple years as a QA developer. Do you think this is a space I could break into? (Decade plus of development experience plus the good fortune of growing up with a mother who was a software developer. I learned to code (badly) when I was 13. I'm more than double that age now :)

If so, I'm wondering if you'd be up for chatting some more like on IM (Google Chat or Whatsapp or whatever) to elaborate further if you think this is still a viable proposition for someone new. I'd be happy to pay you for your time if you think this could make me money. I know how to set up CI, I'm vaguely familiar with bitcoin (I used to own some), and I don't care for cryptocurrency but I'm happy to meet market needs with a smile to pay the bills and then some.

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

#165

Post by avg_dev »

avg_dev wrote: post #164
exdsq wrote: post #144

Earlier quoted context omitted.

Sure! So when testing you want a deterministic environment - starting from genesis, couple accounts, the ability to build or wipe state, etc… sometimes projects use multiple chains, so maybe Ethereum and Polkadot along with a bridge between them. Building this out in Docker, managing it in CI, and building a test framework to allow devs to easily complete actions like sending a tx or waiting for an event to occur in…

Wow, that's fantastic. So basically: unit test fixture setup spanning multiple external services ("Chains?") in a scriptable build, with various common/comprehensive/programmable interaction flows, and then integrating with CI? I'm making some guesses here as I'm not very familiar with the space. I think it's amazing that you have (had) made this into a career. I am a dev and spent a couple years as a QA developer. D…

And here's another thought. I know very little of the space, again, but I've seen some headlines about smart contracts going wrong.

Do you think there's any space for low hanging fruit simple auditing of smart contracts? Maybe a linter?

EDIT: Here's what Ethereum suggests: https://consensys.github.io/smart-contract-best-practices/se...

In particular,

https://github.com/protofire/solhint/blob/master/docs/rules....

https://github.com/protofire/solhint/blob/master/docs/rules....

https://github.com/prettier-solidity/prettier-plugin-solidit...

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

#166

Post by bee_rider »

adepressedthrow wrote: post #33
bee_rider wrote: post #22

Earlier quoted context omitted.

This completely tangential, but any time I see someone talking about normalizing a database, I briefly think they are talking about doing something like: x/|x| Ya know, like normalizing a vector. Of course this brief confusion doesn't matter, I sort it out quickly, and it is totally clear language to other database people -- it is just a funny quirk of overloaded lingo. But I wonder if as big data and machine learnin…

While the overloading is annoying, database normalization actually has a strict definition that is not unlike the standard mathematical use; that is, to imply consistency (to make normal): https://en.wikipedia.org/wiki/Database_normalization I would also point out that normalization within mathematics does not have a single concrete definition either, and it depends on your domain and desired property to stabilize: h…

Just to be clear -- I'm not annoyed really, I actually find these little momentary confusions to be a charming little quirk of our language. And I think it is not a big deal anyway, 99% of the time we're talking inside our fields where it is obvious what we mean.

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

#167

Post by smokey_circles »

The title made me expect some argument about endlessly spinning up cloud resources, which I was ready to pull apart.

Instead, I found an argument about not building v1 with unnecessary optimizations.

Which I agree with but I didn't find anything new being said here.

What I've found _is_ worth investing in early on is measurement and metrics. No more blind changes, go look at the data and draw testable theories out of it. Huge quality of life improvement.

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

#168

Post by dub »

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.

Scalable relational storage is relatively new to industry consciousness (outside of Google, where Spanner is used for nearly everything).

Spanner and Vitess existed at Google in the early 2010s. It was mid-to-late 2010s before CockroachDB, TiDB, and Vitess were available as open source.

Battle hardened database administrators who've been working with traditional unscalable databases for decades often aren't up-to-date with what's possible today unless they frequently talk shop with peers at other companies or go to conferences.

Personally I hope old databases like MySQL and PostgreSQL die out within the next decade. They served us well, but they're 25+ years old and the weight of legacy code plus the need for backwards compatibility is a huge drag on their ability to evolve.

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

#169

Post by mbrodersen »

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…

Microservices are not even great in theory if you spend just a bit of time deeply thinking about the complexities that microservices introduce compared with simply using libraries/modules to organise your system.

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

#170

Post by mbrodersen »

polote wrote: post #31
taylodl wrote: post #2

> "So unless your product legitimately only sells to the likes of Google, Facebook, and Apple, you probably don’t need to be 'enterprise ready'" What in the actual fsck? Check out this list of companies ranked by the number of employees they have - https://companiesmarketcap.com/largest-companies-by-number-o... . Okay, Amazon is #2 - but notice the top 100 doesn't include Apple. There's a lot more to business than FA…

And good luck selling enterprise software to Apple, Google and Facebook, they all already have some custom internal softwares for everything

Nope. Microsoft (for example) use SAP. It would be crazy for them to spend millions building something similar to SAP.
Post reply on HN