Ask HN: Is Palantir Apollo just an AWS competitor?
I’m watching Palantir’s Apollo explainer (https://vimeo.com/745514542/c0ec314888), and it basically seems like a new set of dashboards for what I normally view via AWS EC2, RDS, and IAM. To be clear, I’m not trying to place a value judgement here, my use of the word “just” is because I feel like I must be missing something, but is Apollo just a dashboard layer over AWS?
3 comments
No, it's much closer to an ArgoCD replacement, if Argo could run Terraform plan+apply loops, too
There's quite a bit of documents out on their public site[1], although the Mission Manager that represents the other half of the story has its docs gated by authentication
1: https://www.palantir.com/docs/apollo/core/release-channels/ et al, plus one can get a sense of how apollo-cli works from their OpenAPI spec https://github.com/palantir/apollo-openapi/blob/develop/open...
There's quite a bit of documents out on their public site[1], although the Mission Manager that represents the other half of the story has its docs gated by authentication
1: https://www.palantir.com/docs/apollo/core/release-channels/ et al, plus one can get a sense of how apollo-cli works from their OpenAPI spec https://github.com/palantir/apollo-openapi/blob/develop/open...
Thanks for this; I'm still not getting it, I think because I haven't really deployed software at scale before? It's a CI/CD solution?
I can see how this would be instrumental for coordinating hundreds of developers across tens of products, but as someone who's only ever worked as tens of developers on one product it seems like a lot of overhead for really no ROI; what's the difference between using this product and having a DevOps team that coordinates CI/CD in-house? Is Palantir's edge here being the out-of-house devops team for any large enterprise?
I can see how this would be instrumental for coordinating hundreds of developers across tens of products, but as someone who's only ever worked as tens of developers on one product it seems like a lot of overhead for really no ROI; what's the difference between using this product and having a DevOps team that coordinates CI/CD in-house? Is Palantir's edge here being the out-of-house devops team for any large enterprise?
It is a CD solution, there's no CI involved at all. However, it extends the 'delivery' portion of that phrase to also include so called "day 2" Kubernetes-centric functionality such as "how does my Secret content get populated?" and "how to I apply only certain values.yaml to certain Helm release versions?" Then, Mission Manager also gets into the game of "how do I ensure my cloud resources are present alongside the software?"
It also gets into the compliance side of things (arguably it's all about compliance) in that new releases, config changes, vulnerability mitigation, downtime windows, and a ton of other stuff are optionally gated by a review process. If you want to change the values.yaml for an existing release, you can choose whether that is a 4-eyes change
That latter bit also speaks to your question about "who is the target audience for this?" because, like many things Palantir, it's a lot of the defense industry and intelligence community, as they care a lot about having gates and controls in place. Apollo specifically also gets into "edge deployments," such as what software is running on a laptop that goes out into the field, comes back to base, and only then gets its updates pushed to it
I detest them with all my heart, but I'll be straight that Apollo does actually model the deployment concerns of software very well. Every place that I've been always hand-assembles their own CD story using off the shelf stuff, and so if one has compliance needs then Apollo allows to pay to have the "hand assembled" problem go away. That said, I have _absolutely no idea_ how much Apollo costs, so I'd also speculate that most organizations would be much happier just paying for a competent DevOps role to do the best they can to use off the shelf tools to hand assemble their own CD story, or use BigBang[1] which is at least open source and a standard (one may not like it, but it is at least consistent)
1: https://github.com/DoD-Platform-One/bigbang#readme
It also gets into the compliance side of things (arguably it's all about compliance) in that new releases, config changes, vulnerability mitigation, downtime windows, and a ton of other stuff are optionally gated by a review process. If you want to change the values.yaml for an existing release, you can choose whether that is a 4-eyes change
That latter bit also speaks to your question about "who is the target audience for this?" because, like many things Palantir, it's a lot of the defense industry and intelligence community, as they care a lot about having gates and controls in place. Apollo specifically also gets into "edge deployments," such as what software is running on a laptop that goes out into the field, comes back to base, and only then gets its updates pushed to it
I detest them with all my heart, but I'll be straight that Apollo does actually model the deployment concerns of software very well. Every place that I've been always hand-assembles their own CD story using off the shelf stuff, and so if one has compliance needs then Apollo allows to pay to have the "hand assembled" problem go away. That said, I have _absolutely no idea_ how much Apollo costs, so I'd also speculate that most organizations would be much happier just paying for a competent DevOps role to do the best they can to use off the shelf tools to hand assemble their own CD story, or use BigBang[1] which is at least open source and a standard (one may not like it, but it is at least consistent)
1: https://github.com/DoD-Platform-One/bigbang#readme