Please consider adding a user agent string with a link to the repo or some Google-able name to your curl call, it can help site operators get in touch with you if it starts to misbehave somehow.
> Me: No, no, I'm sorry. Yeah one more time. I was just saying if the opportunity cost of Apollo is currently $20 million a year. And that's a yearly, apparently ongoing cost to you folks. If you want to rip that band-aid off once. And have Apollo quiet down, you know, six months. Beautiful deal. Again this is mostly a joke, I'm just saying if the opportunity cost is that high, and if that is something that could make it easier on you guys, that could happen too. As is, it's quite difficult.
> Reddit: Yeah, yeah, yeah, I hear you. I think it's… I don't know what you mean by quiet down. I find that to be-
> Me: No, no, sorry. I didn't mean that to-
> Reddit: I'm going to very straightforward to you too, it sounds like a threat. And I'm just like "Oh interesting". Because one of the things we're trying to do is say "You have been using our API free of cost for many, many years and we have absolutely sanctioned - you have not broken any rules." And now we're changing our perspective for what we're telling you - and I know you disagree with it. That hey, we want to operate on a thing that is financially, you know, footing. And so hopefully you mean something completely different from what I said when you say like "go quietly", I just want to make sure.
> Me: How did you take that, sorry? Could you elaborate?
> Reddit: Oh, like, because you were like, "Hey, if you want this to go away".
> Me: I said "If you want Apollo to go quiet". Like in terms of- I would say it's quite loud in terms of its API usage.
> Reddit: Oh, go quiet as in that. Okay, got it. Got it. Sorry.
> Me: Like it's a very-
> Reddit: Yeah, that's a complete misinterpretation on my end.
> Me: Yeah. No, no, it's all good.
> Reddit: I apologize. I apologize immediately.
> Me: No, no, no, it's all good.
> Reddit: Because what we're hearing in some conversations is folks are, you know, like in other- making threats, and we're like "Hey, that's not a conversation that we want to have". So I immediately apologize.
> Me: Oh, no, no, it's all good. I'm sorry if it sounded like that.
Zero, which is why we're not using k8s on-prem. Our team is already handling the on-prem hardware/software environment, and this will consolidate our apps on a single platform methodology, allowing us to keep the same team size. Using mrsk allows us reduce the complexity of our servers, moving that into the Dockerfile.
If we had gone down the k8s on-prem rabbit-hole, I suspect we would have required more folks to manage those components and complexity.
I mean, mrsk has a different feature set than ECS, sure. But we don't want to pay AWS for ECS anywhere. We're trying to get off big tech where we can. I'm sure you've heard David talk about that.
This tool covers our use cases so far, and is easy to reason about. Ergonomically, it's very similar to Capistrano, which we're all familiar with.
> I move companies between clouds and on-prem to cloud, cloud to on-prem (even though a bit bigger one than 37singnals) and I could use tools like Ansible and Terraform.
Where did anyone say we don't use other tools? Chef + Terraform are wonderful and still in use for us.
> Could you share the comparison chart of tools that you considered? What thought process led you to believe that this is an unsolved problem and requires a new tool? Genuinely interested.
Your phrasing here and in your previous quoted reply leads me to believe you're not genuinely interested. Our environment is not your environment, our experiences are not your experiences. No, I can't share a chart of other tools that were considered, but off the top of my head, Capistrano, various CI integrations, Github Actions, etc.
We're a rails shop. We're going to look at tools in that area. We're not going to go dig into dagger or garden.io or something that causes us to have to conform our dev/deploy environment to a mental model that adds more friction for our developers.
> How should I judge it by than? Reading the code? Figuring out how to hold it right myself?
It's not that complicated of code, only about 2k, total, IIRC? I mean, you could read it. I'm baffled that you're choosing to compare a structural design flaw like the iPhone antennae issue to the fact that a configuration example in a new tool used an IP address. Go off, king.
I don't think there's a writeup out there, but mrsk just uses docker under the hood. So, if you have a CMD in your Dockerfile, it will use that.
If you have an image that can run multiple things, like a rails app that can run the app process for web traffic by default, but it can also run job workers with the right command, you can provide the cmd in the mrsk config. You can see this in the jobs role in the example: https://github.com/mrsked/mrsk#using-different-roles-for-ser....
We did! And it did work. And there are def some great things that I (we) love about k8s. Personally, the declarative aspect of it was chef's kiss. "I want 2 of these and 3 of these, please", and it just happens.
Which is the primary reason why we did investigate k8s on-prem. We had already done the work to k8s-ify the apps, let's not throw that away. But running k8s on-prem is different than running your own k8s in the cloud is different than running on managed k8s in the cloud.
Providing all of the bits k8s needs to really work was going to really stretch our team, but we figured with the right support from a vendor, we could make it work. We worked up a spike of harvester + rancher + longhorn and had something that we could use as if it were a cloud. It was pretty slick.
Then we got the pricing on support for all of that, and decided to spend that half million elsewhere.
We own our hardware, we rent cabs and pay for power & network. We've got a pretty simple pxeboot setup to provision hardware with a bare OS that we can use with chef to provide the common bits needed.
It's not 'ultimately flexible in every way', but it's 'flexible enough to meet the needs of our workloads'.
IP addresses are easy to use in the configurations that inspired mrsk. Small apps that are fairly static. There are two main problems that mrsk is trying to solve.
1. Moving our stuff out of the cloud without going back to static hosts.
2. Giving new rails devs a tool where they can deploy their application easily, in a modern fashion.
Both of these are not so large or complex that you must use hostnames in configs instead of IP addresses. I will note, that most of our internal configs, do in fact, use hostnames rather than IP's. But judging a tool because an example used an IP address seems shortsighted.
There are plenty of things in mrsk to discuss without fixating on that.
Yes, we're actively de-k8s/de-clouding all workloads, including Hey, with mrsk as the pattern. We've started with simple apps and moved up our complexity tree, updating mrsk as we go. My co-worker, Farah Schüller, wrote up a good summary of things so far: https://dev.37signals.com/bringing-our-apps-back-home/
> Presenting a driver’s license or state ID to TSA: Once added to Wallet, customers can present their driver’s license or state ID to the TSA by simply tapping their iPhone or Apple Watch at the identity reader. Upon tapping their iPhone or Apple Watch, customers will see a prompt on their device displaying the specific information being requested by the TSA. Only after authorizing with Face ID or Touch ID is the requested identity information released from their device, which ensures that just the required information is shared and only the person who added the driver’s license or state ID to the device can present it. Users do not need to unlock, show, or hand over their device to present their ID.
Please read the article. It's presented there, and not even hidden away.
I use FF as my daily driver, and yes, it's tested fine with "Standard" Enhanced Privacy Protections. I did see the issue you were talking about, but I had to modify the permissions to "Custom".
Please consider adding a user agent string with a link to the repo or some Google-able name to your curl call, it can help site operators get in touch with you if it starts to misbehave somehow.