The asset was created in-house by our design team custom for our website (not outsourced or a template) and was copied identically. The asset itself is a small thing, but the denial of something which is materially provable seemed very odd to me, hence my reply!
I think it's a bit strange to reply directly that you did not plagiarise any images when the opening table cell background is a direct lift of the SVG from our site...
At work we do some pretty significant parallelised computation (using Node and Rust) and that has equivalent performance to a relevant python based library.
There are nuances to how data enters and exits the VM runtime which means I couldn’t say with confidence if performance would be better or worse in the general case - but either direction is at least technically viable.
Native bindings can use libuv to offboard work to other threads and then re trigger the JS execution when it completes.
This is how a lot of the native node libraries work under the hood to allow parallel IO operations! It’s also an incredibly powerful performance optimisation tool in more complex, scale out NodeJS deployments.
I think this is definitely the primary challenge with building great, modern enterprise software. You need the flexibility to meet the various demands of differently shaped businesses but the trade off is complexity.
I personally think that we've come a long way with no code tooling and UI these days which makes these problems easier to tackle well - but it's a constant battle.
The comments here have mainly focused on the issue of instant suspension - which is obviously deeply concerning - but I also feel like there is a huge issue at Cloudflare regarding their Enterprise pricing model.
Cloudflare's sales team and Enterprise pricing model are one of the least effective sales organisations I have encountered in this space. Given the technical nature of their product, it's extremely hard to explain even basic uses of the tool and things like Workers are near impossible to discuss with them. I was really unsurprised to see that OP had a failed Enterprise negotiation with them as I have had the exact same conversation at three different companies now and can imagine perfectly what you were told.
The current offerings of Enterprise and Enterprise Lite simply do not map to the reality of how people use the tool and scale businesses on top of it. I think in part due to Cloudflare's history essentially selling bandwidth and caching, the model is fixated on high binary traffic workloads and simply cannot comprehend the SaaS service model that runs on it and tools like Workers.
This is mostly a rant and hopefully a small +1 signal that this area needs major improvement - but I would also love to hear if anyone else has had interactions with Cloudflare Enterprise and how they found that process?
(Disclaimer: I'm a massive fan of Cloudflare, a user of their products and hold their stock)
We moved from Heroku to GCP after approximately two years of using Heroku. (This was three years ago so some information may have changed)
The move worked out incredibly smoothly and has saved us money and allowed us to "modernise" our infrastructure to take advantage of some of the newer trends in Infrastructure and Security.
To address your direct questions:
1. Not very long. We were running a NodeJS app with a web layer and several background workers. We were able to get this running on a Google Compute Engine VM in about 1 day using Packer. The whole migration process took about two weeks start to finish.
2. Our team is relatively experienced and had experience with all three major platforms and Kubernetes (although we chose not to use Kube in this case). We are definitely a team of developers, not sysadmins though. This means we had to learn some new things particularly about tuning NodeJS apps on raw linux.
3. I don't think we learnt too much (other than the undocumented rough edges of both platforms) but it was definitely worth it for financial and quality reasons.
4. It's a relatively hard metric to calculate when the company is growing user base and features quickly - but I would estimate it at around 50%.
5. 1 app with around 5000 requests per second. NodeJS / Typescript / Rust
6. If you have only ever used Heroku I think it would be worth getting comfortable with Containers (Docker basically) and making your app run in a container. From there you have tools like Railway (https://railway.app) or Cloud66 (https://www.cloud66.com) that can do most of the rest for you.
I’ve watched Google’s behaviour towards its products for the 10 years cited and referenced it in my post above.
Reviewing the infamous https://killedbygoogle.com/ I don’t see much to draw the conclusion that Google kills enterprise products. Which products do you use to draw this inference or are you simply saying you believe the mentality they use for their consumer products would be used for their cloud products?
In either case, I do not think it’s impossible they kill GCP. Just that it is extremely unlikely and without historical precedent w.r.t their cloud business.
As a business customer, we have a dedicated account manager and customer support engineer who in the worst instance any member of our incident response team could ring directly.
We also work with a Google Cloud Partner that we maintain out of band communication with who would be able to mediate account restoration.
All in all, I do not think a business account faces this risk at all and it’s largely a narrative developed from their consumer business where humans are hard to reach.
We rely heavily on GCP and, whilst nothing is impossible, it would be incredibly painful for us to transition away.
I personally think it’s quite unlikely that they shutter the entire business and all the product lines - many of them are extremely high margin and are already in a stable position. Given how many of their products they have designated as Google Cloud (last I heard Workspace is being attributed to Cloud revenue now) it seems more likely we would see the killing of new or in-development product lines such as Anthos or Alloy DB whereas the more established and profitable areas such as Workspace, BigQuery, Looker, GKE, BigTable and others would be allowed to continue to exist in some form.
As someone who has used all the major Cloud Providers, I have generally found the Google products to be the best engineered with “the right sized nut” normally being available, rather than an exercise in cryptography to decipher the documentation for a workaround. It would be a colossal waste and shame IMO to throw that away.
As a customer, I think they are struggling (as the article concurs) with their approach to Sales, Marketing and Support. It is frankly years behind their competition and recently (~2 years) have seen an increase in effort but not real shift in the end result. Part of this problem is their insistence on using resellers and partners for any interesting size deal where these partners themselves are really not up to scratch.
For now, we won’t be taking action to de-risk our position beyond ensuring that a migration of some kind is technically feasible given sufficient notice. I think they will start to drop the investment into the platform and focus on extracting revenue from what they’ve got - but I don’t see it going the way of Stadia and siblings from the consumer side. It’s my hope that revenue (and the narrative it allows them to tell the market around diversification) is worth keeping their crown jewel products running.
We’re currently migrating to Spanner for a variety of reasons - but the mandatory downtime on their Postgres CloudSQL offering will be the part I miss the least.
It’s insane that even with all of their HA and failover turned on they take the whole cluster down for as long as they like every few months!
Attio | London, UK | Full Time | ONSITE or REMOTE within UK | Backend Engineers
Attio is building the next generation of Relationship Management (CRM) with a focus on easy configuration and realtime collaboration. We build on top of email and calendar data to build a smart workspace that represents a step change over existing solutions.
We are looking for experienced backend engineers, ideally with experience of NodeJS, Typescript and PostgreSQL.
We're well funded, growing fast and solving interesting problems along the way!
We recently finished moving our "Recurring Billing" stack from Stripe to Recurly after we found a tonne of problems with the Stripe billing setup. We still use Stripe as a Payment Gateway but we migrated off of their "Billing" product.
I think a lot of those problems related to us being a European business and Stripe not quite being there yet in regards to Tax and Invoicing but now we have switched it's really shocking to me how steep of a price Stripe is placing on a somewhat lacking billing system here. I always assumed their Billing product was there to lock people in to the payment gateway and make it harder to have Interchange++ pricing negotiations.
What's particularly sad is that I have fond memories of the early days of Stripe when I was genuinely excited to use their recurring charge product because the developer experience was so nice.
Today with VAT MOSS, SCA and a larger team the Billing product is neither easy nor powerful for us.
One saving grace for anyone else who finds themselves with an expensive / insufficient Stripe integration is that they make migration out very easy. We were able to get the whole process done with no downtime or missed billing - so it's definitely possible even when dealing with complex billing arrangements.
This is definitely a surprising, if welcome, development from GCP. We used to be pretty significant users of Pub/Sub but migrated to Cloud Tasks after several discussions with our account manager indicated this wasn't the direction they wanted to go with PubSub.
The implementation here also seems to be somewhat unusual at first glass - in particular that a retry of any given tasks appears to also retry any subsequent message with the same "ordering key".
I do wonder what use cases this is targeted that wouldn't require pretty extensive work on the application side to ensure good idempotency. Does anyone have any ideas of problems this would solve in and of itself?
You can see the image behind the central video on the wayback machine archive here: https://web.archive.org/web/20240311143537/https://teable.io...
The asset was created in-house by our design team custom for our website (not outsourced or a template) and was copied identically. The asset itself is a small thing, but the denial of something which is materially provable seemed very odd to me, hence my reply!