31–40 of 51 posts
I have built Cuber ( https://github.com/cuber-cloud/cuber-gem ) a few years ago as a replacement for Heroku and now we use it to deploy all our Rails applications on DigitalOcean Kubernetes. Extremely lower cost, better performance, less bugs, better support...
Is Heroku that expensive these days? What are extremely lower costs? In my experience DO is hella expensive.
Earlier quoted context omitted.
Momentum??
If they still had momentum one year after acquisition, I think it's hard to say they have been going downhill Maybe we could say they went uphill instead for a while? Or something
This was a(n internally-)famously hard and lengthy process for them with ExactTarget (read: Marketing Cloud) because ExactTarget employees identified strongly with "ExactTarget orange" culture rather than "Salesforce blue", which mostly meant being appalled at the technical and process swamp that Salesforce represented and pushing hard to keep their own tech stack and their own culture and standards as long as possible.
Heroku had an interesting arc, as they were the bright spot people would point at internally as where actually good engineering somehow happene even at Salesforce. There was a whole effort to let Heroku be the business unit that paved the path to AWS and PaaS for the entire company (which was at the time operating datacenters themselves), and so Heroku got a bunch of investment and freedom for a bit.
Then there was some weird power struggle, and the executives inexplicably decided not only to take that out of Heroku's hands despite their expertise, but also to basically shove Heroku in a corner to be ignored unless stripmined of its customer base through upsells or its staff through reallocations of headcount.
Earlier quoted context omitted.
This is more helpful when software doesn't just pin the first 4 available cores at 100% to get things done.
How? If each core is 5x faster then it's done 5x sooner. I can't think of a use case for a cheap vps where 5x faster per core cpus are not helpful.
Earlier quoted context omitted.
How? If each core is 5x faster then it's done 5x sooner. I can't think of a use case for a cheap vps where 5x faster per core cpus are not helpful.
A slower background transcode usually doesn't matter, but a faster transcode that stops important processes running in the meantime might. This is usually fixable with effort, but sometimes it's nice to not have to configure everything to the nth degree.
There are many different configurations of vps available with different numbers of cores, if you are picking the vps configuration specifically to have more cores than some transcoding software uses by default to avoid configuring a thread limit for that software then you are still configuring things to the nth degree just at the objectively wrong level of abstraction.
Five bucks it’s this: Management: “we’re going into maintenance mode” Devs: “You mean we get to work on whatever we want?!”
But, paradoxically, this has given those engineers free rein to make whatever improvements they deem fit - including things they may have been blocked from working on in the past due to Product meddling and/or corporate bureaucracy.
(Not speaking authoritatively - this situation just, from the outside, appears to have a lot of parallels to teams I've been on that owned "Legacy" services.)
Earlier quoted context omitted.
The experience of "you push, provision databases & dependencies in 3 clicks, and it just works" is sadly still unmatched.
Maybe true in 2010 but not today.
Earlier quoted context omitted.
A slower background transcode usually doesn't matter, but a faster transcode that stops important processes running in the meantime might. This is usually fixable with effort, but sometimes it's nice to not have to configure everything to the nth degree.
I don't really buy it. The idea that somehow getting one less core but faster per core speeds per pricing bracket makes any difference in this imagined problem. There are many different configurations of vps available with different numbers of cores, if you are picking the vps configuration specifically to have more cores than some transcoding software uses by default to avoid configuring a thread limit for that soft…