Live data from Hacker News

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

gorelay.co

41–50 of 185 posts

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

#41

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 was as simple as running the JS server, rake db seed and then rails s. We used puppeteer to test FE, and rspec for the BE. Two test suites, but we knew if something was wrong.

That same place sometimes had a net outage, and I wouldn't even notice because I was running everything locally.

Now I can only get everything running locally with confidence, if I block out an hour or so.

Honestly... microservices are great in theory, but make dev a huge pain. Docker does not mitigate the pain.

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

#42
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…

Same here in e-commerce. We end up testing in production environments with an element somewhere that's in a development environment that can be tracked and actively watched. Amazon notoriously does not have a production environment, and eBay's is just unusable.

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

#43
post #39
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…

Worked with banking software before; it can be incredibly complicated. I worked on proof of concept infrastructure for a Websphere monolith that ran on AIX servers. It had at least 10-15 services it connected to and each one of those were huge Java monoliths, too. Some of those apps had 8+ copies of /each/ environment (8x dev, 8x test, 4-8x stage/uat, 1-2x prod) so you could do integrated tests without stepping on ot…

This works well. I've seen deployments where you have test1, 2, 3 etc, and you can "lock" the environment to yourself for a few hours.

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

#44

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.

NoSQL might not be the right term here. Maybe you mean "columnar databases"?

Ex Mongo sorts just fine, and can optimize sorting with indexes.

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

#45

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…

That's the reason why I walk away as soon as I hear "microservices". It's cargo-cult mentality where complexity and the issues you speak of above are considered a feature.

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

#46
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…

I agree. The last three companies I worked for were large health care companies. They spend millions on SaaS products.

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

#47
post #31
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

No. They use ADP, Concur, WordPress (check out AWS official blogs), Salesforce and third party SaaS products just like everyone else.

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

#48
post #21
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…

Yes, but.. I am a software architect. ~90% of the job offers I get are from CEOs/CTOs who want me to join their small company to help them refactor because they can’t grow anymore. Tech debt kills as well.

For every company that has this problem, another several never made it far enough for it to matter.

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

#50

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…

[deleted]
Post reply on HN