I believe the it's over because tech X has thinking is at best lazy and at worst dangerous. It implies that the everyone's requirements are the same and static and that solution X has reached all of those requirements.
If people blindly accepted X has won we'd be still using Perl, XML, CGI-Bin, Apache, Angular, etc. As another comment has said, I believe years from now, folks will be looking back at in disbelief at how anyone could have considered k8s to be the best solution without room for improvement or alternative approaches.
Every discussion around subscribing to a SaaS vs. operating it is always reduced to costs on HN. There is another, more critical aspect to why we (and many others) operate their own infrastructure, run their own servers, operate their own Elasticsearch clusters: Keeping ownership of customer data for business continuity and compliance purposes.
That is exactly my worry. It's hard enough as it is with VPN / IP detection, headless detection, Captchas, etc. WEI would probably mean game over for all but a handful of Google-sanctioned bots.
I would say that you don't absolutely need a service like urlscan.io to look at a single suspicious URL, but running a URL through our sandbox will create a point of time snapshot that you can share with others, compare to existing scans and use as evidence for further actions like takedown.
CEO of urlscan.io here: We will be evaluating the use of captcha bypass services soon, we are fully aware of the growing problem of captchas being abused by threat actors to hide their malicious websites from automated analysis tools such as ours.
It's honestly a frustrating problem as we're effectively in an arms race with the likes of Cloudflare, Google et al, and we're in the same boat with less reputable services like scrapers and bots. The recent developments around Web Environment Integrity are concerning to us for the same reasons. Feel free to reach out with any questions or suggestions you might have!
As someone who has built a business on browsing certain website using Chrome in headless mode this proposal worries me, and it has the potential to destroy large commercial segments of other similar companies.
What I've seen missing in these discussions is what happens with Headless browsers. Yes, these are used a lot for scraping, but there are also many legitimate use-cases. If the Web Integrity API is available to everyone then you can effectively no longer use Headless Chrome to browse to any of these pages, or am I missing something?
I disagree. I'm not saying saying that I'm a 10x engineer, but I've sometimes found myself working with folks who feel like they're a 0.1x engineer, so compared to them the 10x difference still applies.
It's not that they were worse engineers or less intelligent or anything like that, it's just that they would opt for the unnecessarily complex decision at every step of the way, and seemingly in other aspects of their life as well. The kind of folks where you find yourself saying "Why don't you just ..." constantly.
I imagine a 10x engineer as someone who can consistently identify the fastest, cleanest and least complex way to get from A to B, reliably, in different situations professionally and personally. That includes making quick decisions and tradeoffs. These people do exist, they get stuff done, and some folks don't want to acknowledge it because they don't want to be seen as the 1x in comparison.
Same here. We run a very content/media-heavy SaaS SPA application completely out of a single location in Germany and have customers that are primarily located in the US, and also in places like Australia and Japan. We don't use any CDN, every request has to go to our origin in Germany. Yet customers regularly tell us how fast and snappy our application is. Why? While we do make dozens or even hundreds of requests per page navigation in the SPA (images, XHR), these are all fired off in parallel, and none of these are blocking anything. A CDN would probably improve things slightly, but currently we don't feel like we need it.
It's funny to hear this in this context. Fly is treated as one of the few potential successors to Heroku, and Heroku raised very little money while remaining the number one choice for most devs here (based on sentiments). And then an existing corporation with tens of billions of free money came along, bought Heroku ... and ran it into the ground. So I don't buy that you need to fundraise or else be outpaced, at least not by big corporation.
It doesn't use up too many resources, but I still don't like having more than 50% of the user database be essentially spam. If you ever want to sell your company you want to have somewhat accurate numbers of actual user registrations. Ever since I realised the extent of the issue I have become very doubtful about reported user counts from startups. In our case the only reason we've realised this is spam is because we annotate signups with GeoIP and also allow users to fill in a name and title which will then be something like "find escorts in Chennai" and the signup will be from India etc. If you only look at the email addresses all you'll see are many gmail addresses with western names, so you might be fooled into thinking that all of these are legitimate users.
I've been thinking about converting a legacy application which uses UUIDv4 to use ULIDs instead going forward, but then to represent these ULIDs in a format that is compliant with a UUIDv4. I have not thought through the possible downsides, but I think it should be a pretty straightforward change. Of course old records will remain true random UUIDv4s, but at least new records will be time-order and as such will create less stress on the B-Tree index when writing them.
I don't know. I run a SaaS that allows free user signup and significantly more than 50% of my daily signups are just signup "spam", without any visible motivation for doing so. The user name or information doesn't show up anywhere publicly and there is no inherent value in having a free user account. I've implemented some basic countermeasures (dummy form fields which reject the submission) which wasn't enough. I've added reCaptcha, and I'm still getting 50% spam signups from working (!) gmail addresses, meaning someone is able to receive emails on these. The majority of these are from places like India, Bangladesh, Vietnam, etc.
I don't event want to know what my site would look like without my own countermeasures + reCaptcha + if it was a service where a user account has any kind of "value"...
This is a great point. People use Caddy because for simple cases the configuration is seemingly "easy", and more importantly it includes Let's Encrypt out of the box. I've tried to argue with these users that nginx has many powerful (and necessary) features, to no avail. Traefik is a similar story: It integrates neatly with Consul for service discovery so it's a go-to tool for TLS termination in front of a service mesh.
Do I personally need DNS SRV support? No, I have a templated Nomad config that will re-render and reload the nginx config if the consul upstreams change. Setting this up though is definitely a bigger hurdle than just specifying a Consul service as an upstream.
I'm just daydreaming here, completely understand they have a business to run and they probably thought long and hard about which features to put into which license. No criticism intended, just something that eventually might catch up on them if another http server/proxy can offer everything that nginx does plus the missing items.
And, come to think of it, some additional great features would be automatic TLS certs via Let's Encrypt and maybe even being able to use a shared cache with multiple instances of nginx.
I still love nginx, but it's a damn shame they gate some really useful features behind their nginx plus license, namely service discovery via DNS SRV records, cache purge requests and request queueing for upstreams.
Not really, I've been operating 10+ node Elasticsearch cluster for years, running on a workload scheduler (Nomad). I never have to perform any maintenance or housekeeping except deleting old indices, and updates are performed by bumping a container version number and then restarting nodes one-by-one with a delay in between.
For the same reason you have money going to various SQL-as-a-service companies that run Postgres / MySQL for you as a service: Some folks would rather eat the network latency, give up control of their data and complicate their compliance process than operating a database themselves.
Try sleeping with earplugs. I started doing it out of necessity, and it was awkward at first, but once I got used to it was really life-changing. Sleeping with plugs in feels like being embraced by silence and darkness, so much so that you can sleep the whole night through and feel more refreshed in the morning.
We're doing this with our monolithic Node.js / Express application as well, but I wasn't aware that it's a common pattern. For us having a monolithic app greatly simplifies development, deployment, updating dependencies, shared code, etc. Just having a single set of third-party dependencies to update makes things so much easier.
We're running ScyllaDB on Docker via Nomad and it's been an absolute breeze. One simple container with a handful of open ports. I don't get what's complicated about ScyllaDB deployment.