Under the hood Pulumi actually uses many Terraform modules. It also allows you to easily create kubernetes resources. So in fact you could likely use Pulumi to control crossplane so that you don't have to write repetitive manifests and instead are just working with simple typed objects. I don't think you should have used Golang to test Pulumi as it seems to be a lot better in Typescript. It's advantage is not just loops or if conditionals and I'd put those on the lower end. The advantage is allowing you to great simple abstractions and create clear relationships between your infrastructure components. Yaml for kubernetes tends to be about copying the same value into many different parts of different kubernetes resources.
What about AWS CDK Viktor? (despite the fact it's a AWS CloudFormation under the hood and single vendor only tool) Can it be comparable to Pulumi or Terraform? Is it possible to have hybrid model, i.e. use CDK+Terraform/Pulumi/etc.
@@zlonux AWS CDK is more similar to Pulumi than to Terraform. It allows users to define infra through few languages instead of doing it through YAML/HCL/etc. So, it's comparable to Pulumi but, as you said, it is limited to AWS. Also, it compiles to YAML so, at the end of the day, it is limited with what it can do when compared to Pulumi. I never tried a hybrid model with CDK and something else. To be honest, I never saw a good reason to use CDK. Now, I do not work exclusively with AWS so I might not be a good representative. CDK might make more sense for those who are fully on AWS.
Some observations on the video: Crossplane uses ETCD and it's limited to 1mb per document: this can be a problem with complex topologies. Secondly, the use of a proper programming language allows you to test to a level of detail you can only forget with Terraform and Crossplane, third, drift detection if available also in Terraform and Pulumi (they have kubernetes operators too), fourth no mention of policy as code, where Terraform and Pulumi are very strong. Lastly, using a programming language allows you to build sophisticated workflows in reusable components.
I haven't had problems with 1mb ETCD limit so far. I guess you would need to have a truly massive Crossplane Composition for that to be an issue. You're right about testing, at least when unit testing is concerned. Pulumi has the edge on that. Drift detection is Terraform and Pulumi is nowhere near Crossplane simply because it leverages Kubernetes natively while other tools need to deal with workarounds trying to make it somehow work in k8s. Policy as code is actually one of the advantages of Crossplane. Since it's k8s-native, it can leverage (almost) any tool in the CNCF landscape, while others need to build their own tools for everything. Policy as code is a good example given that you can use Gatekeeper, Kyverno, or anything else that you are likely already using in Kubernetes. As for reusable components... I would argue that Crossplane Compositions (not explained in that video) provide a much better way of creating reusable components. They end up being Kubernetes CRDs with their own APIs and on the same level as controllers that come out of the box through Crossplane providers.
@@DevOpsToolkit just to be clear, I actually used all of them. We will probably end up sticking with Crossplane mostly because of its affiliation with the CNCF. But if I had to tell you which approach I like the best, then Pulumi is that one.
As someone mentioned Pulumi can use terraform modules under the hood. There is a terraform bridge to easily create a pulumi module from terraform. What never seems to be mentioned is the native modules in Pulumi though. What I do not like with terraform is how you have to keep the terraform providers up to date manually with underlying apis / sdks. There is always a delay from azure sdk is updated till feature is available in terraform, there are still features over a year old that is not available in terraform! Pulumi has azure native support, built from azure sdk with same day access to anything added to azure sdk. It now also has a beta for google cloud native. This is a huge bonus compared to terraform if you ask me. Just comparing the number of providers / module is not enough, compare the support they have on the underlying api / sdks. If your doing mostly Azure and Kubernetes the support is superior in Pulumi.
Personally, I think of Terraform modules in Pulumi only as a temporary solution until Pulumi catches up with Terraform from the modules perspective or as a way to transition to Terraform. It's for the mixed-setup scenario and, on the long run, I would go to Pulumi all the way. You're right about the necessary delays required for Terraform to catch up with the changes to underlying APIs and SDKs. Having the native support for those is a huge plus for Pulumi and I'm ashamed for not mentioning it. That was a huge oversight on my part.
Two things: 1) If you want to store the state of Terraform in a server, you have to rely on a proprietary solution. 2) Deleting and restoring a VM is easy. Exactly. But if a VM already exists because it was created by hand, you get a conflict with Terraform. The resolution is only possible by hand. With Ansible, this is not a problem. Ansible does not distinguish WHO created something. General: Puppet has already tried to describe only the final state and not the way to the target. What was the result? There were always things that are done in a certain order. This can be mapped in Puppet only via dependency. And so you get a dependency hell very quickly. I suspect that I will run into the same problems with Terraform & Co. But thanks for making the effort with the video. Keep going! These are important discussions that should be led.
1) Terraform can store state in Artifactory, AzureRM, Consul, COS, etcd, GCS, etc. There are, if I remember correctly, around 15 "standard" locations for remote state, and a bunch of others available through modules. 2) You can import existing infra into Terraform. But, to be honest, it does not work perfectly. Since, most of the time, Terraform would destroy and create instead of update, I rarely bother importing anything. Terraform is mostly focused on the immutable way of managing infra which tends to be the preferable way in Cloud (public or private). So, it's not that much about the ability to manage (update) VMs are runtime, but more about creating and destroying VMs. In most cases, if, for example, you update a definition of a VM, it will create a new one and shut down the old one, usually using rolling updates when more than one VM is involved. Now, immutability might not be a good fit for all use-cases, especially when working on-prem. In those cases, Ansible, Chef, and Puppet might be a better choice. They are mostly designed around the ideas of mutable infra. That does not mean that Terraform works only on the immutable level nor that Ansible/Chef/Puppet only deal with mutable infra. Instead, it's more about which of those is the primary focus of those tools. Anyways... There is no on-fits-all solution. It all depends on what we currently have and where we want to be. As long as we are aware of how different tools work, we can make educated choices of what fits the best our use-cases.
@@DevOpsToolkit Interesting! That Artifactory is supported as backend store was new to me. Good to know. I had tried it with azurerm and got problems with lockings.
Nice summary. Like you rightly said, Crossplane taps into k8s ecosystem so it stands out with its sibling ecosystem providers in that * SDK: K8s resource definition is the unified SDK for defining app workloads and cloud native services * Control Pane: ArgoCD/Flux is the unified control pane to monitor the health of your app as well as dependent cloud native services * Policy Mgmt: Kyverno is the unified policy mgr that helps one define & apply policies for k8s app services as well as cloud services provisioned via crossplane
Using the Terraform Cloud Operator for Kubernetes is almost the best of all worlds and allows us to leverage the Kubernetes ecosystem. The main drawback is that doesn't seem to have any automated drift detection like Crossplane.
Auto drift detection and sync, together with the ability to use the same API (kube API) for everything is the main selling point of Crossplane. Now, one needs to weigh that against the size, stability, and market presence of Terraform.
Nice comparison. + Some other use-cases with General purpose languages are: DocOps(e.g Sphinx) or Unit testing! (something very useful for big organizations or large teams) Imagine; if Hashicorp would have started with some general purpose language(instead of HCL); DevOps world would have been completely different! They already have started with Terraform_with_CDK; its a bit late for something like this. I hope it will come out of its BETA state soon.
Can you do a video/talk that go more in depth about your thoughts on ansible and why you think ansible is on life support. Really interested and would love for you to speak more on this topic. Thanks!
I’d love to see this as well. Look, I understand that IaaC and containers are taking over. That’s fine. There are still a ton of orgs, projects, applications, or infrastructure that simply aren’t there yet. Yes, it works great for microservices or applications developed with a cloud native mindset, but assuming that every devops in every shop everywhere can just adopt this without a massive amount of work is assuming a lot. Ansible’s standard library of modules can handle *so* much, more, I would assert, than any of the three tools reviewed. Try calculating subnet CIDRs simply in Terraform, or launching standalone Docker images based on templated variables per environment (with secrets able to be stored in Git) in Pulumi. The fact is Ansible fills a different niche than the other three tools reviewed - the former is configuration management and the latter three are infrastructure management. In fact, the latter usually rely on something like Ansible to post provision the infrastructure they stand up.
I agree that Ansible is for orgs "that simply aren't there". My mistake was to qualify that as on life support. There is a lot of legacy out there, and Ansible serves it well. Similarly, many might not want to make an investment to transition to something else, just as many are using mainframe, mutable VMs, Jenkins, etc. It's hard to make such an investment and, sometimes, there might not be enough ROI to do that. That being said, I do not agree that it works great for microservices or cloud native apps. It doesn't. Ansible is based on mutable principles that are left overs from the times we all used bare metal. Today we have much better options on the table. What those options are depends on the task at hand. Managing infra alone is much more efficient with IaC tools. Many of us are packaging apps as immutable containers and managing them through Argo CD or Flux. Kubernetes is becoming the standard. Ansible is not a good fit for those use cases. All that being said, Ansible is or, to be more specific, was great. I used it a lot throughout the years and it still has an important role. Nevertheless, that role is mostly tied to legacy systems and there's nothing wrong with that. It's usage will continue dropping, but it will also live for a long while, just as Jenkins, mainframe, and other widely used but old tech will continue living.
@@DevOpsToolkit I wholeheartedly agree that Ansible and microservices are a mismatch. I can almost guarantee though that Ansible will continue to be used for at least another decade. The others are really already dead; Ansible has survived because of its portability and simplicity.
@@bobbyray8457 Oh yeah. Within that same category of tools (configuration management), Ansible is without doubt the best. That's why it is the only one standing (RIP CFEngine, Chef, and Puppet). As you said, there is a need for such type of tool and it will continue being heavily used for years to come. The fact that it is not next-gen type of tool and that it's usage is not increasing, does not mean that it'll dissapear nor that there are no good use cases for it. I shouldn't have said that it's on life support. That was an exaggeration and I shouldn't have said it. I could have explained it better.
I think Terraform CDK and Pulumi styles are popular over delcarative styles because they allow you to be more expressive and also open opportunities for us to test IaC. E.g. - what lessons can we take away from convention over configuration and an imperative style, versus having to declare everything over and over again? Also, testing declarative 'code' is really pretty hard. People understand how to test imperative constructs a bit better. Just my $0.02
I really like the idea of Crossplane although the chicken and egg scenario is much worse with Crossplane than with Terraform or Pulumi. For example with Terraform I usually include a module to set-up the initial state storage which is run once locally (and the state is just discarded or kept locally). Also sometimes you just need to make a quick change to the infra manually in dev and it's not easy to tell Crossplane _not_ to reconcile those changes, it'll just pull things back which makes debugging really painful.
"Chicken and egg" issue is a problem, but mostly for smaller organizations. For bigger ones, it's actually the opposite. The is the initial investment into running Crossplane (e.g., k8s cluster), but letting etcd handle the state is much better than tf remote storage. TF state quickly becomes "complicated" when working with larger teams/operations. Personally, I don't think that Crossplane is sufficiently good of a choice if one is managing only a few resources. It shines at larger scale. As for a quick change... That's the same issue as with any something-as-code tool, and especially with GitOps. Once we start defining everything as code, we are forced or, at least, we should be forced to, follow it through. If, for example, you start using Argo CD or Flux, you'll have exactly the same problem. Once a tool starts managing something through reconciliation loops, we need to stick to the process (the tool). Otherwise, we easily get into the same situation as if we'd edit manually a Pod which is managed by a Deployment (through a ReplicaSet). Those tools/processes are intentionally making sure that the actual state is (almost) always the same as the desired state. As a side note, one could argue that changing an existing YAML and executing `kubectl apply` is just as easy and fast as doing the same through, let's say AWS console. P.S. When I created that video, I was only a user of all three tools. Since then, I choose to join Upbound (the company behind Crossplane). That might compel you to take everything I wrote above with a grain of salt and say that I'm subjective. The alternative could be that I did join Upbound because I genuinely believe in Crossplane. It can be interpreted both ways and I thought I should be open about it.
Crossplane fixes the drift automatically, one downside of this is, let's assume there is some incident and you need to vertically scale elasticache or add a node. The most easier way will be to directly change it from the console. Because during downtimes fixing things quickly is most important, it's more of a do-or-die situation. In the case of Crossplane changing from the console is not possible. Crossplane will detect the changes as drift and sync them again. :/
One could argue that changing the Crossplane CR is just as easy as making a change through the vendor API (including console). Similarly, if I would be managing infra through Terraform or Pulumi, I would do the same (`terraform apply`) instead of a console. The more you work with those tools (Terraform/Pulumi/Crossplane/etc.), the more you use them to manage everything, including "disaster" scenarios. For me, for example, changing manifests in any of those is easier and faster than through a console. Nevertheless, I can understand that for some (or many) that is not the case and, in that scenario, drift detection can indeed cause trouble, just as doing something directly with Pods would cause trouble since they are controlled by ReplicaSets which are controlled by Deployments.
Hi, thank you so much for all your videos, One thing to mention about terraform, there is an alternative, you don't *have* to use HCL, you could use json. I'm personally templating terraform/packer configurations with jsonnet, so to use a templating engine already use for other services (kubernetes).
I do not agree that puppet ansible etc.. are dead, I give you the challenge to manage on-premise infrastructure with terraform. I agree that Terraform Pulumi and cross-plane are better options to cloud management but, is really a nightmare for on-prem. I think the best is a convo of two technologies, I'm coding with terraform the basic cloud infrastructure and with ansible or salt stack the configuration that I need to apply on-premise and cloud. Is possible to combine and automatize transparently the deployment on-prem and cloud
You're right. Saying that they are dead was an overstatement. A better wording could be "fading away". Their usage is shrinking and the chance of reversing that trend are very slim. So, those will stay with us for a long time, but their user base will continue getting smaller and smaller, just as on-prem will continue shrinking, but never fully disappear.
I made that video before I joined Crossplane/Upbound. I feel that if I would make it again it would be understood as being too biased. TL;DR; It's still Crossplane. Otherwise, I'd go elsewhere.
Thanks for this video and all the others you have created. Very informative. I just have one comment, about something I don't think you addressed in your comparison of the IaC tools, namely dependencies. What I mean here is that both Pulumi and Terraform offer out of the box intuitive ways to define configurations where there are dependencies between the individual resourcea and/or modules. Being able to easily set the input of a resource as the output of another and letting Terraform (or Pulumi) build up a DAG is extremely powerful. It's not clear to me how this can be achieved using Crossplane, at least from the quick googling I did. In some cases it's not important that one thing is created before another, but typically for infrastructure it is, i.e. a VPC must be created before a subnet for example. I love the idea of Crossplane, but unless I can understand how to do this in an intuitive way I'm not sure I could recommend that tool.
Crossplane has the concept of `patches`. Essentially, you tell it to get data from one resource and use it as a value of a specific field. If the source is not yet available, it will wait until it is.
Excellent insight as always - I would like to point a subtle correction on the native drift detection and reconciliation of feature that cross plane borrows from Kubernetes is Controller(read custom controller) or Operator - the famous control loop of Kubernetes NOT Scheduler. Please correct me in case I misunderstood.
Ansible/Puppet/Chef users often use those tools to create infra, and not only to configure existing servers. From that perspective, I see them as IaC tools or, to be more precise, IaC could be considered a subset of config management tools, at least when practical usage is concerned. That being said, I might be wrong and my sample almost certainly does not represent the industry in general.
@@DevOpsToolkit I agree. Although those tools were primarily designed and implemented to manage the configuration of servers, they can be extended and used to orchestrate the management of several infrastructure components. This is certainly not the best way to manage an infrastructure, but it can be done.
@@gbws Oh yeah. I was, for example, using Ansible for many years to manage not only configuration but also infrastructure. All the tools eventually start expanding and covering areas beyond their initial scope. Config management tools gained capabilities to manage infra, just as infra tools gained the capability to manage configs. The major question is where someone is. If one has heavy investments in, lets say, configuration management with Ansible, it makes sense to use it for infra as well. But, if you're starting from scratch and you can choose what to use, I would always choose Terraform/Pulumi/Crossplane for infra rather than Ansible/Chef/Puppet/CFEngine.
Hi, Viktor. Is it true, that Crossplane‘s Compositions are build on top of proper Terraform provider, f. e. Azure Terraform Provider for building Compositions with Azure Ressources? And in general, that each Crossplane Cloud Provider uses proper Terraform Provider under the hood … ok now I have confirmation of it from some online sources. Just brillant solution!
I curious to know your thoughts on the route Terraform is going with things like Consul-Terraform-Sync. I don't imagine it would be a huge stretch in the future to get similar daemon functionality for other resource types to help with the issue of drift sync (similar to what Crossplane does)
I'm sure that Terraform is and will be investing in something like that. Now, Crossplane has the advantage of being k8s-native so it does not have to do everything. It can rely on the scheduler and the API to do a part of the job. That is, in general, the goal behind building tools designed for k8s. They can all leverage k8s and the ecosystem in general. Terraform will ned to put more effort to get to the same point when auto-sync is concerned. On the other hand, HashiCorp has more people so that does not need to be seen as a problem. My main beef is with Consul. There is no good reason why I would run Consul in k8s that already comes with a similar tool (etcd). Consul might be better, but not sufficiently for me to ignore the fact that there is already a key-value store in my clusters.
Ansible is not dead; Ansible is not IaC. Crossplane is out if you don't use K8s. Pulumi costs money. Terraform is great as long as there's a provider for your cluster; which in on-prem can become an issue. I notice in general in your videos that you're using K8s as a service as if it's the most natural and widespread thing in the world, as if nobody would ever think or need to use a self-managed K8s cluster on a bunch of PCs. Or not use K8s at all 😲. That's fine as long as it's clear, you can't make videos for everybody everywhere; but then don't make sweeping statements like "Crossplane is the best IaC tool". It is if you're using K8s + GitOps + cloud provider; it is NOT if you want to provision Kafka on a bunch of VMs on PCs in an on-prem/offline mode. This is not a critique, just an observation. Not sure how you could improve, I understand that you face limitations in what you can cover in 30-40 min.
Configuration management was transformed into IaC just as IaC is getting transformed into control plane, so, comparing Ansible and terraform does make sense just as comparing running apps in web logic and Kubernetes makes sense even though they are not called the same. I do agree that not everyone has a Kubernetes cluster to serve as a control plane (not necessarily to run all the apps in there). Nevertheless, a significant part of innovation goes into Kubernetes and it's adoption is sky rocketing so it makes sense to have it as a focus. Similarly, cloud adoption is going up rapidly so it makes sense to focus on it as well. That does not mean that everyone is using cloud or Kubernetes or serverless or ... Heck, many companies are still using mainframe. Many are using Ansible. There is no denying it. Still, it's usage is dropping with close to no chance of recovering so it is not dead, but it is on life support. Even if you look at providers with solutions for on-prem, you can see that Kubernetes and control planes are moving forward. Take a look at development in VMware, redhat, etc.
I thought crossplane was k8s specific whereas terraform/pulumi were general purpose. Terraform, for example can manage github, aws, gcp, .., vm/docker images (via packer, ..). It can also do k8s natively or via kubectl / kustomize / helm. So you could in theory use both tf and cp on the same project - tf for everything except k8s and cp for the rest.
All three are general purpose. Crossplane runs inside k8s, but manages all sorts of infra just like Terraform and Pulumi. In other words, you can use any of them to manage anything (ignoring which one has more pre-baked libraries included out of the box).
I am certain that kubernetes will be extended to manage everything. My bet is that it will be crossplane but that is not the main question. What matters is whether we will move from IaC to control planes and i believe they is inevitable.
Drift can be caused by changes to the desired state (manifests in Git) or by changes to the actual state. You are right only about the former case. If you change Terraform manifests, GitHub actions can trigger a process that will execute `terraform apply` which, in turn, will detect the drift and fix it. But, if the actual state changes (e.g., a node disappears, someone changes something at runtime, etc.), GitHub actions will not trigger anything since there were no changes to Terraform manifests (or anything else stored in Git). In that case, the drift will persist until you do change something in Git. To solve that with Terraform, you would need to run some kind of a cron job that would execute `terraform apply` periodically (e.g., every 3 minutes).
I agree, even when I risk to get some hate from Viktor. 😁Nah, just kidding, but I guess he is busy like hell. It would be very nice to see this comparison with the actual state of all 3 tools, and maybe some newcomers, if there are any.
I'm trying to avoid that since after i made that video i joined upbound, the company behind crossplane. Since then, i am avoiding any comparisons since that would label me as subjective, and I'm trying to avoid that as much as possible. The only thing I will say is that i an privileged to be able to choose where i work so the fact that i am still with crossplane probably tells you what i think about it compared to other similar tools.
@@DevOpsToolkit I can fully understand this and it makes sense. I already made my decision to go with Crossplane anyway. The only thing I need to figure out now, is how to adapt it to my special use case where I can not use cloud providers, because everything needs to run and the data kept on servers in Swiss datacenters only. Regulatory and customer demand. I will figure out a way. Currently evaluating openstack self hosted. A lot to do, but I love digging into stuff.
@MarkusEicher70 it is open source so in the worst case scenario you might need to create a provider if one you need is not already available. Creating a provider can be relatively easy.
Hi Viktor, very nice video! Thanks for sharing. Don’t really get why you said ansible was out of life as new versions were released after your video. Would you mind clarify that? Thanks !
Ansible adoption is not increasing (outside redhat customers) or, to be more precise, is very low. On the other hand, some are moving from Ansible to terraform, pulumi, crossplane, etc. I do not see that trend reversing. I do not think that Ansible will change significantly enough to convince people using other similar tools to move (back) to Ansible. It is a similar trend as with on-prem and cloud. Some on-prem users are moving to cloud, and almost no one takes the reverse direction. So, what I'm saying is not that Ansible is not making new releases but that it's userbase is shrinking and that I do not see that trend changing. Ansible is in a similar situation as chef and puppet were in the past. Both exist, both are probably having new releases, but their loss of users is irreversible. When that happens, contribution rate tends to drop, investments tend to drop, etc. All in all, I stand by my words. Ansible is on life support. There are people keeping it alive but they are fewer and fewer in number. Eventually, the day will come when none will be there.
That is true. Crossplane assumes that Kubernetes is everywhere and that creating a cluster they will host it is relatively fast and easy. It could be even minikube. Once the cluster is created all the future updates of it can be managed by crossplane. That being said, there is not denying that there must be a cluster created somehow before installing crossplane and that might be an issue for some. On the bright side, crossplane is about to release SaaS version. That would remove the need to have a cluster (local one or a real one) before using crossplane.
Hey Viktor. There's a (relatively) new tool from Weave: tf-controller, which can reconcile Terraform in cluster, similar to Crossplane, but the big feature here is that you can use any of your existing Terraform modules. Also, it uses Flux's source objects. Any plans to cover it? You could also compare it to Crossplane's Terraform provider, which does the very similar thing.
`kubectl diff` will give you the difference in manifests, not the difference in the "real" infra resources that will be affected. Now, whether that is enough is a different question.
@@DevOpsToolkit I don't use kubernetes in my day to day work, so I'm not sure if I got this right, but in recent versions kubernetes can dry run server side and diff is based on what changes the server would actually make to the state, including crds, so it should be reasonably close to a preview - if the kubernetes resources actually represent the infra. However, as an author of those manifests, you're not actually changing the infra anymore, but the kubernetes representation. Kubernetes is going to change the infra after all. I hope to get to work with it some day to see whether that is enough. Crossplane sure looks innovative to me and how I would want to create and manage infrastructure.
For management of AWS resources, what is the difference between crossplane and ACK (Amazon Controllers for Kubernetes), given that crossplane's AWS provider leverages ACK?
I haven't (yet) used ACK directly so I cannot judge the differences from personal experience. It's still on my TODO list which happens to grow faster than I can handle.
Crossplane supports multi-cloud (and even things like Helm providers). Crossplane also lets you build composites. This gives ability for an InfraTeam to define MyCompanyRDSInstance which can give a simplified interface for AppTeam. For example, InfraTeam defines an interface which means the AppTeam only needs to supply name & storageSize (in other words, composites can define sensible defaults). Composites become pretty important if you want to hide the more complicated stuff like VPC/SecurityGroups. I wish AWS went all in on crossplane in terms of contributing...it's extremely good :)
`kubectl diff` works with Crossplane. Crossplane manifests are Kubernetes resources so any tool that works with k8s works with Crossplane. That's one of the big advantages of it. We can combine it with `kubectl`, `kustomize`, `helm`, Argo CD, Flux, and so on and so forth. That being said, I don't think that you should be applying k8s resources with `kubectl`, at least not in production. Instead, it's better if you push them to Git and let GitOps (e.g., Argo CD, Flux) or CI/CD tools do the work. In such cases, you can get `diff` by reviewing PRs before merging them to the mainline (and letting other tools apply them)
I'm a bit late to the party, but since March 4, 2022, Pulumi has declarative YAML support. @Victor maybe we should have another run of this comparison? :D
I should do another run. All those tools are changing relatively fast, and new players are entering the "game" as well. I'll do my best to make a new comparison video soon.
@@DevOpsToolkit Take your time. On the other hand I think the Kubernetes scheduler is still the best approach when you really want to automate it all and don't touch it again. Nevertheless it would also be nice to see what has changed overall since your video.
I'm new at IaC tools, so I'm probably missing something, but doesn't Pulumi have one massive advantage: ability to query existing infrastructure and apply changes instead of defining completely new infrastructure? So for example, if there are some items that were created outside of IaC tool, you can use your favourite programming language to analyse existing infrastructure and tell Pulumi to not destroy those items.
That could indeed be an advantage. Personally, I haven't had those cases since whatever I define in Terraform/Pulumi/Crossplane is either new or is meant to take control of existing infra. Nevertheless, you're right. That is an advantage of Pulumi.
That's probably because I'm new, haven't yet figured out how everything works and still thinking as developer. Modifying existing infrastructure seems logical to me, but from various videos about IaC I've been watching, look like logic is different. My goal is to automatically manage deployments of my app. I want to deploy it in several regions, use Route53 for latency routing to make sure users are routed to closest server, then, when either code or data set are updated, first add new servers and start app on them, then add Route53 records for them, then remove old Route53 records, then give some time before destroying old servers in case someone still has old IPs cached. Looks like things are much easier when using load balancers, but I can't afford that. Load balancers are expensive and I just need small EC2 instances in few regions, one per region. Trying to figure out how to set it all up and which tools to use. Thanks for excellent videos, they are very helpful! Going to watch more of them because every time I watch one, things become a bit clearer.
It's not really an adavantage. In terraform most resources have a "data" counterpart that can be used to query existing resources for their setup and then your code can use those values to make decisions (how many NATs based on an existing VPC subnets, etc). Some of these data types have properties to filter (eg get all AWS AMI that meet certain criteria). Pulumi apparently has a notion of getting existing resources, so I'd say terraform and pulumi are on quite even footing for this aspect. Also note that terraform never destroys what it does not own, and I believe Pulumi does same. Even if you use a resource name for creation that exists, terraform will say during plan stage that it already exists but it does not own it and will refuse to go further. You will then have to use terraform import or edit your code, depending on the situation, and apply again.
I had to limit myself somehow, so Salt Stack failed to be mentioned together with quite a few others. Ansible will indeed be with us for a long time. As a matter of fact, it is probably still the best option for on-prem infra. Others (e.g., Terraform and Pulumi) are too much oriented towards Cloud while Crossplane still does not have enough on-prem providers.
@@DevOpsToolkit I agree. Also, it looks like on premise environments aren't going anywhere for the foreseeable future. Whoever can bridge this gap or manage hybrid environments seamlessly is gonna stay here as a winner.
@@shinebayar Oh yeah. On prem is not going anywhere. It might not be increasing in usage, but it's here to stay. That's why most new products start with cloud (higher interest/reach), but, at some later stage, go for on prem as well. The thing is that the tools that were initially focused on prem rarely make successful transition to cloud. We are yet to see whether the other direction will work. If it doesn't, there is the chance that the gap will never be bridged.
Thanks - very interesting video! Does Crossplane have notion of Terraform data-sources to lookup / cope with existing resources? This is usually quite hard in the Gitops world where _everything_ wants to be described in Git ...
Still not sold on using Helm to modularize your IaC for Crossplane's case. Helm templating sucks as we all know. But in this case, I still have no idea how you would do it. You have to make a helm chart for, say, a VPC, and another for EKS? No thanks. It takes forever to make a chart, let alone, a bunch of them.
I don't see why would you have a separate charts for VPC and for EKS. If you would keep those in the same project in Terraform, I don't see the reason not to keep them together with Crossplane or, if you do choose Helm to wrap Crossplane, why not to have it in the same chart (excluding the possibility of organizing it as Chart dependencies). Now, I don't think it takes any longer to create a chart that, let's say, to add variables to Terraform manifests. In both cases, there is a similar syntax how to use values within the manifests, and both are using separate files to store variable definitions (even though that is not mandatory with Terraform). That being said, I would not recommend anyone to use Crossplane if not already working with k8s. On the other hand, if one is already working with k8s, Helm/Kustomize/JSONNet or something similar is unavoidable (for better or worse).
It is a good practice to separate resources based on its own lifecycle and purpose. Separating the vpc from the compute allow you in the future to reconfigure your network without affecting/validating your existing resources. An example I can give you is creating a vpc with a subnet for the cluster and in the future add new subnets for new resources that are managed outside the cluster lifecycle. It makes easier and quicker to manage. Regarding using helm, I am not a fan, I think it add complexity to things tja6 should be simple (yaml)
I think you neglect an important component for the on premise crowd concerning the easiness of setting up crossplane: You need a functional kubernetes cluster. This is trivial in the cloud where you have kubernetes as a service. On premise, you need to provision your kubernetes workers, masters, load balancers, etcd cluster, your kubernetes installation and in all likelihood dns servers, bastions (and possibly also ntp servers depending on how stringent your self-sufficiency requirements are). That's a fair amount of infrastructure you have to manage before you can even start leveraging kubernetes and this is where an infra as code tool that don't depend on kubernetes start to look pretty good. When you have to manage it yourself, kubernetes is not an operationally trivial tool with next to no footprint.
You're right. Creating the initial cluster is easier in cloud than on-prem. However, you do not need everything you listed. Crossplane, for example, does not need an external lb, DNS, etc. As a matter of fact, you can run it initially in minikube or rancher Desktop or any other local Kubernetes. Once you do have it running, you can start using it and that means that you can use crossplane to create and manage Kubernetes clusters even the one where crossplane will be running permanently. Since it all goes through yaml manifests (hopefully stored in git) it's easy to move stuff. Still, you are right. It is easier in cloud, there's no denying it.
and what if you are not using k8s? not all clients like k8s, no matter how much you try to sell it to them, so a k8s dedicated tool is a no for a lot of cases
If you're not using Kubernetes, Crossplane is definitely not the option. There is no such a thing as the best solution for all use cases. So, I agree with you, except the part that says that "a k8s dedicated tool is a no for a lot of cases". Kubernetes is (becoming) a dominant platform and a significant percentage of companies adopted it. I would instead say that "a k8s dedicated tool is a no for **some** cases" given that k8s is today used in a lot of cases and it continues growing exponentially.
I agree. I think that using crossplane to manage its own dependencies (i.e managing its hosting k8s cluster after the initial bootstrap) will amplify the blast radius of some mistakes/incidents. IMO, you'd be prone to even more disastrous outcomes if you share the crossplane k8s cluster with tools used across your whole system (like log servers).
Terraform sucks if you manage across many environments. You cannot conditionally configure a provider. So now I have to maintain a separate code base for every combination of environment conditions or generate hcl in another language. This is why CDK and pulumi exist. I think crossplane is the future though.
This was great, just starting up an infra as data/code project and this was a nice overview. We definitely have a lot of on prem infra as well, so we might need some ansible in the mix
Ansible is, in my opinion, the best option for on-prem infra that should be treated as mutable. The alternative is to adopt immutable approach and, in that case, you would be building VM images instead of changing VMs are runtime. If you do something like that, Packer is a good choice. Nevertheless, that tends to be a complicated change for many so you might want to stick with the mutable approach with Ansible for on-prem infra.
@@DevOpsToolkit Thank you I neeeded this specific answer... I have on prem hardware that by reqruiement must be bare metal K8s. I also 2 clouds and for those we use Ansible / Python for one and Terrraform for the other.
You're probably right. I am trying to make it visible on all devices but that probably results in the font being too big on "real" monitors. It's hard to make it readable everywhere... I'll decrease the font in next week's video (the one for this Thursday is already done) and see how it goes.
well, I use clusters for every project, but I don't use k8s. So, having it for IaC don't worth it. PS: Your opinion does matter - please, don't hesitate to share it.
Hi - very good video. Thanks for sharing it. Is it possible to use Crossplane and Pulumi together - use the power of k8s api using crossplane and imparative control using pulumi?
@@DevOpsToolkit I am thinking the other way round - Use crossplane for reconciliation and instead of XRDs, pulumi for infrastructure definations. Any thoguths on this?
That can be done as well. I would not do it though since that would remove the benefits of Cards like, for example, having tailor made k8s resources for certain groups of "real" resources, GitOps, etc.
Crossplane seems really promising and I'll be testing that. The only problem I see is.... how to use Crossplane to create the cluster where it'll be running? Difficult there and, there, Terraform wins.... we could use both anyway for different things.
You are partly true. You need storage for terraform state created in advance. Once you do, you can use Terraform to manage that storage, just as you can use crossplane to manage k8s cluster where it's running. That being said, it is true that having a k8s cluster as a requirement is harder than creating a storage (even though creating a k8s cluster is easier today than it was before). Now, just as terraform, there is a cloud option. You can use crossplane cloud to run crossplane.
@@DevOpsToolkit you can create an S3 bucket before, using Terraform, and then store the state, plan and whatever you want there later. I've done that running Terraform from Python, so I handle those files as that. I don't see how I can do it with Crossplane. I really want to try Crossplane, but that part... I don't know how to pass. Maybe I create the first cluster using Terraform, install Crossplane and, all the rest, with it... I'll need to try and think...
@@AlvaroC77 You can do something similar, even though more complicated. You can create a local k8s cluster (e.g., k3d, KinD, Minikube, etc.) to run Crossplane and create the initial infra (including a k8s cluster). From there on, you can install Crossplane in the "real" cluster and let it manage infra (including the cluster where it's running). That being said, that initial setup is definitely more complicated than Terraform (unless you use .www.upbound.io/cloud/).
Would it be possible to use something like Crossplane in conjunction with Terraform ? As Crossplane acts as a K8s resource you could theoretically manage it via TF using the K8s provider right ? Then you could get the best of both worlds, vast provider support offered by TF (for providers that are not supported by Crossplane yet) and also the self healing capabilities made available for the resources managed by Crossplane. Does this make sense ? Or is this example use-case just adding another tool (TF) for the sake of it ? Haha Would love to hear your opinion ☺️ BTW just came across your channel and love the content! You have many other videos I have pinned to Watch Later :)
Personally, I'm not sure I like the idea of using Terraform to execute `kubectl`, `helm`, `kustomize`, or similar commands. On the other hand, combining Terraform with Crossplane is often a necessity, but I prefer doing that through automation tools. So, I tend to keep both types of definitions in Git and use Argo CD or Flux to manage Crossplane manifests just as any other types of k8s manifests, and CI/CD pipelines for Terraform or the k8s operator.
@@DevOpsToolkit . I intended to convey an interest in the later statement. It seems like a lot of disasters and interesting findings could be found if Crossplane is a K8s CRD controlling the cloud infrastructure on the same cloud account where the Kubernetes Cluster is running. Like IaC recursion.
The problem is that I feel that litmus might not be the best one to be combined with Crossplane. It's capabilities are mostly focused on k8s with close to none related to infra. I feel that something like chaos toolkit might be a better combination. WDYT?
Great overview talk! Thanks! I'm using Terraform. But one day I'll switch to Kubernetes ... so Crossplane stays on my radar screen. But still ... I'm learning Go ... so Pulumi is something to risk looking at it ... ;-)
All three (Terraform, Pulumi, Crossplane) are great tools. That being said, Crossplane is changing the way we manage everything (infra, services, apps) while Terraform and Pulumi are based on the same ideas. There is no significant difference between Terraform and Pulumi except in the format to define the desired state of resources. Personally, I am not convinced that Go or any other full-fledged languages are the way to define the desired state of resources. On the other hand, I might be biased (I am heavily involved with Crosplane) so you might take that with a grain of salt.
Oh yeah. Go is my favorite language and it is the one used in most open source projects today. It is the way to go. As a side note, Crossplane is 100% Go, just as almost any other k8s-related project.
@@DevOpsToolkit I have created public subnet and private subnet. I'm creating the route table and associating the public subnet with internet gateway and private gateway with nat gateway. The route table is created but it is not being associated. And also I want to put name for the subnets. You can see the name field is empty in the image. How to do that? subnet.yaml apiVersion: ec2.aws.crossplane.io/v1beta1 kind: Subnet metadata: name: crossplane-public-subnet1 spec: forProvider: region: ap-south-1 availabilityZone: ap-south-1b cidrBlock: 10.0.1.0/24 vpcIdRef: name: crossplane-vpc mapPublicIPOnLaunch: true tags: - key: name value: crossplane-public-subnet1 providerConfigRef: name: default --- apiVersion: ec2.aws.crossplane.io/v1beta1 kind: Subnet metadata: name: crossplane-private-subnet1 spec: forProvider: region: ap-south-1 availabilityZone: ap-south-1c cidrBlock: 10.0.2.0/24 vpcIdRef: name: crossplane-vpc tags: - key: name value: crossplane-private-subnet1 providerConfigRef: name: default routetable.yaml apiVersion: ec2.aws.crossplane.io/v1beta1 kind: RouteTable metadata: name: crossplane-public-routetable spec: forProvider: region: ap-south-1 vpcIdRef: name: crossplane-vpc associations: - subnetIdRef: name: crossplane-public-subnet1 routes: - destinationCidrBlock: 10.0.0.0/16 gatewayId: local - destinationCidrBlock: 0.0.0.0/0 gatewayIdRef: name: crossplane-internetgateway tags: - key: name value: crossplane-public-subnet1 providerConfigRef: name: default --- apiVersion: ec2.aws.crossplane.io/v1beta1 kind: RouteTable metadata: name: crossplane-private-routetable spec: forProvider: region: ap-south-1 vpcIdRef: name: crossplane-vpc associations: - subnetIdRef: name: crossplane-private-subnet1 routes: - destinationCidrBlock: 10.0.0.0/16 gatewayId: local - destinationCidrBlock: 0.0.0.0/0 natGatewayIdRef: name: crossplane-natgateway tags: - key: name value: crossplane-private-subnet1 providerConfigRef: name: default
Sorry for not responding earlier. I somehow missed this comment. Which association is missing? ReuteTable with the Subnet? Is the `associations` not working?
@@DevOpsToolkit It is successfully associated now. By the way it was associated before but I was confused whether it is associated. I have put "Name" in key and the name is also shown now. Thank you.
- Configuration platforms dead? They have still lots of uses, and are far from dead, I think you are too concentrated on k8s here. Also, not sure why are you putting them on the same video. They are totally different beasts. - Crossplane: find weird use a k8s resource to create something that has no relationshinp to k8s. Why? Why complicate it with helm k8s..... not sure what crossplane ,main purpose is. (monitoring drift is a minor issue, at least for me, can be achieved in different easy ways.But for me is even not desirable; in some instances, I want to be able to manually modify something and fix it when I want, not automatically. Is a useful option to have when you work in the real world. - Terraform: It does not use a normal language because is deterministic and non-runtime dependant. That's the reason why it can "plan" what will be done. Agreed with pure yaml and being declarative also solves the issue, but terraform language provides a middle ground much simpler than yaml templating (helm or whatever)
> Configuration platforms dead? if you look at the usage of CFEngine, Chef, and Puppet, they are clearly going away. That does not necessarily mean that they are bad, but, rather, that they are in the downfall and are hardly going to recover. That does not mean that they will not be used by anyone but, rather, that they are getting the same treatment as mainframe. It's there, we need it, but mostly because switching to something else is too expensive and risky. What I might agree is that Ansible's days are not yet over. It might recover. It's not very likely, but it's possible. In any case, those four are mostly used for the maintenance of the existing systems. Some use them for new ones, but that's mostly as a way to leverage existing knowledge. > Why complicate it with helm k8s Helm (or something similar) is not a complication, but a reality. Today, almost every company has something running in k8s. That might be 95% or 1% of their workloads. Nevertheless, k8s is there. That means that almost every company is using Helm (or something similar). From that perspective, Helm is not a complication, but a reality. We might have a discussion whether it should be Helm, Kustomize, JSONNet, or something else. But, one of those is present in almost every company. > I want to be able to manually modify something and fix it when I want, not automatically The question is not whether we should be able to fix something manually or not. Any of those tools assume that there are manual actions. Changing a manifest of something is a manual action. A better question would be whether someone should be able to change things directly without leaving a trace of that change (outside of the resource that was changed)? I believe that should never be an option. Whatever should be changed, should be pushed to Git first, unless it is a type of organization where there is a single person in charge of the whole system. Now, I understand that auto-sync might not suit everyone, and I can agree with that. That's perfectly fine. > much simpler than YAML templating (helm or whatever) I guess that depends on what we are used to. I don't think that using HCL templating is simpler (or more complicated) than using Go templating (that's the one used by most of the tools written lately, including Helm). Actually, that is not true. Go templating is more complicated because it does many more things than what is available in HCL. But, if we compare them for the same set of features, they are similar in simplicity (or complexity) and differ more in style than anything else. I might feel more at home with one or the other, but that's mostly because I might be more used to one over the other.
I can see reasons to use Crossplane, just as I can see reasons in favour of Terraform. To me, usefulness of Crossplane in some (not all) scenarios is clear. The doubt I have is whether the benefits applicable to some teams and organisations (not to all) outweigh the benefits of using Terraform (assuming that they are already using it), including the learning curve (everything new has a curve) and the cost of switching.
Do not agree regarding ci/cd. every step in a pipeline requires binary outcome - green or red, 0 or 1. if terraform/pulumi fails to apply there will be clear indication through non zero return code. with crossplane or k8s for that matter you have no idea and would have to implement custom logic to validate that apply actually happened.
The same can be said for using pipelines to deploy your apps to k8s, or for anything else that assumes eventual consistency. Instead, we tend to rely more on notifications and alerts. If that does not work for some use cases, k8s is not a good option.
@@DevOpsToolkit hmmm, are you saying that k8s/crossplane are not a good option for doing Continuous Integration/Delivery? Both techniques rely on the ability to validate every commit and require binary outputs from the steps to work so CI/CD system can notify a correct person regarding issues introduced by his/her change
Not at all. K8s and crossplane are great for CD. What I was trying to say is that both k8s and GitOps favor async processes and that might change how traditional pipelines work. Instead of having one pipeline, we might need many, each triggered on different events. So it's not 0 or 1 but rather "this pipeline built an image and pushed some change to a git repo and then a completely different process (e.g. Argo cd) deployed something and that triggered an event that might run another pipeline or do something else.
@@DevOpsToolkit well, this is exactly the point that I tried to get across in the initial comment. ArgoCD/Crossplane requires additional work to fit them into classic pipelines or additional work to re-engineer pipelines to account for eventual consistency. Thus they can't get the same score when it comes to CI/CD
Ansible EOL, chef dead..lol, Ansible is more popular then Terraform and IAAC does not mean only provisioning.You are comparing all the tools here on the basis of provisioning capabilities on cloud or may be only Kubernetes. And switching from one tool to other very frequently works only for startups or may be on personal laptops :)
You are right that terraform is mostly for cloud primarily because on-prem is rarely treated through immutability. Nevertheless, Cloud usage is rising and, as a result, on-prem is going down. Not many use Ansible in Cloud and that means decreasing usage of Ansible in favor of Terraform, Pulumi, Crossplane and similar tools. That can be backed by looking at trends. We can see that over, let's say, 5 years, the usage of Ansible is dropping and Terraform and similar tools is increasing. No matter how many companies switch from Ansible to terraform, hardly anyone takes the opposite route, just as hardly anyone goes back from cloud to on-prem. So, it is not that much about the total usage of one compared to another but trends. Ansible reached its peak a while ago and it's downward trend is not likely to be reversed. That does not mean that it is not widely used, but that it's days of glory are passed, just as the days of configuration management glory are passed as well.
I wish community give more love to sceptre project. it really has a potential like helm ... if only community adopts it, I could really be a better tool than these 3 ...
I haven't used Sceptre but, from what I saw on docs, it is limited to AWS. Typically, tools of that kind tend to succeed when they are not limited to a single provider since, on that case they compete with the tools of that same provider, get less adoption which leads to less contributions. Nevertheless, I haven't used it so I might be wrong. It might be based on an original idea that makes it stick from the crowd. I'll check it out and spend some time with it.
You are comparing apples and pears. You cannot compare configuration management tools with IaC tools. Each of them are for different purpose. You can bend them to do each others work, but it doesn't result in a good solution. I would say that CFEngine is dead, Puppet and Chef are on life support and Ansible is thriving.
You are right. They are indeed different types of tools, but thry serve a similar purpose. Both config management and iac tools manage infra and whatever is in it. The difference is that config management tries to do it in a mutable and iac in immutable fashion (even thought they can all do both). We are moving (or already are) into immutable realms for everything from infra to apps. As for ansible... I do not think it's thriving. Many switched from Ansible to terraform, and there are hardly any cases of the opposite. That does not mean that ansible does not have a big user base (it does), but that it is slowly being reduced. It is unlikely that trend will be reverted. Part is partly due to immutability, and partly due to ansible not being seen as a good choice for cloud.
@@DevOpsToolkit Not true. Configuration management tools are here mainly to manage OS-level things where IaC is managing mainly the infrastructure (networking, VMs, ...). You can use Ansible to build cloud infrastructure but nobody sane would do that. The same, Terraform can manage OS-level things but nobody sane would do that. If you are fully in the cloud and all your applications are containerized, there is no reason to use Ansible. If you are running stuff on prem, then there is very little space for Terraform. Simply comparing configuration management tools with IaC tools will never work.
You are right. Ansible rules on-prem area, and will likely continue doing so. Personally, I think that on-prem should be managed by building VM images and instantiating VMs, but that is not what the majority does. So, you are right. Ansible is on-prem ruler. It's usage will keep dropping as more and more workloads are moving to cloud, but there will always be on-prem (in some capacity) and therefore, Ansible as well. Thank you for you comment. I often forget that on-prem is still significant. As a result, I dismissed Ansible too fast.
@@DevOpsToolkit We got rid of Ansible for "on prem" config management in favor of Powershell (we're mostly a Windows shop running in AWS). We're still using CloudFormation for IaC in AWS but are starting to move towards Amazon CDK to abstract the CloudFormation code even further. It was mostly a choice that provides us with vendor support (and AWS lock-in lol, we're a very small team that does "everything", servers, networks, EKS, 3rd party SaaS, IAM, security etc).
Chef, Puppet dead ??? Ansible on life support, wait, what you said, which year is now, 2132 ?? Am I missed something ? I don't have experience with Chef and Puppet, and I don't care, but not sure about this software.
You're right. Those are not dead, just as mainframe is not dead. There will always be companies that will reject letting go of something. So, there will always be someone somewhere using Chef, Puppet, and mainframe. As for Ansible, it's usage is dropping and that trend is likely going to continue. Hardly anyone new jumps into Ansible and every once in a while someone makes a switch from Ansible to Terraform, Pulumi, etc. That is especially true for those moving to Cloud (which is almost everyone).
@@DevOpsToolkit thank you for letting us know. I am having blast now. Just to be clear, I am in DevOps from April last year, but I am studying from beginning of 2020, and I have strong background in networking/Linux env. Is not like I am complete noob, just I didn't hear anything similar, but I understand your point. Really appreciate.
It all depends on where you work. Ansible is indeed used in quite a few companies. What I tried to say, but obviously failed, is that it is going down in usage.
two years down the road, neither pulumi or crossplan has really caught on in popularity. Google Trends shows very clearly that they are both not really popular. One the other hand Terraform is far far far ahead of them
You mean Google Trends? Page that shows you what people search via Google? Let's remove Intellisense from IDEs and code documentation from Pulumi source (to make it fair fight with Terraform) and I guarantee you it will top up Terraform on Google Trends...
![Kodak Black - Versatile 4 [Official Video]](http://i.ytimg.com/vi/VcP_1Ua__vY/mqdefault.jpg)
Please let me know in the comments which one are you using? Terraform, Pulumi, Crossplane, or something else?
Terraform!
Terraform, but playing with Crossplane - taking advantage of k8s reconciliation is a huge bonus, especially if you're into the whole GitOps thing :)
Under the hood Pulumi actually uses many Terraform modules. It also allows you to easily create kubernetes resources. So in fact you could likely use Pulumi to control crossplane so that you don't have to write repetitive manifests and instead are just working with simple typed objects. I don't think you should have used Golang to test Pulumi as it seems to be a lot better in Typescript.
It's advantage is not just loops or if conditionals and I'd put those on the lower end. The advantage is allowing you to great simple abstractions and create clear relationships between your infrastructure components. Yaml for kubernetes tends to be about copying the same value into many different parts of different kubernetes resources.
What about AWS CDK Viktor? (despite the fact it's a AWS CloudFormation under the hood and single vendor only tool) Can it be comparable to Pulumi or Terraform? Is it possible to have hybrid model, i.e. use CDK+Terraform/Pulumi/etc.
@@zlonux AWS CDK is more similar to Pulumi than to Terraform. It allows users to define infra through few languages instead of doing it through YAML/HCL/etc. So, it's comparable to Pulumi but, as you said, it is limited to AWS. Also, it compiles to YAML so, at the end of the day, it is limited with what it can do when compared to Pulumi.
I never tried a hybrid model with CDK and something else. To be honest, I never saw a good reason to use CDK. Now, I do not work exclusively with AWS so I might not be a good representative. CDK might make more sense for those who are fully on AWS.
Some observations on the video: Crossplane uses ETCD and it's limited to 1mb per document: this can be a problem with complex topologies. Secondly, the use of a proper programming language allows you to test to a level of detail you can only forget with Terraform and Crossplane, third, drift detection if available also in Terraform and Pulumi (they have kubernetes operators too), fourth no mention of policy as code, where Terraform and Pulumi are very strong. Lastly, using a programming language allows you to build sophisticated workflows in reusable components.
I haven't had problems with 1mb ETCD limit so far. I guess you would need to have a truly massive Crossplane Composition for that to be an issue.
You're right about testing, at least when unit testing is concerned. Pulumi has the edge on that.
Drift detection is Terraform and Pulumi is nowhere near Crossplane simply because it leverages Kubernetes natively while other tools need to deal with workarounds trying to make it somehow work in k8s.
Policy as code is actually one of the advantages of Crossplane. Since it's k8s-native, it can leverage (almost) any tool in the CNCF landscape, while others need to build their own tools for everything. Policy as code is a good example given that you can use Gatekeeper, Kyverno, or anything else that you are likely already using in Kubernetes.
As for reusable components... I would argue that Crossplane Compositions (not explained in that video) provide a much better way of creating reusable components. They end up being Kubernetes CRDs with their own APIs and on the same level as controllers that come out of the box through Crossplane providers.
@@DevOpsToolkit just to be clear, I actually used all of them. We will probably end up sticking with Crossplane mostly because of its affiliation with the CNCF. But if I had to tell you which approach I like the best, then Pulumi is that one.
As someone mentioned Pulumi can use terraform modules under the hood. There is a terraform bridge to easily create a pulumi module from terraform. What never seems to be mentioned is the native modules in Pulumi though. What I do not like with terraform is how you have to keep the terraform providers up to date manually with underlying apis / sdks. There is always a delay from azure sdk is updated till feature is available in terraform, there are still features over a year old that is not available in terraform! Pulumi has azure native support, built from azure sdk with same day access to anything added to azure sdk. It now also has a beta for google cloud native. This is a huge bonus compared to terraform if you ask me. Just comparing the number of providers / module is not enough, compare the support they have on the underlying api / sdks. If your doing mostly Azure and Kubernetes the support is superior in Pulumi.
Personally, I think of Terraform modules in Pulumi only as a temporary solution until Pulumi catches up with Terraform from the modules perspective or as a way to transition to Terraform. It's for the mixed-setup scenario and, on the long run, I would go to Pulumi all the way.
You're right about the necessary delays required for Terraform to catch up with the changes to underlying APIs and SDKs. Having the native support for those is a huge plus for Pulumi and I'm ashamed for not mentioning it. That was a huge oversight on my part.
Pulumi is also better for AWS resources rollout as well...more like hand and gloves
@Terje Thank you, that helped me a lot in evaluation for an Azure first architecture.
Best channel I’ve found. Saw your CNCF video and now can binge and learn from you. Thanks!
Two things:
1) If you want to store the state of Terraform in a server, you have to rely on a proprietary solution.
2) Deleting and restoring a VM is easy. Exactly. But if a VM already exists because it was created by hand, you get a conflict with Terraform. The resolution is only possible by hand. With Ansible, this is not a problem. Ansible does not distinguish WHO created something.
General: Puppet has already tried to describe only the final state and not the way to the target. What was the result? There were always things that are done in a certain order. This can be mapped in Puppet only via dependency. And so you get a dependency hell very quickly. I suspect that I will run into the same problems with Terraform & Co.
But thanks for making the effort with the video. Keep going! These are important discussions that should be led.
1) Terraform can store state in Artifactory, AzureRM, Consul, COS, etcd, GCS, etc. There are, if I remember correctly, around 15 "standard" locations for remote state, and a bunch of others available through modules.
2) You can import existing infra into Terraform. But, to be honest, it does not work perfectly. Since, most of the time, Terraform would destroy and create instead of update, I rarely bother importing anything.
Terraform is mostly focused on the immutable way of managing infra which tends to be the preferable way in Cloud (public or private). So, it's not that much about the ability to manage (update) VMs are runtime, but more about creating and destroying VMs. In most cases, if, for example, you update a definition of a VM, it will create a new one and shut down the old one, usually using rolling updates when more than one VM is involved.
Now, immutability might not be a good fit for all use-cases, especially when working on-prem. In those cases, Ansible, Chef, and Puppet might be a better choice. They are mostly designed around the ideas of mutable infra. That does not mean that Terraform works only on the immutable level nor that Ansible/Chef/Puppet only deal with mutable infra. Instead, it's more about which of those is the primary focus of those tools.
Anyways... There is no on-fits-all solution. It all depends on what we currently have and where we want to be. As long as we are aware of how different tools work, we can make educated choices of what fits the best our use-cases.
@@DevOpsToolkit Interesting! That Artifactory is supported as backend store was new to me. Good to know. I had tried it with azurerm and got problems with lockings.
Nice summary. Like you rightly said, Crossplane taps into k8s ecosystem so it stands out with its sibling ecosystem providers in that
* SDK: K8s resource definition is the unified SDK for defining app workloads and cloud native services
* Control Pane: ArgoCD/Flux is the unified control pane to monitor the health of your app as well as dependent cloud native services
* Policy Mgmt: Kyverno is the unified policy mgr that helps one define & apply policies for k8s app services as well as cloud services provisioned via crossplane
Today I asked you this during the CNCF GitOps, great you already have it published! Thank you very much for all the details
My pleasure!
One simple reason to prefer HCL over JSON is that JSON doesn't support comments.
Is there an infra tool that is still working with JSON?
Using the Terraform Cloud Operator for Kubernetes is almost the best of all worlds and allows us to leverage the Kubernetes ecosystem. The main drawback is that doesn't seem to have any automated drift detection like Crossplane.
Auto drift detection and sync, together with the ability to use the same API (kube API) for everything is the main selling point of Crossplane. Now, one needs to weigh that against the size, stability, and market presence of Terraform.
Nice comparison.
+ Some other use-cases with General purpose languages are: DocOps(e.g Sphinx) or Unit testing! (something very useful for big organizations or large teams)
Imagine; if Hashicorp would have started with some general purpose language(instead of HCL); DevOps world would have been completely different!
They already have started with Terraform_with_CDK; its a bit late for something like this. I hope it will come out of its BETA state soon.
Can you do a video/talk that go more in depth about your thoughts on ansible and why you think ansible is on life support. Really interested and would love for you to speak more on this topic. Thanks!
Great suggestion! Adding it to my TODO list...
I’d love to see this as well. Look, I understand that IaaC and containers are taking over. That’s fine. There are still a ton of orgs, projects, applications, or infrastructure that simply aren’t there yet. Yes, it works great for microservices or applications developed with a cloud native mindset, but assuming that every devops in every shop everywhere can just adopt this without a massive amount of work is assuming a lot. Ansible’s standard library of modules can handle *so* much, more, I would assert, than any of the three tools reviewed. Try calculating subnet CIDRs simply in Terraform, or launching standalone Docker images based on templated variables per environment (with secrets able to be stored in Git) in Pulumi. The fact is Ansible fills a different niche than the other three tools reviewed - the former is configuration management and the latter three are infrastructure management. In fact, the latter usually rely on something like Ansible to post provision the infrastructure they stand up.
I agree that Ansible is for orgs "that simply aren't there". My mistake was to qualify that as on life support. There is a lot of legacy out there, and Ansible serves it well. Similarly, many might not want to make an investment to transition to something else, just as many are using mainframe, mutable VMs, Jenkins, etc. It's hard to make such an investment and, sometimes, there might not be enough ROI to do that.
That being said, I do not agree that it works great for microservices or cloud native apps. It doesn't. Ansible is based on mutable principles that are left overs from the times we all used bare metal. Today we have much better options on the table. What those options are depends on the task at hand. Managing infra alone is much more efficient with IaC tools. Many of us are packaging apps as immutable containers and managing them through Argo CD or Flux. Kubernetes is becoming the standard. Ansible is not a good fit for those use cases.
All that being said, Ansible is or, to be more specific, was great. I used it a lot throughout the years and it still has an important role. Nevertheless, that role is mostly tied to legacy systems and there's nothing wrong with that. It's usage will continue dropping, but it will also live for a long while, just as Jenkins, mainframe, and other widely used but old tech will continue living.
@@DevOpsToolkit I wholeheartedly agree that Ansible and microservices are a mismatch. I can almost guarantee though that Ansible will continue to be used for at least another decade. The others are really already dead; Ansible has survived because of its portability and simplicity.
@@bobbyray8457 Oh yeah. Within that same category of tools (configuration management), Ansible is without doubt the best. That's why it is the only one standing (RIP CFEngine, Chef, and Puppet). As you said, there is a need for such type of tool and it will continue being heavily used for years to come. The fact that it is not next-gen type of tool and that it's usage is not increasing, does not mean that it'll dissapear nor that there are no good use cases for it.
I shouldn't have said that it's on life support. That was an exaggeration and I shouldn't have said it. I could have explained it better.
I think Terraform CDK and Pulumi styles are popular over delcarative styles because they allow you to be more expressive and also open opportunities for us to test IaC. E.g. - what lessons can we take away from convention over configuration and an imperative style, versus having to declare everything over and over again? Also, testing declarative 'code' is really pretty hard. People understand how to test imperative constructs a bit better. Just my $0.02
Testing is indeed a strong argument in favor of using a general purpose language or a DSL.
The upbringing joke was killer 🔥🔥🔥
you are a story teller after all - well done. I liked your use of metaphors.
Glad you liked it!
I really like the idea of Crossplane although the chicken and egg scenario is much worse with Crossplane than with Terraform or Pulumi. For example with Terraform I usually include a module to set-up the initial state storage which is run once locally (and the state is just discarded or kept locally).
Also sometimes you just need to make a quick change to the infra manually in dev and it's not easy to tell Crossplane _not_ to reconcile those changes, it'll just pull things back which makes debugging really painful.
"Chicken and egg" issue is a problem, but mostly for smaller organizations. For bigger ones, it's actually the opposite. The is the initial investment into running Crossplane (e.g., k8s cluster), but letting etcd handle the state is much better than tf remote storage. TF state quickly becomes "complicated" when working with larger teams/operations.
Personally, I don't think that Crossplane is sufficiently good of a choice if one is managing only a few resources. It shines at larger scale.
As for a quick change... That's the same issue as with any something-as-code tool, and especially with GitOps. Once we start defining everything as code, we are forced or, at least, we should be forced to, follow it through. If, for example, you start using Argo CD or Flux, you'll have exactly the same problem. Once a tool starts managing something through reconciliation loops, we need to stick to the process (the tool). Otherwise, we easily get into the same situation as if we'd edit manually a Pod which is managed by a Deployment (through a ReplicaSet). Those tools/processes are intentionally making sure that the actual state is (almost) always the same as the desired state.
As a side note, one could argue that changing an existing YAML and executing `kubectl apply` is just as easy and fast as doing the same through, let's say AWS console.
P.S. When I created that video, I was only a user of all three tools. Since then, I choose to join Upbound (the company behind Crossplane). That might compel you to take everything I wrote above with a grain of salt and say that I'm subjective. The alternative could be that I did join Upbound because I genuinely believe in Crossplane. It can be interpreted both ways and I thought I should be open about it.
Interesting.
Crossplane fixes the drift automatically, one downside of this is, let's assume there is some incident and you need to vertically scale elasticache or add a node. The most easier way will be to directly change it from the console. Because during downtimes fixing things quickly is most important, it's more of a do-or-die situation. In the case of Crossplane changing from the console is not possible. Crossplane will detect the changes as drift and sync them again. :/
One could argue that changing the Crossplane CR is just as easy as making a change through the vendor API (including console). Similarly, if I would be managing infra through Terraform or Pulumi, I would do the same (`terraform apply`) instead of a console. The more you work with those tools (Terraform/Pulumi/Crossplane/etc.), the more you use them to manage everything, including "disaster" scenarios. For me, for example, changing manifests in any of those is easier and faster than through a console. Nevertheless, I can understand that for some (or many) that is not the case and, in that scenario, drift detection can indeed cause trouble, just as doing something directly with Pods would cause trouble since they are controlled by ReplicaSets which are controlled by Deployments.
Hi, thank you so much for all your videos,
One thing to mention about terraform, there is an alternative, you don't *have* to use HCL, you could use json. I'm personally templating terraform/packer configurations with jsonnet, so to use a templating engine already use for other services (kubernetes).
.
I do not agree that puppet ansible etc.. are dead, I give you the challenge to manage on-premise infrastructure with terraform. I agree that Terraform Pulumi and cross-plane are better options to cloud management but, is really a nightmare for on-prem. I think the best is a convo of two technologies, I'm coding with terraform the basic cloud infrastructure and with ansible or salt stack the configuration that I need to apply on-premise and cloud. Is possible to combine and automatize transparently the deployment on-prem and cloud
You're right. Saying that they are dead was an overstatement. A better wording could be "fading away". Their usage is shrinking and the chance of reversing that trend are very slim. So, those will stay with us for a long time, but their user base will continue getting smaller and smaller, just as on-prem will continue shrinking, but never fully disappear.
I would love you to do an update on this post, not sure if timoni, upbound and cue were in the picture when you made this awesome video 3yrs ago.
I made that video before I joined Crossplane/Upbound. I feel that if I would make it again it would be understood as being too biased.
TL;DR; It's still Crossplane. Otherwise, I'd go elsewhere.
Ansible has been my "to go tool" when I have to deploy in VM's or on-premise infra (servers) from a CI/CD.
Ansible is, indeed, probably the best tool to manage resources on prem, especially when immutability is not an option.
Thanks for this video and all the others you have created. Very informative. I just have one comment, about something I don't think you addressed in your comparison of the IaC tools, namely dependencies. What I mean here is that both Pulumi and Terraform offer out of the box intuitive ways to define configurations where there are dependencies between the individual resourcea and/or modules. Being able to easily set the input of a resource as the output of another and letting Terraform (or Pulumi) build up a DAG is extremely powerful. It's not clear to me how this can be achieved using Crossplane, at least from the quick googling I did. In some cases it's not important that one thing is created before another, but typically for infrastructure it is, i.e. a VPC must be created before a subnet for example. I love the idea of Crossplane, but unless I can understand how to do this in an intuitive way I'm not sure I could recommend that tool.
Crossplane has the concept of `patches`. Essentially, you tell it to get data from one resource and use it as a value of a specific field. If the source is not yet available, it will wait until it is.
Another great video from Viktor! a lot of useful information
Excellent insight as always - I would like to point a subtle correction on the native drift detection and reconciliation of feature that cross plane borrows from Kubernetes is Controller(read custom controller) or Operator - the famous control loop of Kubernetes NOT Scheduler. Please correct me in case I misunderstood.
You are right. K8s controllers are doing the control loop. I used "scheduler" as a more general term that envelops more.
Very intetesting watch. Thank you Viktor.
My infra tool is Terraform.
Holly cat, what an amazing content. Congrats to contribute with us to improve our technical skills.
Your all videos are must watch. Have you checked gardener to manage Kubernetes clusters?
I have it on my TODO list. Can't promise when I'll manage to make a video about it, except to say that it's comming.
Thanks for all the videos!
Regarding cross plane not having a “plan” step, maybe kubectl diff can fill in that role?
That's correct. `kubectl diff` provides similar functionality.
Thanks Viktor. Would you be kind enough to go through Composition in Crossplane maybe on AWS with EKS/IAM/VPC etc ...
Adding it to my TODO list...
Thanks for the quality content 😃, we appreciate it 😃
We hosts stateful apps outside k8s, so we leverage SaltStack, Terraform to manage these. We are considering Rancher, and checking out Crossplane now.
From this video, it seems like Crossplane is an easy way of writing Kubernetes operators.
I was somehow suprised that you add Ansible, Puppet, Chef and also CFEngine in compare to IaC Tools like Terraform. Feels super odd.
Ansible/Puppet/Chef users often use those tools to create infra, and not only to configure existing servers. From that perspective, I see them as IaC tools or, to be more precise, IaC could be considered a subset of config management tools, at least when practical usage is concerned.
That being said, I might be wrong and my sample almost certainly does not represent the industry in general.
@@DevOpsToolkit I agree. Although those tools were primarily designed and implemented to manage the configuration of servers, they can be extended and used to orchestrate the management of several infrastructure components. This is certainly not the best way to manage an infrastructure, but it can be done.
@@gbws Oh yeah. I was, for example, using Ansible for many years to manage not only configuration but also infrastructure. All the tools eventually start expanding and covering areas beyond their initial scope. Config management tools gained capabilities to manage infra, just as infra tools gained the capability to manage configs.
The major question is where someone is. If one has heavy investments in, lets say, configuration management with Ansible, it makes sense to use it for infra as well. But, if you're starting from scratch and you can choose what to use, I would always choose Terraform/Pulumi/Crossplane for infra rather than Ansible/Chef/Puppet/CFEngine.
I use Terraform and pretty happy about it.
Hi, Viktor. Is it true, that Crossplane‘s Compositions are build on top of proper Terraform provider, f. e. Azure Terraform Provider for building Compositions with Azure Ressources? And in general, that each Crossplane Cloud Provider uses proper Terraform Provider under the hood … ok now I have confirmation of it from some online sources. Just brillant solution!
I curious to know your thoughts on the route Terraform is going with things like Consul-Terraform-Sync. I don't imagine it would be a huge stretch in the future to get similar daemon functionality for other resource types to help with the issue of drift sync (similar to what Crossplane does)
I'm sure that Terraform is and will be investing in something like that. Now, Crossplane has the advantage of being k8s-native so it does not have to do everything. It can rely on the scheduler and the API to do a part of the job. That is, in general, the goal behind building tools designed for k8s. They can all leverage k8s and the ecosystem in general. Terraform will ned to put more effort to get to the same point when auto-sync is concerned. On the other hand, HashiCorp has more people so that does not need to be seen as a problem.
My main beef is with Consul. There is no good reason why I would run Consul in k8s that already comes with a similar tool (etcd). Consul might be better, but not sufficiently for me to ignore the fact that there is already a key-value store in my clusters.
Ansible is not dead; Ansible is not IaC.
Crossplane is out if you don't use K8s.
Pulumi costs money.
Terraform is great as long as there's a provider for your cluster; which in on-prem can become an issue.
I notice in general in your videos that you're using K8s as a service as if it's the most natural and widespread thing in the world, as if nobody would ever think or need to use a self-managed K8s cluster on a bunch of PCs. Or not use K8s at all 😲. That's fine as long as it's clear, you can't make videos for everybody everywhere; but then don't make sweeping statements like "Crossplane is the best IaC tool". It is if you're using K8s + GitOps + cloud provider; it is NOT if you want to provision Kafka on a bunch of VMs on PCs in an on-prem/offline mode.
This is not a critique, just an observation. Not sure how you could improve, I understand that you face limitations in what you can cover in 30-40 min.
Configuration management was transformed into IaC just as IaC is getting transformed into control plane, so, comparing Ansible and terraform does make sense just as comparing running apps in web logic and Kubernetes makes sense even though they are not called the same.
I do agree that not everyone has a Kubernetes cluster to serve as a control plane (not necessarily to run all the apps in there). Nevertheless, a significant part of innovation goes into Kubernetes and it's adoption is sky rocketing so it makes sense to have it as a focus. Similarly, cloud adoption is going up rapidly so it makes sense to focus on it as well. That does not mean that everyone is using cloud or Kubernetes or serverless or ... Heck, many companies are still using mainframe.
Many are using Ansible. There is no denying it. Still, it's usage is dropping with close to no chance of recovering so it is not dead, but it is on life support. Even if you look at providers with solutions for on-prem, you can see that Kubernetes and control planes are moving forward. Take a look at development in VMware, redhat, etc.
I thought crossplane was k8s specific whereas terraform/pulumi were general purpose.
Terraform, for example can manage github, aws, gcp, .., vm/docker images (via packer, ..).
It can also do k8s natively or via kubectl / kustomize / helm.
So you could in theory use both tf and cp on the same project - tf for everything except k8s and cp for the rest.
All three are general purpose. Crossplane runs inside k8s, but manages all sorts of infra just like Terraform and Pulumi. In other words, you can use any of them to manage anything (ignoring which one has more pre-baked libraries included out of the box).
@@DevOpsToolkit Awesome! Thank you for the videos!
Crossplane is going to be best IaC , It is just matter of adoption and when more resources available!
I am certain that kubernetes will be extended to manage everything. My bet is that it will be crossplane but that is not the main question. What matters is whether we will move from IaC to control planes and i believe they is inevitable.
Terraform can use Gitops feature right
Like for drift it can be done using GitHub actions so that any change in config can be done via trigger
Drift can be caused by changes to the desired state (manifests in Git) or by changes to the actual state. You are right only about the former case. If you change Terraform manifests, GitHub actions can trigger a process that will execute `terraform apply` which, in turn, will detect the drift and fix it. But, if the actual state changes (e.g., a node disappears, someone changes something at runtime, etc.), GitHub actions will not trigger anything since there were no changes to Terraform manifests (or anything else stored in Git). In that case, the drift will persist until you do change something in Git. To solve that with Terraform, you would need to run some kind of a cron job that would execute `terraform apply` periodically (e.g., every 3 minutes).
would be great to do a refresh of this video based on the current state of these tools!
I agree, even when I risk to get some hate from Viktor. 😁Nah, just kidding, but I guess he is busy like hell. It would be very nice to see this comparison with the actual state of all 3 tools, and maybe some newcomers, if there are any.
I'm trying to avoid that since after i made that video i joined upbound, the company behind crossplane. Since then, i am avoiding any comparisons since that would label me as subjective, and I'm trying to avoid that as much as possible. The only thing I will say is that i an privileged to be able to choose where i work so the fact that i am still with crossplane probably tells you what i think about it compared to other similar tools.
@@DevOpsToolkit I can fully understand this and it makes sense. I already made my decision to go with Crossplane anyway. The only thing I need to figure out now, is how to adapt it to my special use case where I can not use cloud providers, because everything needs to run and the data kept on servers in Swiss datacenters only. Regulatory and customer demand. I will figure out a way. Currently evaluating openstack self hosted. A lot to do, but I love digging into stuff.
@MarkusEicher70 it is open source so in the worst case scenario you might need to create a provider if one you need is not already available. Creating a provider can be relatively easy.
Hi Viktor, very nice video! Thanks for sharing. Don’t really get why you said ansible was out of life as new versions were released after your video. Would you mind clarify that? Thanks !
Ansible adoption is not increasing (outside redhat customers) or, to be more precise, is very low. On the other hand, some are moving from Ansible to terraform, pulumi, crossplane, etc. I do not see that trend reversing. I do not think that Ansible will change significantly enough to convince people using other similar tools to move (back) to Ansible. It is a similar trend as with on-prem and cloud. Some on-prem users are moving to cloud, and almost no one takes the reverse direction.
So, what I'm saying is not that Ansible is not making new releases but that it's userbase is shrinking and that I do not see that trend changing. Ansible is in a similar situation as chef and puppet were in the past. Both exist, both are probably having new releases, but their loss of users is irreversible. When that happens, contribution rate tends to drop, investments tend to drop, etc.
All in all, I stand by my words. Ansible is on life support. There are people keeping it alive but they are fewer and fewer in number. Eventually, the day will come when none will be there.
@@DevOpsToolkit got it, thanks for clarifying that out
Regarding Crossplane you'd still need something else to provision the cluster infra required for it to run on.
That is true. Crossplane assumes that Kubernetes is everywhere and that creating a cluster they will host it is relatively fast and easy. It could be even minikube. Once the cluster is created all the future updates of it can be managed by crossplane.
That being said, there is not denying that there must be a cluster created somehow before installing crossplane and that might be an issue for some.
On the bright side, crossplane is about to release SaaS version. That would remove the need to have a cluster (local one or a real one) before using crossplane.
Hey Viktor. There's a (relatively) new tool from Weave: tf-controller, which can reconcile Terraform in cluster, similar to Crossplane, but the big feature here is that you can use any of your existing Terraform modules. Also, it uses Flux's source objects. Any plans to cover it?
You could also compare it to Crossplane's Terraform provider, which does the very similar thing.
I already have it in my TODO list and I'll probably cover it together with a few other similar tools.
Isn't it possible to use kubectl diff to get a preview with crossplane? Why is that not on par with the preview functionality of terraform and pulumi?
`kubectl diff` will give you the difference in manifests, not the difference in the "real" infra resources that will be affected. Now, whether that is enough is a different question.
@@DevOpsToolkit I don't use kubernetes in my day to day work, so I'm not sure if I got this right, but in recent versions kubernetes can dry run server side and diff is based on what changes the server would actually make to the state, including crds, so it should be reasonably close to a preview - if the kubernetes resources actually represent the infra. However, as an author of those manifests, you're not actually changing the infra anymore, but the kubernetes representation. Kubernetes is going to change the infra after all.
I hope to get to work with it some day to see whether that is enough. Crossplane sure looks innovative to me and how I would want to create and manage infrastructure.
This is going to be another good one to watch. Thanks in advance
For management of AWS resources, what is the difference between crossplane and ACK (Amazon Controllers for Kubernetes), given that crossplane's AWS provider leverages ACK?
I haven't (yet) used ACK directly so I cannot judge the differences from personal experience. It's still on my TODO list which happens to grow faster than I can handle.
Crossplane supports multi-cloud (and even things like Helm providers).
Crossplane also lets you build composites. This gives ability for an InfraTeam to define MyCompanyRDSInstance which can give a simplified interface for AppTeam. For example, InfraTeam defines an interface which means the AppTeam only needs to supply name & storageSize (in other words, composites can define sensible defaults).
Composites become pretty important if you want to hide the more complicated stuff like VPC/SecurityGroups.
I wish AWS went all in on crossplane in terms of contributing...it's extremely good :)
Great video Viktor. Can you use kubectl diff in crossplane to see updates instead of applying directly?
`kubectl diff` works with Crossplane. Crossplane manifests are Kubernetes resources so any tool that works with k8s works with Crossplane. That's one of the big advantages of it. We can combine it with `kubectl`, `kustomize`, `helm`, Argo CD, Flux, and so on and so forth.
That being said, I don't think that you should be applying k8s resources with `kubectl`, at least not in production. Instead, it's better if you push them to Git and let GitOps (e.g., Argo CD, Flux) or CI/CD tools do the work. In such cases, you can get `diff` by reviewing PRs before merging them to the mainline (and letting other tools apply them)
I'm a bit late to the party, but since March 4, 2022, Pulumi has declarative YAML support. @Victor maybe we should have another run of this comparison? :D
I should do another run. All those tools are changing relatively fast, and new players are entering the "game" as well. I'll do my best to make a new comparison video soon.
@@DevOpsToolkit Take your time. On the other hand I think the Kubernetes scheduler is still the best approach when you really want to automate it all and don't touch it again. Nevertheless it would also be nice to see what has changed overall since your video.
For a diff in Crossplane you can use the Helmfile diff functionality: ruclips.net/video/qIJt8Iq8Zb0/видео.html
Or kubectl diff (new in 1.18), or kapp deploy --diff-changes
But how do you manage the state of the crossplane cluster 🤯
With crossplane itself. It's similar to argo in the sense that you need to set it up somehow but, once you do, it can manage itself.
I'm new at IaC tools, so I'm probably missing something, but doesn't Pulumi have one massive advantage: ability to query existing infrastructure and apply changes instead of defining completely new infrastructure? So for example, if there are some items that were created outside of IaC tool, you can use your favourite programming language to analyse existing infrastructure and tell Pulumi to not destroy those items.
That could indeed be an advantage. Personally, I haven't had those cases since whatever I define in Terraform/Pulumi/Crossplane is either new or is meant to take control of existing infra. Nevertheless, you're right. That is an advantage of Pulumi.
That's probably because I'm new, haven't yet figured out how everything works and still thinking as developer. Modifying existing infrastructure seems logical to me, but from various videos about IaC I've been watching, look like logic is different.
My goal is to automatically manage deployments of my app. I want to deploy it in several regions, use Route53 for latency routing to make sure users are routed to closest server, then, when either code or data set are updated, first add new servers and start app on them, then add Route53 records for them, then remove old Route53 records, then give some time before destroying old servers in case someone still has old IPs cached. Looks like things are much easier when using load balancers, but I can't afford that. Load balancers are expensive and I just need small EC2 instances in few regions, one per region. Trying to figure out how to set it all up and which tools to use.
Thanks for excellent videos, they are very helpful! Going to watch more of them because every time I watch one, things become a bit clearer.
It's not really an adavantage. In terraform most resources have a "data" counterpart that can be used to query existing resources for their setup and then your code can use those values to make decisions (how many NATs based on an existing VPC subnets, etc). Some of these data types have properties to filter (eg get all AWS AMI that meet certain criteria). Pulumi apparently has a notion of getting existing resources, so I'd say terraform and pulumi are on quite even footing for this aspect.
Also note that terraform never destroys what it does not own, and I believe Pulumi does same. Even if you use a resource name for creation that exists, terraform will say during plan stage that it already exists but it does not own it and will refuse to go further. You will then have to use terraform import or edit your code, depending on the situation, and apply again.
1:30 If you added Salt stack as well it would've been complete dead stack. Also Ansible will never die as long as Linux itself hasn't become an API!
I had to limit myself somehow, so Salt Stack failed to be mentioned together with quite a few others.
Ansible will indeed be with us for a long time. As a matter of fact, it is probably still the best option for on-prem infra. Others (e.g., Terraform and Pulumi) are too much oriented towards Cloud while Crossplane still does not have enough on-prem providers.
@@DevOpsToolkit I agree. Also, it looks like on premise environments aren't going anywhere for the foreseeable future. Whoever can bridge this gap or manage hybrid environments seamlessly is gonna stay here as a winner.
@@shinebayar Oh yeah. On prem is not going anywhere. It might not be increasing in usage, but it's here to stay. That's why most new products start with cloud (higher interest/reach), but, at some later stage, go for on prem as well.
The thing is that the tools that were initially focused on prem rarely make successful transition to cloud. We are yet to see whether the other direction will work. If it doesn't, there is the chance that the gap will never be bridged.
Thanks for sharing your thoughts, they're valuable. Regarding Crossplane, is it possible to use it without a Kubernetes cluster (as in bootstrapping)?
No. It must run in a Kubernetes cluster. Now, that can be just as well k3d or minikube running locally.
Thanks - very interesting video!
Does Crossplane have notion of Terraform data-sources to lookup / cope with existing resources? This is usually quite hard in the Gitops world where _everything_ wants to be described in Git ...
If you have a manifest that references an existing resource, crossplane will take control or link other resources to it depending on the context.
Still not sold on using Helm to modularize your IaC for Crossplane's case. Helm templating sucks as we all know. But in this case, I still have no idea how you would do it. You have to make a helm chart for, say, a VPC, and another for EKS? No thanks. It takes forever to make a chart, let alone, a bunch of them.
I don't see why would you have a separate charts for VPC and for EKS. If you would keep those in the same project in Terraform, I don't see the reason not to keep them together with Crossplane or, if you do choose Helm to wrap Crossplane, why not to have it in the same chart (excluding the possibility of organizing it as Chart dependencies).
Now, I don't think it takes any longer to create a chart that, let's say, to add variables to Terraform manifests. In both cases, there is a similar syntax how to use values within the manifests, and both are using separate files to store variable definitions (even though that is not mandatory with Terraform).
That being said, I would not recommend anyone to use Crossplane if not already working with k8s. On the other hand, if one is already working with k8s, Helm/Kustomize/JSONNet or something similar is unavoidable (for better or worse).
It is a good practice to separate resources based on its own lifecycle and purpose.
Separating the vpc from the compute allow you in the future to reconfigure your network without affecting/validating your existing resources.
An example I can give you is creating a vpc with a subnet for the cluster and in the future add new subnets for new resources that are managed outside the cluster lifecycle.
It makes easier and quicker to manage.
Regarding using helm, I am not a fan, I think it add complexity to things tja6 should be simple (yaml)
You videos are just great. Thank you!
I think you neglect an important component for the on premise crowd concerning the easiness of setting up crossplane: You need a functional kubernetes cluster.
This is trivial in the cloud where you have kubernetes as a service.
On premise, you need to provision your kubernetes workers, masters, load balancers, etcd cluster, your kubernetes installation and in all likelihood dns servers, bastions (and possibly also ntp servers depending on how stringent your self-sufficiency requirements are).
That's a fair amount of infrastructure you have to manage before you can even start leveraging kubernetes and this is where an infra as code tool that don't depend on kubernetes start to look pretty good. When you have to manage it yourself, kubernetes is not an operationally trivial tool with next to no footprint.
You're right. Creating the initial cluster is easier in cloud than on-prem. However, you do not need everything you listed. Crossplane, for example, does not need an external lb, DNS, etc. As a matter of fact, you can run it initially in minikube or rancher Desktop or any other local Kubernetes. Once you do have it running, you can start using it and that means that you can use crossplane to create and manage Kubernetes clusters even the one where crossplane will be running permanently. Since it all goes through yaml manifests (hopefully stored in git) it's easy to move stuff.
Still, you are right. It is easier in cloud, there's no denying it.
and what if you are not using k8s? not all clients like k8s, no matter how much you try to sell it to them, so a k8s dedicated tool is a no for a lot of cases
If you're not using Kubernetes, Crossplane is definitely not the option. There is no such a thing as the best solution for all use cases. So, I agree with you, except the part that says that "a k8s dedicated tool is a no for a lot of cases". Kubernetes is (becoming) a dominant platform and a significant percentage of companies adopted it. I would instead say that "a k8s dedicated tool is a no for **some** cases" given that k8s is today used in a lot of cases and it continues growing exponentially.
Using Crossplane... running Kubernetes on top of your cloud environment to setup your cloud environment... What could possibly go wrong?
Your point?
I agree. I think that using crossplane to manage its own dependencies (i.e managing its hosting k8s cluster after the initial bootstrap) will amplify the blast radius of some mistakes/incidents. IMO, you'd be prone to even more disastrous outcomes if you share the crossplane k8s cluster with tools used across your whole system (like log servers).
Terraform sucks if you manage across many environments. You cannot conditionally configure a provider. So now I have to maintain a separate code base for every combination of environment conditions or generate hcl in another language. This is why CDK and pulumi exist. I think crossplane is the future though.
Very good. Congratulations for this video !
Thanks
Thanks for the videos! I just discovered your channel. Good stuff!
Glad you like them!
7:25 -> this is where you earned my like ;)
Yep. That's why I do not prepare in advance a manuscript for my videos (only the commands). The less I prepare, the more truthful I am :)
This was great, just starting up an infra as data/code project and this was a nice overview. We definitely have a lot of on prem infra as well, so we might need some ansible in the mix
Ansible is, in my opinion, the best option for on-prem infra that should be treated as mutable. The alternative is to adopt immutable approach and, in that case, you would be building VM images instead of changing VMs are runtime. If you do something like that, Packer is a good choice. Nevertheless, that tends to be a complicated change for many so you might want to stick with the mutable approach with Ansible for on-prem infra.
@@DevOpsToolkit yeah I don't see us going all immutable on all levels just yet unfortunately. But I think we can do a lot with minimal use of ansible
There is no need to reduce Ansible to "minimal use". Use it for everything that is treating infra as mutable. It is arguably the best tool for that.
@@DevOpsToolkit Thank you I neeeded this specific answer... I have on prem hardware that by reqruiement must be bare metal K8s. I also 2 clouds and for those we use Ansible / Python for one and Terrraform for the other.
Thanks, this was fantastic!
I like your content and style, Victor, thanks! Just would be slightly better to reduce the font size in the term windows - hard to follow as it is.
You're probably right. I am trying to make it visible on all devices but that probably results in the font being too big on "real" monitors. It's hard to make it readable everywhere... I'll decrease the font in next week's video (the one for this Thursday is already done) and see how it goes.
well, I use clusters for every project, but I don't use k8s. So, having it for IaC don't worth it.
PS: Your opinion does matter - please, don't hesitate to share it.
Crossplane assumes that one is using k8s in some capacity or the other. If that's not the case, it is indeed not worth it.
Hi - very good video. Thanks for sharing it. Is it possible to use Crossplane and Pulumi together - use the power of k8s api using crossplane and imparative control using pulumi?
Yes you can :) You can use Pulumi to generate and apply Crossplane Kubernetes manifests.
@@DevOpsToolkit I am thinking the other way round - Use crossplane for reconciliation and instead of XRDs, pulumi for infrastructure definations. Any thoguths on this?
That can be done as well. I would not do it though since that would remove the benefits of Cards like, for example, having tailor made k8s resources for certain groups of "real" resources, GitOps, etc.
Crossplane seems really promising and I'll be testing that. The only problem I see is.... how to use Crossplane to create the cluster where it'll be running? Difficult there and, there, Terraform wins.... we could use both anyway for different things.
You are partly true. You need storage for terraform state created in advance. Once you do, you can use Terraform to manage that storage, just as you can use crossplane to manage k8s cluster where it's running. That being said, it is true that having a k8s cluster as a requirement is harder than creating a storage (even though creating a k8s cluster is easier today than it was before). Now, just as terraform, there is a cloud option. You can use crossplane cloud to run crossplane.
@@DevOpsToolkit you can create an S3 bucket before, using Terraform, and then store the state, plan and whatever you want there later. I've done that running Terraform from Python, so I handle those files as that.
I don't see how I can do it with Crossplane. I really want to try Crossplane, but that part... I don't know how to pass.
Maybe I create the first cluster using Terraform, install Crossplane and, all the rest, with it... I'll need to try and think...
@@DevOpsToolkit is crossplane cloud paid? In thinking on how to sell this to my company, he
@@AlvaroC77 You can do something similar, even though more complicated. You can create a local k8s cluster (e.g., k3d, KinD, Minikube, etc.) to run Crossplane and create the initial infra (including a k8s cluster). From there on, you can install Crossplane in the "real" cluster and let it manage infra (including the cluster where it's running). That being said, that initial setup is definitely more complicated than Terraform (unless you use .www.upbound.io/cloud/).
@@AlvaroC77 There is a free option (www.upbound.io/subscriptions/).
Would it be possible to use something like Crossplane in conjunction with Terraform ? As Crossplane acts as a K8s resource you could theoretically manage it via TF using the K8s provider right ? Then you could get the best of both worlds, vast provider support offered by TF (for providers that are not supported by Crossplane yet) and also the self healing capabilities made available for the resources managed by Crossplane.
Does this make sense ? Or is this example use-case just adding another tool (TF) for the sake of it ? Haha
Would love to hear your opinion ☺️
BTW just came across your channel and love the content! You have many other videos I have pinned to Watch Later :)
Personally, I'm not sure I like the idea of using Terraform to execute `kubectl`, `helm`, `kustomize`, or similar commands. On the other hand, combining Terraform with Crossplane is often a necessity, but I prefer doing that through automation tools. So, I tend to keep both types of definitions in Git and use Argo CD or Flux to manage Crossplane manifests just as any other types of k8s manifests, and CI/CD pipelines for Terraform or the k8s operator.
It would be interesting to see how to properly setup LitmusChaos with Crossplane.
Do you mean how to install litmus at the same time as creating the cluster or how to combine litmus experiments with stuff created by crossplane?
@@DevOpsToolkit . I intended to convey an interest in the later statement. It seems like a lot of disasters and interesting findings could be found if Crossplane is a K8s CRD controlling the cloud infrastructure on the same cloud account where the Kubernetes Cluster is running. Like IaC recursion.
The problem is that I feel that litmus might not be the best one to be combined with Crossplane. It's capabilities are mostly focused on k8s with close to none related to infra. I feel that something like chaos toolkit might be a better combination. WDYT?
@@DevOpsToolkit 😅 Well, I haven't actually used Chaos Toolkit, let me get back to you on that one! Thanks for the suggestion, I love your videos!
Great overview talk! Thanks!
I'm using Terraform. But one day I'll switch to Kubernetes ... so Crossplane stays on my radar screen. But still ... I'm learning Go ... so Pulumi is something to risk looking at it ... ;-)
All three (Terraform, Pulumi, Crossplane) are great tools. That being said, Crossplane is changing the way we manage everything (infra, services, apps) while Terraform and Pulumi are based on the same ideas. There is no significant difference between Terraform and Pulumi except in the format to define the desired state of resources.
Personally, I am not convinced that Go or any other full-fledged languages are the way to define the desired state of resources. On the other hand, I might be biased (I am heavily involved with Crosplane) so you might take that with a grain of salt.
Oh yeah. Go is my favorite language and it is the one used in most open source projects today. It is the way to go.
As a side note, Crossplane is 100% Go, just as almost any other k8s-related project.
what I want looking for, nice job 👍
Crossplane wins! Flawless Victory!
Plumi also supports YAML.
Kuberenets is a hyped cluster, it solves many problems but !
Personally, I believe that Kube API is the main thing. It is more important than the ability to run containers.
Very good
terraform cdk?
You're freaking hilarious!
can you provide the code of that you used in this video? terraform, pulumi and crossplane
All the commands, including cloning the repo with the manifests, are in a Gist. You'll find the URL of the Gist in the description of the video.
@@DevOpsToolkit I have created public subnet and private subnet. I'm creating the route table and associating the public subnet with internet gateway and private gateway with nat gateway. The route table is created but it is not being associated. And also I want to put name for the subnets. You can see the name field is empty in the image. How to do that?
subnet.yaml
apiVersion: ec2.aws.crossplane.io/v1beta1
kind: Subnet
metadata:
name: crossplane-public-subnet1
spec:
forProvider:
region: ap-south-1
availabilityZone: ap-south-1b
cidrBlock: 10.0.1.0/24
vpcIdRef:
name: crossplane-vpc
mapPublicIPOnLaunch: true
tags:
- key: name
value: crossplane-public-subnet1
providerConfigRef:
name: default
---
apiVersion: ec2.aws.crossplane.io/v1beta1
kind: Subnet
metadata:
name: crossplane-private-subnet1
spec:
forProvider:
region: ap-south-1
availabilityZone: ap-south-1c
cidrBlock: 10.0.2.0/24
vpcIdRef:
name: crossplane-vpc
tags:
- key: name
value: crossplane-private-subnet1
providerConfigRef:
name: default
routetable.yaml
apiVersion: ec2.aws.crossplane.io/v1beta1
kind: RouteTable
metadata:
name: crossplane-public-routetable
spec:
forProvider:
region: ap-south-1
vpcIdRef:
name: crossplane-vpc
associations:
- subnetIdRef:
name: crossplane-public-subnet1
routes:
- destinationCidrBlock: 10.0.0.0/16
gatewayId: local
- destinationCidrBlock: 0.0.0.0/0
gatewayIdRef:
name: crossplane-internetgateway
tags:
- key: name
value: crossplane-public-subnet1
providerConfigRef:
name: default
---
apiVersion: ec2.aws.crossplane.io/v1beta1
kind: RouteTable
metadata:
name: crossplane-private-routetable
spec:
forProvider:
region: ap-south-1
vpcIdRef:
name: crossplane-vpc
associations:
- subnetIdRef:
name: crossplane-private-subnet1
routes:
- destinationCidrBlock: 10.0.0.0/16
gatewayId: local
- destinationCidrBlock: 0.0.0.0/0
natGatewayIdRef:
name: crossplane-natgateway
tags:
- key: name
value: crossplane-private-subnet1
providerConfigRef:
name: default
Sorry for not responding earlier. I somehow missed this comment.
Which association is missing? ReuteTable with the Subnet? Is the `associations` not working?
@@DevOpsToolkit It is successfully associated now. By the way it was associated before but I was confused whether it is associated. I have put "Name" in key and the name is also shown now. Thank you.
Thanks!
- Configuration platforms dead? They have still lots of uses, and are far from dead, I think you are too concentrated on k8s here. Also, not sure why are you putting them on the same video. They are totally different beasts.
- Crossplane: find weird use a k8s resource to create something that has no relationshinp to k8s. Why? Why complicate it with helm k8s..... not sure what crossplane ,main purpose is. (monitoring drift is a minor issue, at least for me, can be achieved in different easy ways.But for me is even not desirable; in some instances, I want to be able to manually modify something and fix it when I want, not automatically. Is a useful option to have when you work in the real world.
- Terraform: It does not use a normal language because is deterministic and non-runtime dependant. That's the reason why it can "plan" what will be done. Agreed with pure yaml and being declarative also solves the issue, but terraform language provides a middle ground much simpler than yaml templating (helm or whatever)
> Configuration platforms dead?
if you look at the usage of CFEngine, Chef, and Puppet, they are clearly going away. That does not necessarily mean that they are bad, but, rather, that they are in the downfall and are hardly going to recover. That does not mean that they will not be used by anyone but, rather, that they are getting the same treatment as mainframe. It's there, we need it, but mostly because switching to something else is too expensive and risky.
What I might agree is that Ansible's days are not yet over. It might recover. It's not very likely, but it's possible.
In any case, those four are mostly used for the maintenance of the existing systems. Some use them for new ones, but that's mostly as a way to leverage existing knowledge.
> Why complicate it with helm k8s
Helm (or something similar) is not a complication, but a reality. Today, almost every company has something running in k8s. That might be 95% or 1% of their workloads. Nevertheless, k8s is there. That means that almost every company is using Helm (or something similar). From that perspective, Helm is not a complication, but a reality. We might have a discussion whether it should be Helm, Kustomize, JSONNet, or something else. But, one of those is present in almost every company.
> I want to be able to manually modify something and fix it when I want, not automatically
The question is not whether we should be able to fix something manually or not. Any of those tools assume that there are manual actions. Changing a manifest of something is a manual action. A better question would be whether someone should be able to change things directly without leaving a trace of that change (outside of the resource that was changed)? I believe that should never be an option. Whatever should be changed, should be pushed to Git first, unless it is a type of organization where there is a single person in charge of the whole system. Now, I understand that auto-sync might not suit everyone, and I can agree with that. That's perfectly fine.
> much simpler than YAML templating (helm or whatever)
I guess that depends on what we are used to. I don't think that using HCL templating is simpler (or more complicated) than using Go templating (that's the one used by most of the tools written lately, including Helm). Actually, that is not true. Go templating is more complicated because it does many more things than what is available in HCL. But, if we compare them for the same set of features, they are similar in simplicity (or complexity) and differ more in style than anything else.
I might feel more at home with one or the other, but that's mostly because I might be more used to one over the other.
I can see reasons to use Crossplane, just as I can see reasons in favour of Terraform. To me, usefulness of Crossplane in some (not all) scenarios is clear. The doubt I have is whether the benefits applicable to some teams and organisations (not to all) outweigh the benefits of using Terraform (assuming that they are already using it), including the learning curve (everything new has a curve) and the cost of switching.
you have to buy a lottery ticket if you can name worse documentation than crossplane, but still idea of crossplane is cool.
Docs are indeed not good. That will change soon but, for not, they are indeed far from being good.
Hahahah this is sooo funny and quality content!
Pulumi anytime
i just subscribe, nice video
Can I have the code for EKS?
Adding to my TODO list a variation of that material for AWS...
Do not agree regarding ci/cd. every step in a pipeline requires binary outcome - green or red, 0 or 1. if terraform/pulumi fails to apply there will be clear indication through non zero return code. with crossplane or k8s for that matter you have no idea and would have to implement custom logic to validate that apply actually happened.
The same can be said for using pipelines to deploy your apps to k8s, or for anything else that assumes eventual consistency. Instead, we tend to rely more on notifications and alerts. If that does not work for some use cases, k8s is not a good option.
@@DevOpsToolkit hmmm, are you saying that k8s/crossplane are not a good option for doing Continuous Integration/Delivery? Both techniques rely on the ability to validate every commit and require binary outputs from the steps to work so CI/CD system can notify a correct person regarding issues introduced by his/her change
Not at all. K8s and crossplane are great for CD. What I was trying to say is that both k8s and GitOps favor async processes and that might change how traditional pipelines work. Instead of having one pipeline, we might need many, each triggered on different events. So it's not 0 or 1 but rather "this pipeline built an image and pushed some change to a git repo and then a completely different process (e.g. Argo cd) deployed something and that triggered an event that might run another pipeline or do something else.
@@DevOpsToolkit well, this is exactly the point that I tried to get across in the initial comment. ArgoCD/Crossplane requires additional work to fit them into classic pipelines or additional work to re-engineer pipelines to account for eventual consistency. Thus they can't get the same score when it comes to CI/CD
Now I get what you meant. Yes. I agree.
What about Saltstack?🧟
I don't think it has many users. It kind of winded down.
Ansible EOL, chef dead..lol, Ansible is more popular then Terraform and IAAC does not mean only provisioning.You are comparing all the tools here on the basis of provisioning capabilities on cloud or may be only Kubernetes.
And switching from one tool to other very frequently works only for startups or may be on personal laptops :)
You are right that terraform is mostly for cloud primarily because on-prem is rarely treated through immutability. Nevertheless, Cloud usage is rising and, as a result, on-prem is going down. Not many use Ansible in Cloud and that means decreasing usage of Ansible in favor of Terraform, Pulumi, Crossplane and similar tools. That can be backed by looking at trends. We can see that over, let's say, 5 years, the usage of Ansible is dropping and Terraform and similar tools is increasing. No matter how many companies switch from Ansible to terraform, hardly anyone takes the opposite route, just as hardly anyone goes back from cloud to on-prem. So, it is not that much about the total usage of one compared to another but trends. Ansible reached its peak a while ago and it's downward trend is not likely to be reversed. That does not mean that it is not widely used, but that it's days of glory are passed, just as the days of configuration management glory are passed as well.
Hail Pulumi (C#)
I tried both terraform and pulumi. I hate pulumi very much! It is simply broken
I wish community give more love to sceptre project. it really has a potential like helm ... if only community adopts it, I could really be a better tool than these 3 ...
I haven't used Sceptre but, from what I saw on docs, it is limited to AWS. Typically, tools of that kind tend to succeed when they are not limited to a single provider since, on that case they compete with the tools of that same provider, get less adoption which leads to less contributions. Nevertheless, I haven't used it so I might be wrong. It might be based on an original idea that makes it stick from the crowd. I'll check it out and spend some time with it.
You are comparing apples and pears. You cannot compare configuration management tools with IaC tools. Each of them are for different purpose. You can bend them to do each others work, but it doesn't result in a good solution. I would say that CFEngine is dead, Puppet and Chef are on life support and Ansible is thriving.
You are right. They are indeed different types of tools, but thry serve a similar purpose. Both config management and iac tools manage infra and whatever is in it. The difference is that config management tries to do it in a mutable and iac in immutable fashion (even thought they can all do both). We are moving (or already are) into immutable realms for everything from infra to apps.
As for ansible... I do not think it's thriving. Many switched from Ansible to terraform, and there are hardly any cases of the opposite. That does not mean that ansible does not have a big user base (it does), but that it is slowly being reduced. It is unlikely that trend will be reverted. Part is partly due to immutability, and partly due to ansible not being seen as a good choice for cloud.
@@DevOpsToolkit Not true. Configuration management tools are here mainly to manage OS-level things where IaC is managing mainly the infrastructure (networking, VMs, ...). You can use Ansible to build cloud infrastructure but nobody sane would do that. The same, Terraform can manage OS-level things but nobody sane would do that. If you are fully in the cloud and all your applications are containerized, there is no reason to use Ansible. If you are running stuff on prem, then there is very little space for Terraform. Simply comparing configuration management tools with IaC tools will never work.
You are right. Ansible rules on-prem area, and will likely continue doing so. Personally, I think that on-prem should be managed by building VM images and instantiating VMs, but that is not what the majority does. So, you are right. Ansible is on-prem ruler. It's usage will keep dropping as more and more workloads are moving to cloud, but there will always be on-prem (in some capacity) and therefore, Ansible as well.
Thank you for you comment. I often forget that on-prem is still significant. As a result, I dismissed Ansible too fast.
@@DevOpsToolkit We got rid of Ansible for "on prem" config management in favor of Powershell (we're mostly a Windows shop running in AWS). We're still using CloudFormation for IaC in AWS but are starting to move towards Amazon CDK to abstract the CloudFormation code even further. It was mostly a choice that provides us with vendor support (and AWS lock-in lol, we're a very small team that does "everything", servers, networks, EKS, 3rd party SaaS, IAM, security etc).
That makes sense. If you are dedicated to AWS, using CDK is a good option (better than CF).
all those tool are great but they all lock you to a vendor.. that bad
Those are all open source tools.
Chef, Puppet dead ??? Ansible on life support, wait, what you said, which year is now, 2132 ??
Am I missed something ? I don't have experience with Chef and Puppet, and I don't care, but not sure about this software.
You're right. Those are not dead, just as mainframe is not dead. There will always be companies that will reject letting go of something. So, there will always be someone somewhere using Chef, Puppet, and mainframe.
As for Ansible, it's usage is dropping and that trend is likely going to continue. Hardly anyone new jumps into Ansible and every once in a while someone makes a switch from Ansible to Terraform, Pulumi, etc. That is especially true for those moving to Cloud (which is almost everyone).
@@DevOpsToolkit thank you for letting us know. I am having blast now. Just to be clear, I am in DevOps from April last year, but I am studying from beginning of 2020, and I have strong background in networking/Linux env. Is not like I am complete noob, just I didn't hear anything similar, but I understand your point. Really appreciate.
It all depends on where you work. Ansible is indeed used in quite a few companies. What I tried to say, but obviously failed, is that it is going down in usage.
two years down the road, neither pulumi or crossplan has really caught on in popularity. Google Trends shows very clearly that they are both not really popular. One the other hand Terraform is far far far ahead of them
You mean Google Trends? Page that shows you what people search via Google?
Let's remove Intellisense from IDEs and code documentation from Pulumi source (to make it fair fight with Terraform) and I guarantee you it will top up Terraform on Google Trends...
Fourth terminal .. ha ha
i don't like yaml '__')
hcl, nginx/juniper/caddy-style config are easier to read for me..
but for autocomplete part i prefer general purpose programming language XD
Crossplane will die faster than ansible....