byteofbits

The creator chose to remove the image in question following my post.

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!

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.

This is really interesting - all my interactions have been with people in the London office and were not like this.

Perhaps it varies by region?

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.

Considering Google App Engine launched in 2008 and Compute Engine in 2012 I would argue it exceeds "a few years" and begins to form precedent.

I would also argue that it is not a reasonable comparison in this context to conflate pricing changes with deprecation.

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 building Attio (https://attio.com) for exactly this use case!

We have a really modular data structure and a flexible API that feels a lot like Airtable or Notion with all the CRM features you’d expect.

I’d love to learn more about your use case as I really believe the idea of a “modular, developer focused” CRM is long overdue!

Disclaimer: I am the CTO :)

This is essentially how HARM (Anti-Radiation) missiles work [https://en.wikipedia.org/wiki/AGM-88_HARM]

It’s worth noting that the dreaded maintenance everyone is talking about here is not part of the SLA:

“Downtime as part of Scheduled Maintenance will not be counted towards any Downtime Period.” - https://cloud.google.com/sql/sla

I’ve never seen an SLO document for CloudSQL though so the SLOs may be slightly higher internally?

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!

You can learn more about us and the roles we are hiring for at https://attio.com/join-us

Stripe supports exporting PCI data like credit card details to other PCI Level 1[1] providers such as Recurly and Braintree.

Data portability is a solved problem in this space - so there isn't a material risk of churn due to a migration like this.

We recently went through the process and it was very easy.

[1] - https://stripe.com/docs/security/data-migrations/exports

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?

I’ve seen a variety of solutions to this working on different products but by far the best I have worked with so far is OS Login from Google with their Identity Aware Proxy product.

It’s allows developers to manage their own certificates (adding a new machine or rotating a key) whilst allowing us to use the GCP IAM tooling to grant access to certain machines - all without hosting bastion servers ourselves or exposing the servers themselves to the public internet.

As it’s based on PAM its also been relatively painless to integrate with other functions like audit logging.

If you’re using GCP already - I’d highly recommend it!

It’s worth mentioning here that 1.1.1.1 is also affected by this outage which initially made me think my internet was gone completely.

Changing back to an alternative (such as 8.8.8.8 from google) restored my access to the areas of the internet not using Cloudflare.

As a datapoint for your hypothesis, when working in a typed language I will build my code only a few times a day.

I much prefer working from a logical and thoughtful approach rather than iteration. At the point where I start a build I am already reasonably confident that it will do what I want it to.

There are some bugs where I will need to re-build several times consecutively but these are relatively rare for me (I work on REST API systems - so nothing too crazy).

I've used Trello a couple years ago for some personal planning but hadn't thought to try it. I'll give it a spin and see how it feels.

My gut feeling is that the Kanban / Board model might not be a good fit here because the state is really a binary (not-fixed/fixed) and most kanban systems struggle to represent that cleanly.

As someone who has recently started to use cycle lanes to move around London I disagree with the view expressed in the article. Many of the cycle lanes I use everyday in West / Central London are only painted.

I personally feel much safer in a cycle lane, even if only a painted one, simply because I don't have to worry as much about getting side-swiped by a bus. Seeing the end of a painted cycle lane is a good indication that the road ahead requires more complex navigation and will often cause me to slow down and be more cautious.