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

111–120 of 185 posts

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

#111

Post by matt_heimer »

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…

A lot of it depends on the complexity and the technology stack.

Microservices based architecture with massive amounts of microservices and other service dependencies, its a pain to do more than local unit testing and mocks.

Are you using FaaS or a lot of other cloud features? Also difficult to fully test locally. Extract as much logic out of the cloud dependant code.

Often there will be sub-sections of large apps that can be run locally.

And if the only way to test is in production hopefully they practice some form of limited rollout so you can control who adopts the changes or similarly some form of optional feature flags that are used to enable the new behavior until it can become a new default. If their release model is "We are so good it goes live for everyone all at once" then that tends to make for a stressful release days.

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

#112

Post by scarface74 »

jamesfinlayson wrote: post #108
scarface74 wrote: post #38

Earlier quoted context omitted.

Why is it a big deal to run your app locally? You just give each developer access to a cloud account (either one account or one per developer) with wide enough guard rails. Heck, when I am in a place with bad internet, I spin up a Cloud 9 (Linux) or Amazon Workspace account (Windows) and do everything remotely. I’m not wasting my time trying to use LocalStack or SAM local.

It would be quicker for me to run things locally - in my team we all have access to an AWS account each but to test my code remotely I need to compile code, build my container, push my container to ECR then deploy the container to ECS - that last step takes minutes.

The micro service I was testing locally connected to remote services either via an https end point or via service discovery. It didn’t have to run in a container at all or be run remotely. If it communicated via messages, it simply read from or wrote to the queue using local IAM credentials.

If you’re developing locally to none public endpoints, use a VPN or develop within an IDE hosted on AWS behind a VPC.

Why does the app you’re testing run differently in a container than outside a container?

Standard disclaimer to expose my biases not to do the whole “appeal to authority thing”: I work in ProServe at AWS (cloud app development consultant). But I did the same thing when I was working in the real world. My specific job looks just like a senior enterprise dev + a shit ton of yaml, HCL, draw io diagrams and PowerPoint slides.

The other bias I have is that I work for the only company where I never have to worry about an AWS bill and I can spin up ridiculous remote EC2 based development environments when needed.

But I also didn’t have many constraints when I was the de facto “cloud architect” at a 60 person startup.

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

#113

Post by chupchap »

I think the author is drawing parallels between enterprise and data volumes that need to be managed. While that is a way to look at it, in my pre-sales experience it revolves around the complexity in terms of system functionality expected and the ecosystem of applications it needs to play along with. I would also add the importance of different ratings and certifications a system needs to have to make it enterprise ready along with its ability to meet varios legal requirements in each country it sells in. Example: GDPR, data residency laws, tokenisation for payments to name a few that a lot of tools still struggle with.

The expectation of the word scalability changes based on who you took ot: concurrent users, througput of data managed, data stored, processing time, system maintenance, feature extension, you name it. No system checks all the boxes 100% while still meeting the budget defined by a company.

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

#114

Post by jamesfinlayson »

scarface74 wrote: post #112
jamesfinlayson wrote: post #108

Earlier quoted context omitted.

It would be quicker for me to run things locally - in my team we all have access to an AWS account each but to test my code remotely I need to compile code, build my container, push my container to ECR then deploy the container to ECS - that last step takes minutes.

The micro service I was testing locally connected to remote services either via an https end point or via service discovery. It didn’t have to run in a container at all or be run remotely. If it communicated via messages, it simply read from or wrote to the queue using local IAM credentials. If you’re developing locally to none public endpoints, use a VPN or develop within an IDE hosted on AWS behind a VPC. Why does…

Unsurprising reasons for everything - security department would have been reluctant to allow development from inside AWS, and running in Docker was to ensure everyone (i.e. all developers, testers and TeamCity agents) were running on the same versions of runtimes etc (Docker was chosen as the easiest solution for this problem at the time).

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

#115

Post by bonestormii_ »

temp8964 wrote: post #82
clepto wrote: post #51

Earlier quoted context omitted.

I work at a VOIP services provider and we operate multiple brands which are companies we’ve acquired over several years. One thing that has rang true of every company we’ve acquired is that there is typically barely even a way to run one piece locally, let alone the whole thing. Some of these when I took over there wasn’t even version control, and they were being developed by FTPing files to production server or even…

> they were being developed by FTPing files to production server or even editing them live with vim or something. Many editors / IDEs (e.g. Notepad++) can directly connect to the FTP server, so working on a FTP servers looks almost same as working on a local folder. You just make changes to the files, and then refresh the web browser to see the changes.

lol, yes, sure. But why don't you sound horrified?

Version control at least is essential for something of any size with any number of people working on it. You must be able to "revert" a set of changes quickly and reliably if the application has any importance at all.

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

#116

Post by colechristensen »

dgb23 wrote: post #32
s1k3s wrote: post #21

Earlier quoted context omitted.

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.

Is that a "but" or is that how things should work? You solve a problem when you have it or can reasonably predict it (in technical/engineering terms). I also think it's sensible to look for experts when you need them right?

I don't know I've been places where the difficulty scaling and failure to do it promptly posed an existential threat. As in "this system is poorly designed and needs to be rewritten so we're going to pause new features for six months to do it", you can't always just magically find an expert to solve your problems in a timely manner, and feeding the technical debt monster can easily kill startups.

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

#117

Post by mieubrisse »

halfmatthalfcat wrote: post #53
nijave wrote: post #39

Earlier quoted context omitted.

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…

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.

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

#118

Post by inferiorhuman »

icedchai wrote: post #55
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…

In my experience, good local development environments are relatively rare. We had them at a couple of small focused on software, local environments seemed more of an afterthought. With increased dependencies on cloud services, "serverless" environments, etc. it can also be painful to run stuff locally. Obviously you can build around this (and should...) but it requires thinking ahead a bit, not just uploading your la…

Yaknow I actually transitioned from doing dev stuff to ops at a smallish startup. I was brought in to help with a green field rewrite. Eventually it became clear just how much of a mess the deployment environments were so I cleaned everything up and parameterized things so that when we went to stand up the new production environment it was quick and painless.

I got hired on at megacorp to do pretty much that with a suite of green field apps. And so I did, across a few apps and a zillion different environments because all of a sudden spinning up a new integrated environment was easy. The devs ran a lot of stuff locally but still had cloud based playgrounds to use before they hit the staging environments. Perhaps the best part though was having the CI stuff hooked into appropriate integrations, so even if you couldn't run it locally you sure as shit tested it before it hit staging. SOC2 compliance was painful for the company but not so much for us.

If you're sensing a theme with "green field" you'd be on to something. Even in a largeish company it's not so much the complexity as it is the legacy stuff that'll get you. Some legacy stuff will just never be flexible (e.g. the 32-bit Windows crap we begged Amazon to let us keep running) and even the most flexible software will have enough inertia to make change painful.

Tangentially this is also why I get apprehensive when I see stuff like that linux-only redis competitor.

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

#119

Post by scarface74 »

jamesfinlayson wrote: post #114
scarface74 wrote: post #112

Earlier quoted context omitted.

The micro service I was testing locally connected to remote services either via an https end point or via service discovery. It didn’t have to run in a container at all or be run remotely. If it communicated via messages, it simply read from or wrote to the queue using local IAM credentials. If you’re developing locally to none public endpoints, use a VPN or develop within an IDE hosted on AWS behind a VPC. Why does…

Unsurprising reasons for everything - security department would have been reluctant to allow development from inside AWS, and running in Docker was to ensure everyone (i.e. all developers, testers and TeamCity agents) were running on the same versions of runtimes etc (Docker was chosen as the easiest solution for this problem at the time).

Damn, I first got into AWS not just to avoid administering systems. But to also avoid system administrators.

That being said, how do you get on different versions if everyone uses the same package manager config file (requirements.txt/package.json/the wonderful system that Go uses/whatever Nuget/C# uses).

I’m also spoiled because I’ve never been in a position where I wasn’t the developer and leading the “DevOps” initiatives since working with the cloud - not bragging, I only opened the AWS console four years ago for the first time.

HN/Reddit is a good place to find out other peoples experience.

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

#120

Post by jasonkester »

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.

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.

Post reply on HN