> > it's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them.
> I'm tired of companies with API endpoints that leak data like a sieve. This is why companies need some skin in the privacy game.
There is a world of difference between “untested” and “insecure” API endpoints. What seems to have been cut in the example isn’t a permissions model, but some form of automated integration testing.
I’ve seen horribly insecure APIs with 100% code coverage, and I’ve personally burned myself on untested API endpoints where the privacy implementation was _too_ restrictive for what my customers were trying to do.
Ostensibly based on what I said, yes. But in reality, he was right that untested meant partially insecure. There are real costs to tech debt. But it's hard to argue against a giant raise.
I've worked with Firebase Hosting for around three years, using Firebase Functions instead of Cloud Run, but in your particular example, you can configure your Firebase Hosting to rewrite requests against your Cloud Run instances as documented in https://firebase.google.com/docs/hosting/full-config#rewrite....
This doesn't require handling an OPTIONS request for every endpoint, which I agree could be fairly simple, but Firebase Hosting configuration could very well be less invasive than this change in the rest of the codebase.
Meta might not be legally able to buy “the next big thing” in international markets. Neither the EU nor the US are particularly “friendly” to them right now, and pretty much anything Meta does in the social media category is going to run up against anti-trust regulation.
Instagram was probably the last time Facebook could have gotten away with that sort of thing in the North American and European markets. I’m being cautious to only include those markets because I’m not familiar with the regulatory environment elsewhere.
> No deadlocks, races, etc to worry about because lock graph concurrency is complicated.
I’ve spent the last two and a half years mainly programming in single-threaded NodeJS environments with a focus on heavy same-task concurrency, and I’ve still run into deadlocks and races, despite the lack of OS threads involved.
However, your point that context switching is expensive, and is why thread-per-core architectures are so common, still holds.
> Even simpler: do not upload copyrighted materials to Dropbox, Google Drive, etc.
As the article illustrates, it’s not actually that simple. Cloud services that terminate accounts (and probably instantly delete everything, to comply with GDPR, CCPA, etc.) for perceived copyright infringements will always and necessarily suffer from a false positive rate.
We’ll likely never truly learn what this false positive rate is, but that it will always exist is reason enough to give pause to the thought that services should “just terminate their account” if they think it’s infringing on intellectual property laws.
The only good answer here is an unqualified “Use a local backup”. The terms of use for non-business cloud storage absolve the providers of all responsibility for data loss, even when they have incorrectly taken punitive action against you.
I only have experience with GCP’s Cloud Functions, but in that environment, “serverless” is only cheaper than virtual servers if your load can’t saturate the lowest end VM GCP has to offer.
Once you have enough load to justify going “unserverless” the prices drop to approximately 1/4 that of Cloud Functions for the same burst performance, and that’s before playing billing games like long-term commitments or using preemptible instances.
What’s truly scalable about “serverless compute” versus VMs is the line item on your bill. Sure, “they manage the auto-scaling” but for the per-unit price you rapidly hit a point where you might as well set up a Kubernetes load balancer and eat the setup costs. The pricing model only works out in your favor if you _don’t_ have load.
It would not surprise me to learn that the same is true of AWS prices.
> The people running the company were playing with fire and they must either be too junior themselves to understand that, or they were just knowingly doing so and hoping to get whatever product MVP they had planned as quickly as possible with the minimum amount of expenses possible.
Knowingly playing with fire like this is a sign of a lack of maturity, both on the founders part and the investor’s part. Anyone experienced in the business of building software would have known that:
1. It takes time
2. Time takes funding
3. It’s probably not going to work the first time you try an end-to-end test
Mature founders would have found mature investors to give them both the funding and the time to stabilize the software. They would not have attempted to make their investor demo the first big end-to-end test, and even if they did put off testing they would have communicated that to the investors, who should have understood the state of their investment only six ~months~ weeks in.
Actually, no, the #1 job of the CEO is "do not run out of money".
But, I agree that this CEO sounds like a complete cowboy. Not preparing properly for an investor meeting is ridiculous, and with that attitude, this CEO will probably run out of money sooner or later...
I suspect the author of this article will be much happier in her new job. Hopefully she knew what kind of work environments to avoid after this experience.
The CEO should not be presenting the app in the first place. Product demos should be done by someone who knows the product inside and out, knows where the unfinished bits are (if any), and has experience presenting products to investors/buyers.
Have to disagree on this a bit. The meeting in question was with an investor. The CEO should be the point person for all investor relations... especially the first meeting with said investor.
If your CEO can’t ‘sell’ the product / app/ company to an investor effectively, you won’t last.
The CEO should absolutely have the skills, knowledge and energy to sell whatever it is your business does
Oh of course the CEO should be involved with the investors, at a business level. I'm saying the CEO is not the best person to actually do the demo, in most cases. Bring along a product and sales expert to the meeting do that. Steve Jobs is the exeption that proves the rule; most CEOs do not have his showmanship.
This reminds me of the WWDCs. Tim Cook is there to introduce the products, but their engineers (or management of the individual product) are the ones to demonstrate it.
But, I guess Apple probably has people with better salesmanship skills in each product team than the startup had below the CEO. I'm arguing with myself.
Take a look at the presentation of the original iPhone. It was presented (if I remember correctly) by Steve Jobs himself. But he knew exactly which buttons to press in which order, because otherwise the phone would crash.
I think such an important presentation may/must be done by the CEO, but he must exaclty know that to do and he must prepare very well.
You can let the CEO handle the overall presentation and let someone else do the demo. The CEO should focus on the overall picture and selling it as a product, while a more technical person should do the demo. I have seen this multiple time in presentations.
> Knowingly playing with fire like this is a sign of a lack of maturity, both on the founders part and the investor’s part.
It doesn't matter really whether this is or is not knowingly.
If you are CEO and you don't know something (because you have never had any experience in IT, for example) it is your job to find people that do and give them tools to do their job well enough.
But you would not run a company without at least some experienced accountants or lawyers, I would assume any thinking person should be able to predict the same goes for software developers.
I think the comments here taking the religious references at face value are missing the point.
> This document was [...] created for the purpose of filling in a box on "supplier registration" forms submitted to the SQLite developers by some clients.
> [The developers of SQLite] have pledged to govern their interactions [...] in accordance with the "instruments of good works" from chapter 4 of The Rule of St. Benedict [...] This code of ethics has proven its mettle in thousands of diverse communities for over 1,500 years, and has served as a baseline for many civil law codes since the time of Charlemagne.
> The Rule of Saint Benedict (Latin: Regula Sancti Benedicti) is a book of precepts written [...] for monks living communally under the authority of an abbot.
The explicit purpose of the document is further clarified in the third paragraph.
> This document continues to be used for its original purpose - providing a reference to fill in the "code of conduct" box on supplier registration forms.
As of 8:06:07 AM PDT, all of my Firebase projects in us-central1 are back up.
We saw a complete silencing of our highly used Cloud Functions between 7:15 AM PDT and 7:38 AM PDT, but had reports from our users as early as 7:10 AM PDT.
My favorite part about https://status.cloud.google.com/incident/zall/20005 is that 7:49 AM PDT's update acknowledges that customers can't create support requests. Not like they'd do anything. Every time we've gone to GCP support, we've been unhappy with excessive back-and-forth, non-responsiveness on the part of the responsible parties, and generally extremely long durations between "we are completely down" and "everything would be fine had you not hacked around our incompetence three days ago".
Maybe this is a "grass is greener" sort of thing but I can't imagine AWS is this unreliable. This is the third major GCP outage we've had this year, and last time (not even three weeks ago!) it was three hours long.
> Every time we've gone to GCP support, we've been unhappy with excessive back-and-forth
Exactly this! I love GCP (especially firebase functions), inspite of these service disruptions. But, I can't deal with GCP support. They are unbelievably incompetent and have no understanding of the problem or solution. I feel like paying for support only to waste my time - explaining my problem to them with no hope for a solution.
Though their timing is incorrect. We noticed this at 9:26 AM EST and their posting says it "started" at 10:11 AM EST.