02 Feet in the Cloud, 03 Serverless Development

There is no Right Compute: Serverless Compute by Default

Reading Time: 3 minutes

The series of articles about Cloud Computing Evolution has ended with a big question unanswered – how to choose the right compute for a specific application. There is a tight relationship between application development and the compute it will run on. To better answer it, this series of articles will be in reverse order. Going from fully managed zero maintenance solutions towards high maintenance ones.

Serverless Compute by default

As I’m an advocate for resilience through maintenance minimization the first part of the series would compare Serverless Compute, Containers and Functions. In my opinion should be the default compute chosen as there would be less server/hardware set up or maintenance is required. That is effort invested into actual coding and money making [see the Philosophical Layer series]. 

In general, which would later be detailed, there are costs and considerations of choosing whether to go with Serverless Compute by default or not.

The experience required

Setting up a non-serverless compute and infrastructure requires a lot of DevOps related experience with a specific cloud provider. If you do not have the time to learn it or the resources for it, personnel and money, you’d better focus on the business objectives and focus on code/application development and go Serverless.

For an application developer, Containers (Serverless or not) require additional basic knowledge of building containers, writing Docker and Compose files and to manage a container registry. This does require practice and it is an acquired skill but one of high market demand and some would say is a must have for every engineer (or at least a backend one).

My personal opinion is that lacking this skill will not prevent me from hiring you, but once you start it’s one of the team’s four must have skills needed to develop and deploy an entire application end-to-end:

  • Dockerfile / compose
  • Infrastructure as a Code tool (Terraform)
  • Write CI/CD pipelines
  • Security/identity management

Fearing to adopt and learn to use Containers will quickly lead you down to bad application development and design decisions which will have grave costs all the way through from thousands of dollars to customer satisfaction. 

Faster, safer delivery

Serverless compute also manage your deployments. It simplifies and hastes the development to production process. The newest CI/CD platforms are Container based, running each step in its own Container. This is another good reason to learn about Containers.

When it comes to testing, they are executed in a production like context which guarantees discovered compatibility issues in advance. Generally speaking, it is harder to test Functions than regular application, but practice exists to simplify that. You can use AWS SAM for testing. Alas, not all cloud/FaaS providers have a similar tool so to keep your options open. You can also test your Lambda function within a Container that includes the Lambda runtime.

Lastly, it would be less of a security concern as there is no need to protect a server no one can log into.

This series of articles is not me telling you what to do, but what to consider. I have no idea which application you’d be working on. I actually had no idea which application my team and I will be working on for that matter [see I don’t know]. Remember that you know your task at hand better than me. Thoroughly know your use case and then compare it to the aspects reviewed in this series. Consider them only as “rules of thumbs”. They are not a “one size fits all” offering, not a strict yes/no comparison between the technologies and not a decision tree. Also keep in mind that technologies progress over time so their traits may have changed since I wrote this.

Let’s go!

Leave a Reply