[HN Gopher] You don't need to be "enterprise-ready" or "scalable"
___________________________________________________________________
You don't need to be "enterprise-ready" or "scalable"
Author : gmays
Score : 75 points
Date : 2022-05-31 19:07 UTC (3 hours ago)
(HTM) web link (www.gorelay.co)
(TXT) w3m dump (www.gorelay.co)
| taylodl wrote:
| > "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 FAANG.
| nijave wrote:
| >The buyer is typically a VP, a director, possibly C suite,
| depending on what you're selling
|
| If a company has VPs buying things surely they have some sort
| of internal vendor management that usually involves
| accounting/legal/compliance reviews. Being enterprise ready
| means you have the roles/documentation/process/procedure to
| answer those questions
| scarface74 wrote:
| I agree. The last three companies I worked for were large
| health care companies. They spend millions on SaaS products.
| throwaway892238 wrote:
| Although each of those companies is made up of 5 to 50 mini-
| companies, each with more business units/products/services. You
| have to understand which of them you're selling to, what they
| need, how they will use your product. Are two completely
| different tiny departments gonna hem and haw over trying your
| product, or will the whole org use your software? You might end
| up supporting a dozen users or 500,000. Will you still have to
| support the same features, or can the tiny teams get away with
| less? Is it even worth supporting the enterprise features if
| your product fit is smaller teams and you wouldn't get a large-
| scale contract anyway?
| polote wrote:
| And good luck selling enterprise software to Apple, Google and
| Facebook, they all already have some custom internal softwares
| for everything
| scarface74 wrote:
| No. They use ADP, Concur, WordPress (check out AWS official
| blogs), Salesforce and third party SaaS products just like
| everyone else.
| Mandatum wrote:
| Yeah, they know the "keep everything default as much as you
| can" rule better than anyone else with SaaS providers. What
| a load of gobshite.
| scarface74 wrote:
| Are you saying they should keep everything in house? I
| can tell you from personal experience that the external
| facing services from one of the major cloud providers
| handle spikes in traffic and has much better uptime than
| many internal systems.
| onion2k wrote:
| If you're selling enterprise software then the important number
| is not "number of employees" but "number of employees who would
| use your software". In large retail, manufacturing, oil etc
| companies they have a lot of software of course, but each
| person is typically accessing 4 or 5 apps at most (email,
| office suite, HR, etc). In FAANG companies each employee
| involved in software development is often using closer to 30
| apps (project management, comms, source control, bug tracking,
| telemetry, server management, i18n, etc). It makes sense to
| focus on FAANG companies if you're producing enterprise
| software simply because they buy more of it. That obviously
| doesn't mean there isn't a huge market outside of that _as
| well_.
| wereHamster wrote:
| 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...
| bee_rider wrote:
| 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 learning folks (since
| there's some overlap with Linear Algebra there) ever get their
| lingo mixed up.
|
| "To predict where the ridesharing customers will want to go, we
| will apply the taxicab norm to our database."
| adepressedthrow wrote:
| 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:
| https://en.wikipedia.org/wiki/Normalization_(statistics)
| jsiaajdsdaa wrote:
| 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.
| winrid wrote:
| NoSQL might not be the right term here. Maybe you mean
| "columnar databases"?
|
| Ex Mongo sorts just fine, and can optimize sorting with
| indexes.
| twblalock wrote:
| That's not a scale problem. That's a problem of database
| choice. Cassandra is not good at that sort of query pattern at
| any scale.
| FpUser wrote:
| I've delivered custom backend business servers to a various
| businesses of healthy size. Almost all were deployed on rented
| multicore servers with gobbles of RAM from Hetzner / OVH / etc.
| Some running for many years already. Not a single one required to
| be "enterprise scaled".
|
| Granted all servers are C++ and talking to a local DB. No
| problems in processing thousands requests per second without
| breaking much sweat.
| jsiaajdsdaa wrote:
| You actually do need to be scalable if you intend to serve more
| than a few thousand concurrent customers.
| wildrhythms wrote:
| What an aesthetically pleasing website!
| yarg wrote:
| Though it helps if you design your software in a manner which
| allows for drop-in replacements to non-scalable parts of your
| design.
| halfmatthalfcat wrote:
| Great use-case for GraphQL, unironically.
| robertlagrant wrote:
| This is absolutely it.
| cubes wrote:
| 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 footnote in internet
| history.
| bryanrasmussen wrote:
| >With that said, you need to be prepared to scale up quickly
| once you have this problem.
|
| See I interpret that to mean that you should design for scale,
| but not implement or invest in scale until needed.
| s1k3s wrote:
| 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.
| icedchai wrote:
| For every company that has this problem, another several
| never made it far enough for it to matter.
| dgb23 wrote:
| 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?
| bigtones wrote:
| You actually do need to have Enterprise security and
| authentication features if you intend to sell to Enterprise
| customers. (SOC2, OAuth, SAML etc)
| bob1029 wrote:
| I am on calls all week with our banking clients about getting
| SAML/SSO squared away once and for all.
|
| We are having a lot more nervous takes around legacy LDAP/AD
| auth mechanisms these days.
| dt3ft wrote:
| I developed SAML/SSO integration for an application used by
| the Swiss UBS which initially relied on individual accounts,
| not even AD. Tricky stuff.
| formercoder wrote:
| I did SAML with Barclays years ago. The hardest part was
| getting someone there to click enable for our app. They'd
| never reply to my emails so I called them until they picked
| up. Then it was done in 30 minutes.
| ozim wrote:
| I agree with article because you don't need to have it to
| "start talking" with Enterprise customers.
|
| You probably have to prove that you have these on your roadmap
| and that you have engineering team that can implement these in
| not so distant future. That you know these things exist and
| have will to invest in it in future.
| haswell wrote:
| These capabilities are increasingly required just to get in
| the door, depending on your target customer.
|
| The alternative is that your product becomes a security
| exception, which infosec teams are more and more unwilling to
| grant, for pretty good reasons.
|
| The good news for product teams is that there are more and
| more off-the-shelf options that can be quickly integrated vs.
| having to start from scratch.
|
| But the main point of this comment is: I think you're right
| that "near term roadmap" was good enough a few years ago, but
| less so now, and continuing to trend towards "not acceptable"
| if selling to enterprise customers.
|
| (Observations as a recent/former auth PM at a SaaS/PaaS that
| sold primarily to enterprise customers).
| JacobThreeThree wrote:
| It's true. These types of security certifications like SOC2 are
| quickly becoming a minimum requirement.
| pid-1 wrote:
| You actually need OAuth / SAML if you give 2 shits about your
| customers.
| GauntletWizard wrote:
| You need OAuth and not to use SAML. Saml is insecure by
| design: https://joonas.fi/2021/08/saml-is-insecure-by-design/
| corobo wrote:
| Maybe not quite enterprise ready but if you have any tabular data
| anywhere it's helpful to have an export to csv option. Business
| folk do love their Excel :)
| kodah wrote:
| I like the article, but overall I think it's the same advice as
| "start small, limit scope, be ready to pivot" with a dash of
| "don't make enterprises an early customer". I obviously
| paraphrased quite a bit.
|
| What is glaringly obvious from this article is that "enterprise"
| in this industry has lost much of its meaning. It's almost
| ubiquitous with "medium+", which I think is a self-defeating
| definition that starts to make sense only when you look at what
| features are commonly gatekept behind enterprise distributions of
| software.
| fasteddie31003 wrote:
| 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 intorduce many bugs without
| testing locally. They response was along the lines that they
| hired good engineers that could understand all the complexity
| before deploying new features.
|
| I believe having a solid development environment where you can
| develop and test the whole stack is key to making reliable
| software. Is this common at other companies that you cannot run
| the whole app locally to develop and test against?
| icedchai wrote:
| In my experience, good local development environments are
| relatively rare. We had them at a couple of small <10 person
| B2B, SaaS startups I was involved with. In larger companies,
| there were just too many pieces to run everything locally. Or
| in companies with software development, but not _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 lambdas
| to AWS and editing them there...
| bob1029 wrote:
| > 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 entire strategy.
|
| What we ultimately had to do was negotiate a way to test in the
| production environment in such a way that all the activity
| could be tracked and backed out afterwards. A small group of
| important customer stakeholders were given access to this pre
| production environment for purposes of validating things.
|
| This is something that has never sat well with me. But, the way
| the business works the alternatives are usually worse (if you
| want to survive long-term, that is). We wasted 18 months
| waiting for a customer to have a test environment installed
| before we learned our lesson about how bad those environments
| are in reality.
| nijave wrote:
| 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
| other people or something software (software B might have a
| dedicated test environment of software A)
| winrid wrote:
| 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.
| halfmatthalfcat wrote:
| 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.
| acwan93 wrote:
| 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.
| grogenaut wrote:
| 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.
| asd88 wrote:
| I work at a company that has similar practices to what you
| describe (we don't run our services locally). While it's hard
| to get used to at first, I think the silver lining is that it
| forces everyone to write good unit tests, since it's the only
| efficient way to run their code before publishing a PR. Having
| worked on the opposite end (at a team where we mostly tested
| locally and had almost no automated tests), I much prefer this
| environment.
| scarface74 wrote:
| 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.
| [deleted]
| bin_bash wrote:
| Local dev is great until production gets complex enough that
| you lose parity. That'll happen even earlier now that we run
| x86 on the server but ARM locally.
|
| At my company we don't support local dev nor have any sort of
| staging environment. We have development linux servers
| connected to prod services and dbs. There are no pragmas or
| build flags to perform things differently locally. Things are
| gated with feature flags.
|
| It scared me at first but now I think it makes sense: staging
| is always a pain and doing it this way we avoid parity problems
| between staging and prod. Local development would be impossible
| for a system at our scale but I think even a staging setup
| would result in more defects--not fewer.
| clepto wrote:
| 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 editing them live with vim or
| something. Certainly no reproducible containerization or even
| VMs to speak of.
|
| I agree completely with you about having a solid development
| environment. I've spent the better part of a year creating such
| a thing for some of the brands, and it has increased our time
| to ship features and fixes probably ten fold.
| roflyear wrote:
| Extremely common. For some reason it is cool to put stuff in
| lambda or azure functions or whatever. Or to use 11 different
| stacks.
| nijave wrote:
| Yeah, once you have more than a small handful of dependencies
| (SaaS, databases, microservices). Some of the stuff I worked on
| will have built in stubbing/mocking so you can run parts of the
| stack locally and the test suite also uses the mocks/stubs.
| john_the_writer wrote:
| 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.
| Nextgrid wrote:
| 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_.
| encoderer wrote:
| You don't need 90% of what you think you need before launching a
| product.
|
| We didn't have a "change email address" flow for two _years_.
| Instead we focused on the product. That's what buyers really care
| about.
|
| You need this stuff eventually - SAML included -- but not before
| you launch and refine your product.
| throwaway892238 wrote:
| Well it depends on what you're selling! Design for what you truly
| want to sell, and that will end up however it needs to end up,
| whether that's enterprise or not. This random blogger, and our
| random comments, can't tell you what you need. It has to emerge
| from the product development process like a sculpture from a
| block of marble.
| tnr23 wrote:
| Exactly this. It sounds easy but this type of creator who can
| do this is very rare but usually has a high success rate. This
| should be the defintion of the "10X dev"
| capkutay wrote:
| I wonder if a recession or bear market environment will quickly
| make this type of advice - that worked well for the 2010s boom -
| obsolete in a harsher climate. Might be hard to scale your go-to-
| market by depending on startups who don't want 'enterprise-ready'
| features to spend money on your product.
| darkstar_16 wrote:
| I think enterprise ready here refers more to scale than to
| features. People try and go the microservices, distributed DBs,
| hyper scale route way too early rather than focussing on their
| product, possibly building it as a monolith with simpler SQL
| DBs before going all out.
___________________________________________________________________
(page generated 2022-05-31 23:00 UTC)