Are containers, VMs, orchestration, etc. really needed in Azure PaaS?
-
I’ve been doing architecture and development in Azure a little over three years, and at the on-premise enterprise-level for nearly 40 years. The last couple of projects I designed in Azure, I went with PaaS instead of IaaS. No VMs, no load balancers, no containers, and no Kubernetes. Instead, how I configured the app services (scale up or scale out, as one example) took care of scalability, multiple regions, etc. replaced the older IaaS functionality listed in the 2nd paragraph. This greatly simplifies the design, makes support less complicated, and puts the responsibility for scalability and up-time on MS. I would like to read your opinions on the benefits/drawbacks to shifting that responsibility from an IaaS oriented design to a PaaS oriented design. Thanks in advance.
-
I’ve been doing architecture and development in Azure a little over three years, and at the on-premise enterprise-level for nearly 40 years. The last couple of projects I designed in Azure, I went with PaaS instead of IaaS. No VMs, no load balancers, no containers, and no Kubernetes. Instead, how I configured the app services (scale up or scale out, as one example) took care of scalability, multiple regions, etc. replaced the older IaaS functionality listed in the 2nd paragraph. This greatly simplifies the design, makes support less complicated, and puts the responsibility for scalability and up-time on MS. I would like to read your opinions on the benefits/drawbacks to shifting that responsibility from an IaaS oriented design to a PaaS oriented design. Thanks in advance.
Nope, not needed. VMs are just for legacy applications that can't run any other way. Containers allow you to spin up the same services across multiple cloud vendors, on premise, and developer boxes relative easy. So specifically if support for multiple cloud vendors or on-prem installation is important, consider using them. They also make it easier to spin up "random services" as part of your application without relying on the cloud provider having a PaaS version of that service - or them breaking it by upgrading it or other entertaining things that happens in the cloud. If you do not need any of this go as server-less as possible (or as I used to call it before the term was invented: shut-up-and-run-my-code... and I still believe this is the better name).
-
I’ve been doing architecture and development in Azure a little over three years, and at the on-premise enterprise-level for nearly 40 years. The last couple of projects I designed in Azure, I went with PaaS instead of IaaS. No VMs, no load balancers, no containers, and no Kubernetes. Instead, how I configured the app services (scale up or scale out, as one example) took care of scalability, multiple regions, etc. replaced the older IaaS functionality listed in the 2nd paragraph. This greatly simplifies the design, makes support less complicated, and puts the responsibility for scalability and up-time on MS. I would like to read your opinions on the benefits/drawbacks to shifting that responsibility from an IaaS oriented design to a PaaS oriented design. Thanks in advance.
I just picked up on "shifting responsibilities"; never an easy task; particularly if someone doesn't wanted to get shifted.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I