Using Serverless Deployments with Pull Requests

So far, all the changes we made were pushed to a branch. That was on purpose since one of my goals was to show you the benefits of using serverless deployments with pull requests.

Benefits of using serverless deployments with pull requests

The percentage of the apps running as serverless inevitably varies. Some might have all the stateless applications running as serverless, while others might have none. Between those two extremes can be all shades of gray. While I cannot tell you how many apps you should run as serverless deployments, what I can tell you with a high level of certainty is that you’ll use Knative much more in temporary environments like those created for pull requests than in permanent ones like staging and production. The reason for such a bold statement lies in the differences in purpose for running applications.

Resource usage in preview environments

An application running in a preview environment is to validate (automatically and/or manually) that a change we’d like to merge to the master branch is a good one and that it is relatively safe to merge it with production code. However, the validations we’re running against a release in a preview environment are often not the final ones. A preview environment is often not the same as production.

• It might differ in size.
• It might not be integrated with all the other applications.
• It might not have all the data we need, and so on and so forth.

That’s why we have the staging and other non-production permanent environments. Their primary purpose is often to provide a production-like environment where we can run the final set of validations before promoting to production. If we’d do that ...