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.
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…
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."
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.
> "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…
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.
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…
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.
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…
>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.
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.
I developed SAML/SSO integration for an application used by the Swiss UBS which initially relied on individual accounts, not even AD. Tricky stuff.
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.
You actually do need to have Enterprise security and authentication features if you intend to sell to Enterprise customers. (SOC2, OAuth, SAML etc)
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.
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).