Web application deployment approaches

Question

Currently, our product is a web application with SQL Server as DBMS, ASP.NET backend, and classic HTML/JavaScript/CSS frontend. The product is actively developed and each month we have to deploy a new version of it to production.

During this deployment, we update all the components listed above (apply some SQL scripts, update binaries, and client files) but we deploy only the delta (set of files which were changed since the last release). It has some benefits like we do not reset custom data/configs/client adjustments.

Now we are going to move inside clouds like Azure, AWS, etc. Adjust product architecture to be compliant with the Docker/Kubernetes and provide the product as SaaS.

And now the question itself: "Which approach of deployment is recommended in the clouds?" Can we keep applying the delta only? Or we have to reorganize the process to always deploy from scratch?

If there are some Internet resources I have missed, please share.

Answer 1

This question is extremely broad but maybe some clarification could steer you in the right direction anyway:

Source code deployments (like applying delta's) and container deployments are two very different directions in the sense that the tooling you invest in during the entire SLDC CAN differ substantially. Some testing pipelines/products focus heavily (or exclusively) on working with one or the other. There will be tools that can handle both of course.

They also differ in the problems they're attempting to solve and come with some pro's and con's:

Source Code Deployments/Apply Diffs:

• Good for small teams and quick deployments as they're simple to understand and setup.
• Starts to introduce risk when you need to upgrade the Host OS or application dependencies
• Starts to introduce risk when the Host's in production begin to drift (have more differing files then expected) more dramatically over time

Slack has a good write up of their experience here .

Container deployments

• Provides isolation from the application (developer space) and the Host OS (sysadmin/ops space). This usually means they can work with each other independently.
• Gives an "artifact" that won't change between deployments, ie the container tagged v1 will always be the same unless you do something really funky. You can't really guarantee this
• The practice of isolating stateless components makes autoscaling those components very easy, and you can eventually spend more time on the harder ones (usually stateful).
• Introduces a new abstraction with new concerns that your team will have to mature into. Testing pipelines, dev tooling, monitoring/loggin architectures might all need to be adjusted over time and that comes with cost and risk.
• Stateful containers is hardly a solved problem (ie shoving an existing database in a container can be a surprising challenge).

In order to work with Kubernetes, you need to have a containerized application. That doesn't mean you need to containerize your entire product over night. Splitting out the front end to deploy with cloudfront/s3, and containerizing a stateless app will get your feet wet.

Some books that talk about devops philosophies (in which this transition plays a part)

The Devops Handbook

Accelerate

Effective Devops

SRE book