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

121–130 of 185 posts

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

#121

Post by DeathArrow »

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…

>Is this common at other companies that you cannot run the whole app locally to develop and test against?

It depends what you mean by the whole app. To reflect locally 100% of the conditions the big microservice app I am working on is very hard as I have to replicate locally multiple Kubernetes environments, Kibana, Data Dog, Elasticsearch, Consul and several databases and data stores.

What I can do, is to run one or more microservices locally, connected to remote development databases and speaking to other microservices and apps from some development Kubernetes environments.

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

#122

Post by avg_dev »

exdsq wrote: post #97
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…

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.

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

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

#123

Post by lobocinza »

tixocloud wrote: post #90
gumby wrote: post #66

Earlier quoted context omitted.

My gf works in UX for a major bank and they simply issued her a bank account in her name (with her SSN etc -- it's a real account, with ATM and debit cards and the like). If she and some co workers want to test something out relating to accounts they actually use these accounts to minimize this kind of problem. They must have some special code that says that these accounts can have their fees zeroed and probably are…

Previously led data teams in banks and you’re right. There are dozens of flags for test accounts. When auditing, we screen out these accounts. Of course, with a proper data cleaning process, analytics gets a lot easier

That reminds me of "Mostly Harmless" from Douglas Adams where Ford Prefect breaks into The Guide's offices and gets himself an infinite expense account from the computer system. That's a dangerous thing to have.

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

#125

Post by lmm »

cutler wrote: post #95
lmm wrote: post #87

Earlier quoted context omitted.

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?

> 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).

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

#126

Post by SheinhardtWigCo »

lobocinza wrote: post #123
tixocloud wrote: post #90

Earlier quoted context omitted.

Previously led data teams in banks and you’re right. There are dozens of flags for test accounts. When auditing, we screen out these accounts. Of course, with a proper data cleaning process, analytics gets a lot easier

That reminds me of "Mostly Harmless" from Douglas Adams where Ford Prefect breaks into The Guide's offices and gets himself an infinite expense account from the computer system. That's a dangerous thing to have.

Problem is, anyone with a good story to tell should really keep their mouth shut.

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

#127

Post by winrid »

FpUser wrote: post #102
winrid wrote: post #92

Earlier quoted context omitted.

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

Postgresql. No framework (well there is rather low level one of my own but it is fluid). Using 4 libs for JSON, postgres, HTTP, logging. I expose basically JSON based RPC. Peers / Clients post JSON commands and receive JSON replies. Upon startup all data (except couple of giant tables) is sucked from DB into RAM into highly efficient data structures hence most reading requests are handled in microseconds. Those 2 gia…

Nice! A lot of game servers are similar to this too, which you of course know. In my case I usually just "snapshot" the in memory structures to disk...

BTW for others considering this approach, the DB will do similar things that FpUser is doing in the app layer - keeping hot/recent stuff in memory. But when tail latency and cost really matters this is a good technique.

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

#128

Post by voidfunc »

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…

> Is this common at other companies that you cannot run the whole app locally to develop and test against?

Extremely. We can't replicate our entire infrastructure in development - it's simply too complex and expensive. We use a combination of dev, integration, staging, and canary environments plus pilot environments to gauge quality before a full worldwide rollout.

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

#130

Post by jillesvangurp »

For a great UX, great performance is actually important so that your UI does not block too long on requests that users notice. To get great performance, you need to do things right in your backend. It's not optional. If you do things right, it's going to be easier to scale what you are doing when the time comes. Those two are connected.

Usually where SAAS startups get into trouble is actually the UX and product market fit. There are a lot of successful SAAS companies with absolutely terrible UX. The reason they are successful is that the UX does not matter if what the software does is so valuable that companies want to buy it anyway. So, obsessing about a UX for customers that don't actually care too much may be a mistake. E.g. investing in native apps and tripling the number of frontend engineers you need for that is usually a mistake. Get the software in the hands of your customers quickly and learn whether it lives up to your sales pitch fast. Simple web UI and a simple backend with some conservative tech choices goes a long way. And that stuff is easy to scale.

A lot of SAAS software is bought by people who don't actually use the software themselves. These people buy based on a story and a promise; not the actual UX. There's this curious dynamic where you e.g. sell to the VP of sales who then makes his sales team use the software. The higher the price, the less the UX matters. That's why a lot of SAAS software is absolutely miserable to use: it's designed to make the boss happy, not users. This is also what represents a big opportunity: a lot of that software is not very well defended and can be disrupted with better products. And this happens all the time. But then those companies also end up selling to the same C-level executives and that software becomes less usable over time. Salesforce is the classic example. I've met sales people that hate that stuff with a passion but have to use it anyway. But they started out by disrupting that space.

Ironically, UX matters more if you don't have a remarkable product that is easy to copy. These products depend on easy purchase decisions by people lower in the org chart. Slack is the classic example that showed up in many companies because they had a freemium layer. And then those companies decided to pay up because they had a growing number of people using it.

So, that kind of product actually needs to scale early because it depends on a lot of users not paying anything before enough accounts start converting to paid accounts. Slack only managed that because they had lots of funding. Many companies would have run out of steam long before they could have succeeded.

Those users are going to be a lot more critical on the UX, and it's responsiveness and if the experience sucks, they'll be gone in no time and use something shinier. So, such startups will never break even unless they learn to scale before their runway runs out. For every cute little SAAS app that made it, there are hundreds of me too apps that never came even close to breaking even. Fail fast causes lots of companies to fail. Fast. Unless they can scale and grow. This is why investors are weary of B2C as well. Same scaling issues and it's a lot harder to get consumers to pay. And the UX is critical.

More traditional SAAS companies can afford to close a few big deals with a mediocre product before they have to scale. Mostly these companies keep on selling to bigger and bigger companies without ever needing to address their UX issues.

Post reply on HN