All of this stuff looks cool in theory but i still cannot find a real use-case example where you rollout a green/blue/cannary deployment of a django application with database migrations (imagine database schema changing, how do you handle the database rollback etc.) ?
Those are different subjects. OAM and KubeVela allow you to define applications without going into all the details with k8s manifests. It's a way to define applications instead of k8s resources. Now, for bg/canary deployments of apps, you might want to use Argo Rollouts or Flagger. For database migrations you typically need to adopt a framework that will let you define DB schemas (I used FlyWay years ago, not sure whether it's still popular) and run a process that will apply deltas whenever you make some changes. You can do that with any pipeline tool (e.g., Jenkins, GitHub Actions, Argo Workflows, etc.). As for DB rollbacks... I don't think there is such a thing. The moment a single transaction enters a DB after you changed the schema, you cannot go back.
@@DevOpsToolkit Thanks for reply. I understand that these subjects are different but still they are related. To answer your original question; i believe it totally makes sense but IMHO there should be 100 examples in the repository instead of 100 issues addressing different subjects of the spec. Each example can expose different flaws of the system and guide to better specs.
Hi. KubeVela & OAM committer here. I have been subscribing to your channel for a long time. Loved the materials and learned a lot of stuff. It's fantastic to see something that I build show up in your channel here! I just want to say thanks for making this video and feel wonderful open source life is.
All meat and no filler! Awesome breakdown as usual. Wearing the hat on both sides was a great perspective.OAM might have earned the "VSA" (Viktor Seal of Approval) currently watching your conversation with Kelsey Hightower right now. Would have been fun to be in the chat for that one. Stay well good sir, I look forward to the next one.
Yes to "build your own platform"? If that's the case, we think alike. As a matter of fact, that's the main reason why I recently joined Upbound and got much more involved with Crossplane.
I was watching this video thinking wow, this guy is doing a great job of explaining this... Then I saw that you're Victor Farcic, and was no longer amazed at how good of a job you were doing explaining.... sorry but I'm no longer amazed when I see great presentations and articles from you. I've seen too many and it's no longer surprising. lol.
This is fantastic. I can easily see the power of Flux/Argo combined with KubeVela. But where do you see the split when incorporating Crossplane? It seems as though I could create a Crossplane XRD that abstracts away and does a lot of what KubeVela does at the app layer? I guess the proper separating line would be to have XRDs that provide developer-friendly infrastructure abstractions that will instantiate clusters and resources that can then be referenced by OAM/KubeVela ... All of course actuated via GitOps :)
You're right. XRDs are very similar to what OAM/KubeVela does. I did not see a strong reason to switch from XRDs to KubeVela except for some kind of uniformity in the format between app and infra manifests.
Thanks for the amazing video, I'm playing a little with kubevela in those days and this was pretty useful. Do you think is possible to use it combined with DevSpace? Would it make sense?
You can use it in any Kubernetes cluster. Since DevSpace can work with any Kubernetes resource, I don't see a problem there. That being said, I would not bother with KubeVela if preview/dev clusters and DevSpace are only goals. The true benefits are obtained if you go all the way until production.
Amazing stuff and looks very powerful. I really do not like many yaml, manifests, and this is a way to simplify and to focus on application. Other thing that I see on projects that expands the application config is extensive environment setting. Meaning variables from configmaps and secrets, many apps use many of those, as they are shared in between. I see that app declaration can be very nicely simplified with OAM, but env config can still make it big. I know it is somehow unrelated, but wonder if there is a way to simplify the env settings as well as they really explode the manifests. (including full configmaps and full secrets to env should not be desired - app should only "see" its dedicated variables)
I tend to bake configs into images, and overwrite them only with env. vars. that are specific to an environment. With that approach, the number of variables an application has (apart from those baked into images) is very small. Nevertheless, no matter the quantity of variables, Kustomize can help a lot. You can add configs into the `base` and then patch them for each overlay with those specific to an environment. Secrets, on the other hand, are more complicated, but they tend to be very small in number. You can use one of the secret agents like github.com/external-secrets/kubernetes-external-secrets if SealedSecrets are too complicated (they can be if there are too many secrets).
@DevOps Toolkit Hi, thanks for the great video. Has you opinion about OAM and KubeVela changed since the release of the video? Has OAM progressed to become the „standard“ and did KubeVela improve on docs and scope?
Victor, How do you differentiate the apps of app in Argocd, Crossplane compositions and Kubevela + Helm and Helm with multiple dependencies ? However Helm can be integrated with any of the tools.
Hi Viktor, To define the platform abstraction for appdevs , what is the best fit. As I mentioned above with 3 alternatives will be a perfect fit but when to chose what ? Could you throw some light on it.
i prefer crossplane since it allows me to define abstractions for almost anything. Since end user manifests are now very simple, on the client side, i prefer kustomize.
I know of one (big) company I worked with (but cannot share the name). Outside that one, OAM is gaining traction and it is almost certain that quite a few companies are using it. Unfortunately, outside the companies I work with directly, I do not have more info, mostly since I have the rule not to ask for details from those that contact me privately.
Hi, Great video, kubevela seems to be a really great. Do you have any documentation link for schematic definition using kube? I only found the component definition doc using cue but no luck with kube. Any resource would you have, please share.
Great video as always Victor. I have a question regarding this, creating the crds for different products, what would I gain vs using my own custom helm chart where the dev commits the value.yaml vs the oam kind yaml. I might be missing the bigger picture (first time seeing oam)
Helm and KubeVela serve different purposes. Helm is a packaging mechanism. KubeVela, on the other hand, provides a standard model for defining applications. Now, you can get something similar by defining a base Helm chart, and then let others create charts that use the base chart as a dependency and overwrite the default values of that base chart with whichever values would be specific for that app. Is that what you meant? On the other hand, if you create a chart for each app (not as a dependency of a base chart), then you are effectively creating manifests for each product while Vela would be enabling people working on that product to create their own manifests in an easy way. Finally, Vela enables us to create k8s resources so I can, for example, do `kubectl get go-app` to retrieve all the instances of the same type. It follows the "Kuberentes way" of doing things while Helm simply converts something to something else on the client side.
Kubernetes was designed to be extended and to manage resources through parent/child relations. The reason for creating your own CRDs and controllers is the same as the reasons for using a Depl9yment instead of defining directly Pods. Deployment manages replicasets that manage pods. When we define those, we define only deplyments and not all three of those. The same logic applies to any other types of resources, including those created with the help of kubevela. Realsticslly, especially from developers perspective, it makes no sense to have a deployment, service, virtual service, HPA, etc. It males more sense to define something called, let's say, app and leave to the cluster to figure out what are low level details. On top of that, olives, logging, and many other things become much easier once you define something inside a kubernetes cluster instead of doing that on the cliente side.
At the end of the day, the important thing is to understand all the options we have and choose the one that fits the best our specific use cases. Helm charts work well for many.
First thank you for the video, but I want to ask in frontend definition when creating the component you have fixed the port with the value 80. Does that mean 80 would be the default value and we can changed it or is it already fixed when defining the application?
Yes. It can be changed. Actually, any value that someone defined as changeable can be changed. It's all about creating new schemas that can be whatever you want them to be.
Unlike Go templating, CUE is a language with all the benefits (and downsides) that brings. It indeed allows us to do things that we cannot do with templating or, at least, it makes some things easier. Still, I'm not fond of CUE myself. If I'd be looking for a "real" language for those types of tasks, I would prefer something like Go or JavaScript or a DSL based on one of those.
What are you thinking? Does it make sense to define applications as applications instead of Kubernetes resources?
All of this stuff looks cool in theory but i still cannot find a real use-case example where you rollout a green/blue/cannary deployment of a django application with database migrations (imagine database schema changing, how do you handle the database rollback etc.) ?
Those are different subjects. OAM and KubeVela allow you to define applications without going into all the details with k8s manifests. It's a way to define applications instead of k8s resources.
Now, for bg/canary deployments of apps, you might want to use Argo Rollouts or Flagger.
For database migrations you typically need to adopt a framework that will let you define DB schemas (I used FlyWay years ago, not sure whether it's still popular) and run a process that will apply deltas whenever you make some changes. You can do that with any pipeline tool (e.g., Jenkins, GitHub Actions, Argo Workflows, etc.).
As for DB rollbacks... I don't think there is such a thing. The moment a single transaction enters a DB after you changed the schema, you cannot go back.
@@DevOpsToolkit Thanks for reply. I understand that these subjects are different but still they are related. To answer your original question; i believe it totally makes sense but IMHO there should be 100 examples in the repository instead of 100 issues addressing different subjects of the spec. Each example can expose different flaws of the system and guide to better specs.
I agree with that completely. There is an insufficient number of examples. Docs in general (including examples) leave a lot to be desired.
what do you mean by platform in the end?
Hi. KubeVela & OAM committer here. I have been subscribing to your channel for a long time. Loved the materials and learned a lot of stuff. It's fantastic to see something that I build show up in your channel here! I just want to say thanks for making this video and feel wonderful open source life is.
Thanks a ton. It means a lot to me to know that the author of KubeVela likes the video.
It's an amazing project. Keep it going.
Great work Hongchao. Keep moving!
Great video. I'm interested to see video about existing platforms you mentioned in the video.
It's coming next Thursday :)
Thank you for the video. Very insightful and informative 👍
All meat and no filler! Awesome breakdown as usual. Wearing the hat on both sides was a great perspective.OAM might have earned the "VSA" (Viktor Seal of Approval)
currently watching your conversation with Kelsey Hightower right now. Would have been fun to be in the chat for that one. Stay well good sir, I look forward to the next one.
Great video
Thanks!
30:30 - Yes to that question!
Yes to "build your own platform"? If that's the case, we think alike. As a matter of fact, that's the main reason why I recently joined Upbound and got much more involved with Crossplane.
Thank you sir
I was watching this video thinking wow, this guy is doing a great job of explaining this... Then I saw that you're Victor Farcic, and was no longer amazed at how good of a job you were doing explaining.... sorry but I'm no longer amazed when I see great presentations and articles from you. I've seen too many and it's no longer surprising. lol.
This is fantastic. I can easily see the power of Flux/Argo combined with KubeVela. But where do you see the split when incorporating Crossplane? It seems as though I could create a Crossplane XRD that abstracts away and does a lot of what KubeVela does at the app layer? I guess the proper separating line would be to have XRDs that provide developer-friendly infrastructure abstractions that will instantiate clusters and resources that can then be referenced by OAM/KubeVela ... All of course actuated via GitOps :)
You're right. XRDs are very similar to what OAM/KubeVela does. I did not see a strong reason to switch from XRDs to KubeVela except for some kind of uniformity in the format between app and infra manifests.
Thanks for the amazing video, I'm playing a little with kubevela in those days and this was pretty useful.
Do you think is possible to use it combined with DevSpace? Would it make sense?
You can use it in any Kubernetes cluster. Since DevSpace can work with any Kubernetes resource, I don't see a problem there.
That being said, I would not bother with KubeVela if preview/dev clusters and DevSpace are only goals. The true benefits are obtained if you go all the way until production.
Templating yaml again.
But this looks promising, tbh. I'll give it a try.
Amazing stuff and looks very powerful. I really do not like many yaml, manifests, and this is a way to simplify and to focus on application. Other thing that I see on projects that expands the application config is extensive environment setting. Meaning variables from configmaps and secrets, many apps use many of those, as they are shared in between. I see that app declaration can be very nicely simplified with OAM, but env config can still make it big. I know it is somehow unrelated, but wonder if there is a way to simplify the env settings as well as they really explode the manifests. (including full configmaps and full secrets to env should not be desired - app should only "see" its dedicated variables)
I tend to bake configs into images, and overwrite them only with env. vars. that are specific to an environment. With that approach, the number of variables an application has (apart from those baked into images) is very small.
Nevertheless, no matter the quantity of variables, Kustomize can help a lot. You can add configs into the `base` and then patch them for each overlay with those specific to an environment. Secrets, on the other hand, are more complicated, but they tend to be very small in number. You can use one of the secret agents like github.com/external-secrets/kubernetes-external-secrets if SealedSecrets are too complicated (they can be if there are too many secrets).
@DevOps Toolkit
Hi, thanks for the great video. Has you opinion about OAM and KubeVela changed since the release of the video? Has OAM progressed to become the „standard“ and did KubeVela improve on docs and scope?
Great question. I plan to release a follow up video about kubevela in a couple of weeks.
Victor, How do you differentiate the apps of app in Argocd, Crossplane compositions and Kubevela + Helm and Helm with multiple dependencies ? However Helm can be integrated with any of the tools.
I'm not sure I understood the question.
Hi Viktor, To define the platform abstraction for appdevs , what is the best fit. As I mentioned above with 3 alternatives will be a perfect fit but when to chose what ? Could you throw some light on it.
i prefer crossplane since it allows me to define abstractions for almost anything. Since end user manifests are now very simple, on the client side, i prefer kustomize.
Thanks Victor for this video, have you seen companies that use Kubevela in production environments?
I know of one (big) company I worked with (but cannot share the name).
Outside that one, OAM is gaining traction and it is almost certain that quite a few companies are using it. Unfortunately, outside the companies I work with directly, I do not have more info, mostly since I have the rule not to ask for details from those that contact me privately.
Hi, Great video, kubevela seems to be a really great. Do you have any documentation link for schematic definition using kube? I only found the component definition doc using cue but no luck with kube. Any resource would you have, please share.
I dropped KubeVela a while after i made that video so I'm not up to date with it. My preference goes to crossplane now.
Great video as always Victor. I have a question regarding this, creating the crds for different products, what would I gain vs using my own custom helm chart where the dev commits the value.yaml vs the oam kind yaml. I might be missing the bigger picture (first time seeing oam)
Helm and KubeVela serve different purposes. Helm is a packaging mechanism. KubeVela, on the other hand, provides a standard model for defining applications.
Now, you can get something similar by defining a base Helm chart, and then let others create charts that use the base chart as a dependency and overwrite the default values of that base chart with whichever values would be specific for that app. Is that what you meant?
On the other hand, if you create a chart for each app (not as a dependency of a base chart), then you are effectively creating manifests for each product while Vela would be enabling people working on that product to create their own manifests in an easy way.
Finally, Vela enables us to create k8s resources so I can, for example, do `kubectl get go-app` to retrieve all the instances of the same type. It follows the "Kuberentes way" of doing things while Helm simply converts something to something else on the client side.
@@DevOpsToolkit that was exactly what I meant 😊 and take your points, esp your last point. Thank you!
Thanks so much for the video. However, I do not really see difference between writing a componentdefinition and writing a helm chart and re use it!
Kubernetes was designed to be extended and to manage resources through parent/child relations. The reason for creating your own CRDs and controllers is the same as the reasons for using a Depl9yment instead of defining directly Pods. Deployment manages replicasets that manage pods. When we define those, we define only deplyments and not all three of those. The same logic applies to any other types of resources, including those created with the help of kubevela. Realsticslly, especially from developers perspective, it makes no sense to have a deployment, service, virtual service, HPA, etc. It males more sense to define something called, let's say, app and leave to the cluster to figure out what are low level details.
On top of that, olives, logging, and many other things become much easier once you define something inside a kubernetes cluster instead of doing that on the cliente side.
@@DevOpsToolkit agree, but I can give devs a chart, and they can configure the way the want
At the end of the day, the important thing is to understand all the options we have and choose the one that fits the best our specific use cases. Helm charts work well for many.
First thank you for the video, but I want to ask in frontend definition when creating the component you have fixed the port with the value 80. Does that mean 80 would be the default value and we can changed it or is it already fixed when defining the application?
Yes. It can be changed. Actually, any value that someone defined as changeable can be changed. It's all about creating new schemas that can be whatever you want them to be.
Fighting game stuff in the background?
yeah :)
CUE looks much better than go templating lang ...
Unlike Go templating, CUE is a language with all the benefits (and downsides) that brings. It indeed allows us to do things that we cannot do with templating or, at least, it makes some things easier. Still, I'm not fond of CUE myself. If I'd be looking for a "real" language for those types of tasks, I would prefer something like Go or JavaScript or a DSL based on one of those.