What do you think Azure Container Apps? Is it worth trying out? Are you already using it? Update: Since the time I worked on this video, Microsoft did come up with a YAML example (or I missed it since it's buried in ARM docs). Please use the link docs.microsoft.com/en-us/azure/container-apps/azure-resource-manager-api-spec#examples to check it out and huge thanks to Jiri Tyr for letting me know. His comment was deleted due to TH-cam policy that no one understands, so I thought it should be put here as a reference. IMPORTANT: For reasons I do not comprehend (and Google support could not figure out), TH-cam tends to delete comments that contain links. Please do not use them in your comments.
Would we use Dapr as a layer before Azure Container Apps? So Dapr > Container Apps > your project? Or do we have to increase the chain to... Dapr > Container Apps > Web Apps > Dockerized project > your project? And where in the chain would we throw in an event stream technology?
I'm not sure I understood the question... Think of kubernetes application consisting of a number of components each designed to perform specific tasks (e.g. deployment ensures a number of replicas is running, service deals with networking, etc.). Dapr is yet another one of those components.
@@DevOpsToolkit What I'm trying to say is if you start a new website project e.g. create rubyonrails or django project and save the files to your git repo... Now how many azure cloud services have to be used to get this new project to auto scale? Like do we have to containerize the repo first e.g. dockerize it as an image. Then upload the container to azure web apps, which we put inside of container apps... Then we connect Dapr and container apps with eachother so we control it from Dapr? I don't know anything about dev-ops that's why I'm asking. I like your videos though. In the Dapr one it left me feeling like it was basically a giant [settings] app, where you can switch out or turn on/off different tech services. Sorry if it doesn't make sense.
@@emonymph6911 1. Build a container image 2. Push the image to the registry 3. Instruct Azure Container Apps to use that image (Dapr is already included in Container Apps). That's the bare minimum. The rest depends on the way you work and whether you have additional requirement. For example, you probably want to push code to Git and let pipelines (e.g., GitHub Actions) build the image, push it to a container image registry, and execute CLI commands to deploy it to Container Apps. There can be many other things involved (e.g., testing). A good start are those 3 steps executed manually. From there on you translate that to automation. As for additional tooling... You probably don't need much with Container Apps (beyond pipelines). Container Apps are designed to be the "easy button" and the opposite of using Kubernetes directly (which requires many more things but also gives you more control). Does that answer your question? Please let me know if it doesn't and I'll do my best to expand on it.
Great video Viktor! thank you for the review and we are all expecting the GA of this service... by the way I hate ARM too, because of that I was happy when Azure Bicep was launched :)
Did you try using the YAML format that was output when you ran containerapp show ? It looks like that output is the schema you need to create a new app using the --yaml param.. Just a thought. I agree these commands are crazy, why add such complexity on top of K8s..
That, kind of, works, but is not what I'm looking for. That command assumes that container app is already running and I need to define it before that happens.
Another Knative adoption by major cloud providers without naming it. Knative offers both CaaS and FaaS feature and with Tekton and Cloud Native build back you can say " Come in with your git repo and walk away with a functional url" Holy grail of serverless computing. BTW CaaS should also support running state ful workloads and again Knative has the offering. Google Cloud Run and Google Cloud Run on GKE (with or without Anthos) already implemented the CaaS and FaaS commercially, not sure who is catching up to whom:-)
I don't think there is Knative below Azure Container Apps. I might be wrong though. As for catching up... When CaaS is concerned, everyone is trying to catch up with Google. GCR (with Knative below it) is, from my perspective, the golden standard that others are trying to replicate. It is technically the best CaaS solution. Whether it is successful commercially is a different thing.
@@DevOpsToolkit Without an iota of doubt, that GCR (on or off GKE)has set the standard of CaaS and FaaS combined. By far, GKE is also the best k8s managed service offering , in my opinion based on my limited knowledge and observation. BTW AWS has also tried to catch up with GCR with Apprunner since EKS Fargate was a far off dream in that catch up game.
On a demo app, latency was berable. It's in preview so I did not test it yet with "real" workload nor I bothered with the pricing. I'm waiting for it to go GA before going deeper.
Hey! Great video, silly that this manifest to describe Container Apps is not explained/documented by Microsoft. There is an alternative to ARM (which I agree is very ugly), which is Azure Bicep. I have seen information that it should support all resources ARM supports (because it's templated to ARM) and is more pleaseant to see and use. It is terraform familiar I think.
Part of the appeal of Azure Container Apps is the simplicity which is overshadowed by ARM (or Bicep). I guess that they will have an interface specific to it or, more likely, other tools like Terraform, Pulumi, Crossplane will implement it soon.
Hey, informative video again. You have mentioned that ARM images are not good for containers. Can I know more about this and which base images you suggested using? Thanks
We organised a group call with MS (organised through our enterprise agreement) to discuss what the azure replacement is for a windows service. They suggested container apps. Similarly, there are videos from Microsoft (eg from Scott H.) suggest that container apps are a good choice for "background processes". Windows services are always running. That's their whole "thing". They're not like web apps or azure functions that run "per request". They're always running. All the time. The pricing for azure container apps is described as being "by request". I wonder what the heck that is meant to mean in the context of a windows service processing data streamed over a persistent TCP connection. It seems like microsoft thinks everything is an http request.
As far as I know, Azure Container Apps are also always running. Their main advantage is that they scale automatically and you do not need to manage the underlying infra. On the other hand, that service is still in a very early stage, so it might be risky to adopt it right away. Also, you can always go directly with Kubernetes through AKS. The only thing is that I do NOT know for sure whether Azure Container Apps and/or AKS supports Windows containers. I'm guessing it does (it's Microsoft), but, since I don't use them myself, I am not 100% sure.
@@DevOpsToolkit These days a "widows service" really just means a .net worker running in a host configured to use windows services via DI... ie, it's just a console application with an infinite loop, so there's no actual need for windows containers for our purposes. We'd just take out the .UseWindowsService from the host builder. But I still have no idea how something that is running continuously, and which is processing streamed TCP traffic, can be billed on a "per request" basis :)
Followup! I was able to get a tentative answer to this from the engineering team at MS! I don't think I can share the precise details, but the essence of the answer is that there will be a way to configure a container app like a daemon or windows service (min and max replica = 1), and where the billing will be based on actual CPU and network usage. If there's near-zero CPU and low network usage, the container would be deemed idle and billed at a reduced rate. So they will eventually be releasing an additional pricing model that is not coupled to the concept of http request rate, but it's not ready yet.
@@DevOpsToolkit but I guess why do you think not. Scoping an api to become a crud operation with models and controllers is full featured. I want to try to explore this world but I have questions and hesitations. For me there are fair arguments about what are the downsides of function services but capability isn't one. Portability I think is a better reasoning. One thing for me is cost. However these server less app containers could address that. Along with portability. I'd like to discuss more if you have time.
@@Christiantheone I think that the one-instance-per-request model promoted with FaaS is not suited for majority of workloads. Also, many are still struggling with systems based on hundreds of microservices due to operational overhead. If whole systems are functions, those hundreds of microservices become thousands or more. Personally, I prefer CaaS (containers as a service) as is the case with Azure Container Apps. They allow me to choose what is in a container image (can be but does not have to be a function), how scaling works (it can be 1 replica per request or 1 replica per 100 requests), etc. CaaS is more flexible than FaaS (even though FaaS can be CaaS at the same time), it is more cost efficient, it can be faster, etc. That's why I was very positive towards Azure Container Apps, and negative towards, let's say, Lambda. I'd love to chat more on that subject (comments might not be the best communication method). If you feel the same, please pick any time that works for you from calendly.com/vfarcic/meet and we can talk on that subject.
Thanks!
What do you think Azure Container Apps? Is it worth trying out? Are you already using it?
Update: Since the time I worked on this video, Microsoft did come up with a YAML example (or I missed it since it's buried in ARM docs). Please use the link docs.microsoft.com/en-us/azure/container-apps/azure-resource-manager-api-spec#examples to check it out and huge thanks to Jiri Tyr for letting me know. His comment was deleted due to TH-cam policy that no one understands, so I thought it should be put here as a reference.
IMPORTANT: For reasons I do not comprehend (and Google support could not figure out), TH-cam tends to delete comments that contain links. Please do not use them in your comments.
Would we use Dapr as a layer before Azure Container Apps? So Dapr > Container Apps > your project? Or do we have to increase the chain to...
Dapr > Container Apps > Web Apps > Dockerized project > your project? And where in the chain would we throw in an event stream technology?
I'm not sure I understood the question...
Think of kubernetes application consisting of a number of components each designed to perform specific tasks (e.g. deployment ensures a number of replicas is running, service deals with networking, etc.). Dapr is yet another one of those components.
@@DevOpsToolkit What I'm trying to say is if you start a new website project e.g. create rubyonrails or django project and save the files to your git repo...
Now how many azure cloud services have to be used to get this new project to auto scale?
Like do we have to containerize the repo first e.g. dockerize it as an image. Then upload the container to azure web apps, which we put inside of container apps... Then we connect Dapr and container apps with eachother so we control it from Dapr?
I don't know anything about dev-ops that's why I'm asking. I like your videos though. In the Dapr one it left me feeling like it was basically a giant [settings] app, where you can switch out or turn on/off different tech services. Sorry if it doesn't make sense.
@@emonymph6911
1. Build a container image
2. Push the image to the registry
3. Instruct Azure Container Apps to use that image (Dapr is already included in Container Apps).
That's the bare minimum. The rest depends on the way you work and whether you have additional requirement. For example, you probably want to push code to Git and let pipelines (e.g., GitHub Actions) build the image, push it to a container image registry, and execute CLI commands to deploy it to Container Apps. There can be many other things involved (e.g., testing). A good start are those 3 steps executed manually. From there on you translate that to automation. As for additional tooling... You probably don't need much with Container Apps (beyond pipelines). Container Apps are designed to be the "easy button" and the opposite of using Kubernetes directly (which requires many more things but also gives you more control).
Does that answer your question? Please let me know if it doesn't and I'll do my best to expand on it.
@@DevOpsToolkit Thank you very very much
Great video Viktor! thank you for the review and we are all expecting the GA of this service... by the way I hate ARM too, because of that I was happy when Azure Bicep was launched :)
Bicep for the win!
Did you try using the YAML format that was output when you ran containerapp show ? It looks like that output is the schema you need to create a new app using the --yaml param.. Just a thought. I agree these commands are crazy, why add such complexity on top of K8s..
That, kind of, works, but is not what I'm looking for. That command assumes that container app is already running and I need to define it before that happens.
aws fargate?
I would not put Fargate into that category. It is closer to being a fully managed k8s cluster like, for example, Google GKE Autopilot.
OK, got it. Very good content by the way, thank you!
Another Knative adoption by major cloud providers without naming it. Knative offers both CaaS and FaaS feature and with Tekton and Cloud Native build back you can say " Come in with your git repo and walk away with a functional url" Holy grail of serverless computing. BTW CaaS should also support running state ful workloads and again Knative has the offering. Google Cloud Run and Google Cloud Run on GKE (with or without Anthos) already implemented the CaaS and FaaS commercially, not sure who is catching up to whom:-)
I don't think there is Knative below Azure Container Apps. I might be wrong though.
As for catching up... When CaaS is concerned, everyone is trying to catch up with Google. GCR (with Knative below it) is, from my perspective, the golden standard that others are trying to replicate. It is technically the best CaaS solution. Whether it is successful commercially is a different thing.
@@DevOpsToolkit Without an iota of doubt, that GCR (on or off GKE)has set the standard of CaaS and FaaS combined. By far, GKE is also the best k8s managed service offering , in my opinion based on my limited knowledge and observation. BTW AWS has also tried to catch up with GCR with Apprunner since EKS Fargate was a far off dream in that catch up game.
It uses KEDA and DAPR under the hood
Nice video! But how is the latency when starting from 0 instances? And how is the price?
On a demo app, latency was berable. It's in preview so I did not test it yet with "real" workload nor I bothered with the pricing. I'm waiting for it to go GA before going deeper.
19-20 secs for me in my experiment. (I would share a link but it might get blocked per Victor’s comment)
Hey! Great video, silly that this manifest to describe Container Apps is not explained/documented by Microsoft. There is an alternative to ARM (which I agree is very ugly), which is Azure Bicep. I have seen information that it should support all resources ARM supports (because it's templated to ARM) and is more pleaseant to see and use. It is terraform familiar I think.
Part of the appeal of Azure Container Apps is the simplicity which is overshadowed by ARM (or Bicep). I guess that they will have an interface specific to it or, more likely, other tools like Terraform, Pulumi, Crossplane will implement it soon.
Hey, informative video again. You have mentioned that ARM images are not good for containers. Can I know more about this and which base images you suggested using? Thanks
I probably did not explain myself well. I was referring to ARM which is Microsoft format for defining resources in JSON.
Looking forward to your dapr video!
Bumping it to be closer to the top of the TODO list... :)
th-cam.com/video/-4sHUvfk2Eg/w-d-xo.html :)
We organised a group call with MS (organised through our enterprise agreement) to discuss what the azure replacement is for a windows service. They suggested container apps. Similarly, there are videos from Microsoft (eg from Scott H.) suggest that container apps are a good choice for "background processes".
Windows services are always running. That's their whole "thing". They're not like web apps or azure functions that run "per request". They're always running. All the time.
The pricing for azure container apps is described as being "by request".
I wonder what the heck that is meant to mean in the context of a windows service processing data streamed over a persistent TCP connection. It seems like microsoft thinks everything is an http request.
As far as I know, Azure Container Apps are also always running. Their main advantage is that they scale automatically and you do not need to manage the underlying infra. On the other hand, that service is still in a very early stage, so it might be risky to adopt it right away.
Also, you can always go directly with Kubernetes through AKS.
The only thing is that I do NOT know for sure whether Azure Container Apps and/or AKS supports Windows containers. I'm guessing it does (it's Microsoft), but, since I don't use them myself, I am not 100% sure.
@@DevOpsToolkit These days a "widows service" really just means a .net worker running in a host configured to use windows services via DI... ie, it's just a console application with an infinite loop, so there's no actual need for windows containers for our purposes. We'd just take out the .UseWindowsService from the host builder.
But I still have no idea how something that is running continuously, and which is processing streamed TCP traffic, can be billed on a "per request" basis :)
Azure never stops being confusing.
@@DevOpsToolkit So true! I'm glad to see someone with some community visibility saying it XD
Followup! I was able to get a tentative answer to this from the engineering team at MS! I don't think I can share the precise details, but the essence of the answer is that there will be a way to configure a container app like a daemon or windows service (min and max replica = 1), and where the billing will be based on actual CPU and network usage. If there's near-zero CPU and low network usage, the container would be deemed idle and billed at a reduced rate.
So they will eventually be releasing an additional pricing model that is not coupled to the concept of http request rate, but it's not ready yet.
I never understood how someone would sell container instances lol. Cloud run is my favorite GCP thing so this is great for Azure.
Cloud Run is my favorite as well. Azure is behind, but on the right track with Container Apps.
Great content. Thank you!
Azure should give to clients some rewards or better costs, If they want us to try out their beta services instead contract more QA employees
Again, amazing video!
Could you make a video about KEDA?
I can. Adding it to my TODO list... :)
Done! th-cam.com/video/3lcaawKAv6s/w-d-xo.html
thanks, great video!
AWS Fargate vs. Azure Container Apps.
Adding it to my TODO list... :)
Nice!
Maybe also add cloud run
@@Masupialmi85 Agreed. It wouldn't be a good comparison without including a service from all "big three".
Sounds like Google Autopilot GKE, even with the resource limit limitations which for deployments with sidecars becomes quickly $$$….
I think it's closer to Google Cloud Run.
I use the hell out of function services that argument isn't viable. Endpoints are endpoints. I don't get the argument.
I'm not sure which argument you are referring to. Can you quote it here?
@@DevOpsToolkit you where arguing that fiction app services aren't useful. They are
I probably did not express myself well and wanted to say that they are not as widely useful as they were hyped to be. My bad.
@@DevOpsToolkit but I guess why do you think not. Scoping an api to become a crud operation with models and controllers is full featured.
I want to try to explore this world but I have questions and hesitations. For me there are fair arguments about what are the downsides of function services but capability isn't one. Portability I think is a better reasoning.
One thing for me is cost. However these server less app containers could address that. Along with portability.
I'd like to discuss more if you have time.
@@Christiantheone I think that the one-instance-per-request model promoted with FaaS is not suited for majority of workloads. Also, many are still struggling with systems based on hundreds of microservices due to operational overhead. If whole systems are functions, those hundreds of microservices become thousands or more.
Personally, I prefer CaaS (containers as a service) as is the case with Azure Container Apps. They allow me to choose what is in a container image (can be but does not have to be a function), how scaling works (it can be 1 replica per request or 1 replica per 100 requests), etc. CaaS is more flexible than FaaS (even though FaaS can be CaaS at the same time), it is more cost efficient, it can be faster, etc. That's why I was very positive towards Azure Container Apps, and negative towards, let's say, Lambda.
I'd love to chat more on that subject (comments might not be the best communication method). If you feel the same, please pick any time that works for you from calendly.com/vfarcic/meet and we can talk on that subject.