I'd say don't use Ansible for sending requests anywhere (except for Git* APIs maybe). Crossplane can very well be combined with one of the other three but I don't see the point in chaining Terraform, Helm or any of those. That would only make everything more obscure, I guess.
I like to use Terraform for building backbone infrastructure (core resources, in general), and to combine Crossplane with Helm to build app related objects (the same way Helm templates defines how our app Deployment and HPA looks like, Crossplane defines it's IAM Role, IAM Policy, Route53 Record, Vault Role, Database connections, etc).
I'm currently working on using the Ansible and Terraform providers for crossplane. The idea being generating compositions based on TF providers that already exist or ansible roles that we have already built. i.e: "VMAccess" is a composition that uses an ansible role (through the Crossplane Ansible Provider) to add an ssh key into a server. We can then use any k8s visualizer to see who has access to which VM effectively avoiding building APIs for granting/removing/reporting on permission since k8s+crossplane+ansible work together as one
So much value, especially for someone like me who's trying to get into a DevOps role. This stuff is not thought in any certification, it comes with experience (an of course, a lot of knowledge) :)
Terraform has been created about 14 years ago and is here to stay for specific use cases, especially with IBM support now… Crossplane won’t replace Terraform as it requires k8s, that’s not always there. Infra tools area is quite disruptive and changing, exciting to see what future will bring 🙂
We are planning to adopt Talos Linux in our datacenters which I am really excited about, because it is a 100% API-driven OS. If it works, it's gonna let us ditch a large amount of all the self-crafted, half-automated, and maintenance-heavy scripts, pipelines & Ansible playbooks for provisioning and configuring infrastructure and shift towards APIs even for the machines and OSs 😏
My girlfriend remarked on how this guy never styles his hair, to which I replied, “That’s because we prioritize crafting excellent code over having perfectly styled hair.” 😂
@LawZist the only problem is lazyness. I tend to go to a hairdresser only after I realized that i look like a caveman. That's typically twice a year. Then i tell my barber to cut as short as possible so that i don't have to come again any time soon.
@@DevOpsToolkitI feel you may be my lost brother. I operate the same way. I just wear a baseball hat once I go caveman and go full Sasquatch for a few more months before the hair cut. 😂
Viktor, this may not be relevant to this video but wanted to ask this...when using argo cd and crossplane together, which controller does the reconciliation of resources? Is it argo controller or crossplane controller? and how?
Argo CD creates/updates/deletes resources defined in Git. Those resources can be, for example, Crossplane claims. Crossplane, on the other hand, reconciles all the child resources of those claims (what you define in Compositions) and, just as Argo CD looks for drifts between what is in Git and what is in a cluster, Crossplane looks for drifts between managed resources (those managed by compositions) and "real" resources (e.g., AWS, GCP, Azure, Kubernetes, GitHub, etc.). Does that explanation help?
Viktor, this video is gold, simple and well explained. From here to Hollywood and getting an OSCAR? I would like to manage OS through an API too, sucks ssh-ing or ssm-ing to change something, can I use ansible with Crossplane to expose an API to OS?
Crossplane is aimed towards enabling you to build your own APIs so you could create one for an OS, but that would be a strech. More often than not, third-parties should expose their "stuff" as API and you should focus on what matters to you (to your own services).
You definitely should take a look at Talos Linux. We are testing it right now so I can't give you an experienced pov but it looks very promising. It is focused on running Kubernetes and is completely API-driven. It doesn't even have a shell but comes with its own CLI.
Thanks for another great video! I think there is confusion about the differences between the different kind of tool, I feel the same whenever I hear that true GitOps can be obtained outside of Kubernetes, with the so called "Infrastructure as a Code" tools. Thanks for clarifying!
In theory, GitOps can be done outside Kubernets. In practice, as far as I know, no one built such a solution. Many say they did but those can be easily verified by asking them whether such solutions implement all four GitOps principles (opengitops.dev). The truth is that Kubernetes has quite a few baked-in capabilities that make GitOps much easier to implement. That's probably the reason why we don't see it outside Kubernetes. P.S. We had GitOps long time ago with Chef and Puppet (except that it was more like SvnOps) but those died in the meantime.
@@DevOpsToolkit that's what I meant. I hear many saying: I do GitOps because I use Terraform but I don't think they catch the difference! Thanks for the clarification
I haven't found the need to add Crossplane or Pulumi, yet. Other than that, I'm not sure how you can remove Terraform, Ansible, or Helm (or similar to Helm).
I agree that you should not remove those. You need a tool that translates code to API requests. What you might be missing is a way to build your own APIs.
Thank you very much. Can you do a video on Harness CICD tool. There's been a drive to move from Azure DevOps to Harness in our organisation. Will be helpful if you can share your views.
I'm not sure I'll do harness. It's a tool of the past that is not adopted by many these days and is typically used by those who adopted it a while ago.
So... You can use crossplane even if you dont use k8s at all? I guess just like terraform and pulumi you could use cdk for aws, and terraform for your on prem, if thats where you come from?
I'm not sure I understood your question. Do you mean that you do not need to manage kubernetes clusters with Crossplane (but some other type of resources)?
@@DevOpsToolkit yeah... Imagine if we didn't use k8s at all... And we wanted a control Plane trat can translate and do a drift detection between JSON for Devs... And Terraform CDK Pulumi that we use to actually manage Cloud APIs... Would CrossPlane work for that?
@matscloud why not use kubernetes? Before you answer that question, let me stress out that kubernetes is not used only as a platform to run apps packaged as container images. Even if you do not rin your apps in kubernetes you can still use kubernetes for many other things. That can be for control planes like those enabled by crossplane, for managing virtual machines with kubevirt, for running ci/CD pipelines, etc. As for continuous drift detection and reconciliation... We saw that the only reasonable way to do that is by performing it in individual resources and not projects as a whole. If you prefer terraform or a similar tool you would first need to break projects into individual resources and then do continuous drift detection and reconciliation on each of them. Not using kubernetes for that would be silly since that's hard to do and is already baked into kubernetes. What you can do (apart from breaking projects into resources) is create some sort of kubernetes operatora for terraform or whatever you're using. What I'm trying to say is not whether to use terraform or something else but, rather, that ignoring kubernetes would be a waste since it already comes with many important features baked into it. Use it to create APIs and to manage resources of any kind whereever they are. Know, whether what's managing those resources inside kubernetes is based on terraform, pulumi, crossplane, kubevirt, or anything else is of secondary importance. When we get a kubernetes controller that does something we stop caring what is powering such a controller.
@matscloud I forgot to comment on APIs. When I talk about them, I assume that you use to manage Cloud APIs. I was referring to your APIs. If you want to enable devs to do something, give them APIs to do that. Do not give them files and CLIs. Now, the only reasonable way to create APIs today (at least when managing resources is concerned) is by creating kubernetes CRDs. There are plenty of ways to do that.
Lol, I guess I'm one of the screaming at the screen. No, but seriously, I have code running locally, now I want it in the cloud. That's one task, and one tool should solve it. That's all. I don't think that's too much to ask.
Update: great video, but I'm not outraged. Actually I'm outraged by the absence of content that induced outrage. Legally speaking, does that still count?
@@DevOpsToolkit yes, that's a good point. being economical with one's attention is important given the breadth of the subject. but it often feels to me like I'm under pressure to know everything about everything so I get worried when I realize how much I don't know.
![Hunxho - Ball Forever [Official Video]](http://i.ytimg.com/vi/nki9ZTF9Uls/mqdefault.jpg)
Do you think that solutions like Ansible, Terraform/Pulumi/Helm, and Crossplane should be combined or one of those is enough.
I'd say don't use Ansible for sending requests anywhere (except for Git* APIs maybe). Crossplane can very well be combined with one of the other three but I don't see the point in chaining Terraform, Helm or any of those. That would only make everything more obscure, I guess.
I like to use Terraform for building backbone infrastructure (core resources, in general), and to combine Crossplane with Helm to build app related objects (the same way Helm templates defines how our app Deployment and HPA looks like, Crossplane defines it's IAM Role, IAM Policy, Route53 Record, Vault Role, Database connections, etc).
I'm currently working on using the Ansible and Terraform providers for crossplane. The idea being generating compositions based on TF providers that already exist or ansible roles that we have already built. i.e: "VMAccess" is a composition that uses an ansible role (through the Crossplane Ansible Provider) to add an ssh key into a server. We can then use any k8s visualizer to see who has access to which VM effectively avoiding building APIs for granting/removing/reporting on permission since k8s+crossplane+ansible work together as one
you only need nix: terranix, kubenix, nixos enjoy :)
So much value, especially for someone like me who's trying to get into a DevOps role. This stuff is not thought in any certification, it comes with experience (an of course, a lot of knowledge) :)
Mind blown 🤯 thank you. Going to share this video with anyone who needs it.
Another great video!! A lot of work into it! I'm sharing it once again! Thank you for these!
Very insightful. Your point about having a control plane on this side of the API requests in a hybrid environment is well made. Well done Victor.
Enlightening analysis, very helpful to plenty discussion many of us (have been/ are dealing with), totally agree, thanks
Thanks a ton @diegoamaya6591
Terraform has been created about 14 years ago and is here to stay for specific use cases, especially with IBM support now… Crossplane won’t replace Terraform as it requires k8s, that’s not always there. Infra tools area is quite disruptive and changing, exciting to see what future will bring 🙂
very instructive ! got the idea now of what crossplane is for. thank you !
What an informative video! I virtually wrote each line of the talk.
We are planning to adopt Talos Linux in our datacenters which I am really excited about, because it is a 100% API-driven OS. If it works, it's gonna let us ditch a large amount of all the self-crafted, half-automated, and maintenance-heavy scripts, pipelines & Ansible playbooks for provisioning and configuring infrastructure and shift towards APIs even for the machines and OSs 😏
That's how it should. We should reject using any solution that cannot be managed through an API.
Thanks for this video and maybe a part II :). But wonderful and clear to me - who just started this cloud journey.
My girlfriend remarked on how this guy never styles his hair, to which I replied, “That’s because we prioritize crafting excellent code over having perfectly styled hair.” 😂
😂😂😂
I literally do not have a single comb. The style of my hair mostly depends on random movements I make while washing it.
Shorter hair style can fit you very well. Anyhow, love your videos!
@LawZist the only problem is lazyness. I tend to go to a hairdresser only after I realized that i look like a caveman. That's typically twice a year. Then i tell my barber to cut as short as possible so that i don't have to come again any time soon.
@@DevOpsToolkitI feel you may be my lost brother. I operate the same way. I just wear a baseball hat once I go caveman and go full Sasquatch for a few more months before the hair cut. 😂
"Kumbaya my Lord" I didn't know this song
Now I know a new song
Thanks, great history lesson
good points! very useful information. thanks
Good one Viktor 👌
Great explanation!
With IBM's acquisition of hashicorp, perhaps Terraform and Ansible will be more deeply integrated?
Viktor, this may not be relevant to this video but wanted to ask this...when using argo cd and crossplane together, which controller does the reconciliation of resources? Is it argo controller or crossplane controller? and how?
Argo CD creates/updates/deletes resources defined in Git. Those resources can be, for example, Crossplane claims. Crossplane, on the other hand, reconciles all the child resources of those claims (what you define in Compositions) and, just as Argo CD looks for drifts between what is in Git and what is in a cluster, Crossplane looks for drifts between managed resources (those managed by compositions) and "real" resources (e.g., AWS, GCP, Azure, Kubernetes, GitHub, etc.).
Does that explanation help?
@@DevOpsToolkit yes... I was missing the Managed resource piece(which is specific to crossplane)..
thank you for clarifying on that.
Viktor, this video is gold, simple and well explained. From here to Hollywood and getting an OSCAR?
I would like to manage OS through an API too, sucks ssh-ing or ssm-ing to change something, can I use ansible with Crossplane to expose an API to OS?
Crossplane is aimed towards enabling you to build your own APIs so you could create one for an OS, but that would be a strech. More often than not, third-parties should expose their "stuff" as API and you should focus on what matters to you (to your own services).
You definitely should take a look at Talos Linux. We are testing it right now so I can't give you an experienced pov but it looks very promising. It is focused on running Kubernetes and is completely API-driven. It doesn't even have a shell but comes with its own CLI.
Thanks for another great video! I think there is confusion about the differences between the different kind of tool, I feel the same whenever I hear that true GitOps can be obtained outside of Kubernetes, with the so called "Infrastructure as a Code" tools. Thanks for clarifying!
In theory, GitOps can be done outside Kubernets. In practice, as far as I know, no one built such a solution. Many say they did but those can be easily verified by asking them whether such solutions implement all four GitOps principles (opengitops.dev). The truth is that Kubernetes has quite a few baked-in capabilities that make GitOps much easier to implement. That's probably the reason why we don't see it outside Kubernetes.
P.S. We had GitOps long time ago with Chef and Puppet (except that it was more like SvnOps) but those died in the meantime.
@@DevOpsToolkit that's what I meant. I hear many saying: I do GitOps because I use Terraform but I don't think they catch the difference! Thanks for the clarification
I haven't found the need to add Crossplane or Pulumi, yet. Other than that, I'm not sure how you can remove Terraform, Ansible, or Helm (or similar to Helm).
I agree that you should not remove those. You need a tool that translates code to API requests. What you might be missing is a way to build your own APIs.
Thank you very much. Can you do a video on Harness CICD tool. There's been a drive to move from Azure DevOps to Harness in our organisation. Will be helpful if you can share your views.
I'm not sure I'll do harness. It's a tool of the past that is not adopted by many these days and is typically used by those who adopted it a while ago.
bro is flexing his editing skills
3:31 it's CONTROL, not COHTROL
leviosa
hehe, cyrillic
I wholeheartedly think that pulumi should be included here as well.
My bad. I should have been clearer that Pulumi follows the same logic (within the context of that video) as Terraform.
Agreed. We have a super clean setup of redfish -> cobbler -> pulumi -> kubevela + argo. Works like a charm.
@@arnabseal7629 I saw the Pulumi logo several times 15:47
@ramonsong6707 yeah. I mentioned it a few times. Within the context of that video if falls into the same category as terraform or even helm.
Petarda! 🎉
So... You can use crossplane even if you dont use k8s at all? I guess just like terraform and pulumi you could use cdk for aws, and terraform for your on prem, if thats where you come from?
I'm not sure I understood your question. Do you mean that you do not need to manage kubernetes clusters with Crossplane (but some other type of resources)?
@@DevOpsToolkit yeah... Imagine if we didn't use k8s at all... And we wanted a control Plane trat can translate and do a drift detection between JSON for Devs... And Terraform CDK Pulumi that we use to actually manage Cloud APIs... Would CrossPlane work for that?
@matscloud why not use kubernetes? Before you answer that question, let me stress out that kubernetes is not used only as a platform to run apps packaged as container images. Even if you do not rin your apps in kubernetes you can still use kubernetes for many other things. That can be for control planes like those enabled by crossplane, for managing virtual machines with kubevirt, for running ci/CD pipelines, etc.
As for continuous drift detection and reconciliation... We saw that the only reasonable way to do that is by performing it in individual resources and not projects as a whole. If you prefer terraform or a similar tool you would first need to break projects into individual resources and then do continuous drift detection and reconciliation on each of them. Not using kubernetes for that would be silly since that's hard to do and is already baked into kubernetes. What you can do (apart from breaking projects into resources) is create some sort of kubernetes operatora for terraform or whatever you're using.
What I'm trying to say is not whether to use terraform or something else but, rather, that ignoring kubernetes would be a waste since it already comes with many important features baked into it. Use it to create APIs and to manage resources of any kind whereever they are. Know, whether what's managing those resources inside kubernetes is based on terraform, pulumi, crossplane, kubevirt, or anything else is of secondary importance. When we get a kubernetes controller that does something we stop caring what is powering such a controller.
@matscloud I forgot to comment on APIs. When I talk about them, I assume that you use to manage Cloud APIs. I was referring to your APIs. If you want to enable devs to do something, give them APIs to do that. Do not give them files and CLIs. Now, the only reasonable way to create APIs today (at least when managing resources is concerned) is by creating kubernetes CRDs. There are plenty of ways to do that.
Lol, I guess I'm one of the screaming at the screen. No, but seriously, I have code running locally, now I want it in the cloud. That's one task, and one tool should solve it. That's all. I don't think that's too much to ask.
In that case your best bet is probably Ansible. Both terraform and crossplane require a bit of setup (in cloud?) before they're operational.
@@DevOpsToolkit Thank you for your advice!
Intro set expectations, I'm excited to get offended and angry.
Update: great video, but I'm not outraged. Actually I'm outraged by the absence of content that induced outrage. Legally speaking, does that still count?
@davemeech i thought that saying that terraform and helm are essentially doing the same thing would be outrageous enough.
I haven't used helm yet, perhaps I'm still in the infancy of my DevOps maturity. There we go, that's what I'll be outraged about.
"cloud is sus" bro
talos?
Talos is great but I'm not sure how it fits into the context of this video.
as a scrub I learn so much basically every video you post. worries me though. there's too much to learn. not much hope for me
One of my goals is to hell with that by providing info people can use to decide what is worth investing in and what is not.
@@DevOpsToolkit yes, that's a good point. being economical with one's attention is important given the breadth of the subject. but it often feels to me like I'm under pressure to know everything about everything so I get worried when I realize how much I don't know.
And the project never got delivered!
Which project?
Calm the fuck down. No I can't 😅