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

71–80 of 185 posts

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

#71

Post by Avshalom »

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…

right like any software deployed by Zebra is probably going to get used by every retail company and warehouse in the USA.

Now I don't know how much of the software on my TC26 actually comes from Zebra but, pretty sure, it's not zero.

ASSA ABLOY software is probably everywhere there's a door these days.

I don't know who the players in HVAC are but considering that a lot of HVAC/lighting control for like Target/Walmart are remotely controlled there's definitely somebody with tens of thousands of deployments.

Not to mention EdTech shit like BlackBoard, that gets deployed to every god damned school in the country

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

#72

Post by hatware »

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…

You can find developer first roles where the company puts a lot of time and energy into making developers the most efficient workers, but most companies are a cluster-fuck of resource management and you'll be lucky to find a healthy company that also puts developers first in this way.

In my experience, recreating staging as "production junior with caveats" comes down to cost and living with bad architecture/design. I'm not defending the practice, but I do think it's incredibly common.

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

#73

Post by bri3d »

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…

Quite common.

Usually someone develops a remote or mixed local/remote development environment which is easier to use than configuring the full stack to run locally, and then the ability to ever do so again atrophies until nobody can figure out how anymore.

In some companies I've worked at this is fine and not a major setback. In others, it's been a mess. I don't think that "can run the stack locally" is a good litmus test for developer experience - the overall development experience is a lot more nuanced than that. "How long does it take to get going again if you replace your computer" and "what's the turnaround time to alter a single line of code" are usually better questions.

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

#74

Post by travisgriggs »

cubes wrote: 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…

Is one of the problems though is that the early audiences appreciate this kind of over-engineering? If your investors/buy-in folks are being shown early demos and you mention "and this thing is gonna scale seamlessly up to 1,000,000 users because of tech words A, B, and C" then they get excited. They don't understand A, B, or C. But what they just heard is that you're planning for Big. And that stokes their aspirations.

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

#75

Post by acwan93 »

grogenaut wrote: post #58
acwan93 wrote: post #42

Earlier quoted context omitted.

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.

im pretty sure amazon has a production environment... just their staging is problematic. It's incredibly expensive to run a copy of prod and keep it up. You essentially have to get paged for it doubling your burden.

Yep, I mistyped. Amazon MWS doesn't have a staging/sandbox environment that's available for third party developers to test on.

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

#77

Post by ma2rten »

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…

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.

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

#78

Post by samsquire »

I want a scalable platform that can scale to zero and scale upwards.

Like Kubernetes cluster autoscaler and scaling individual deployments.

I want to be capable of running the same code on a 100KiB file as a 10000 petabyte datastore.

As it stands you need to write your application differently.

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

#79

Post by samsquire »

I wrote an simple YAML configured command line utility app that coordinates Vagrant LXC and Ansible so you could deploy any number of microservices locally

I wrote a cut down open sourced version which is far less advanced than the one I introduced to the DevOps team I was on.

HTTPS://GitHub.com/samsquire/platform-up

Paired with keepass2dir and secrets-login secrets-logout you can handle secrets too.

HTTPS://GitHub.com/samsquire/keepasscsv2dir

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

#80

Post by fasteddie31003 »

ma2rten wrote: post #77
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…

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?
Post reply on HN