Essay Proposal: FaaS, Serverless, Containerization, and DevOps

[Internet-Person-IP]

Members

Taqui - taqui@kth.se
GitHub: Internet-Person-IP

People will be added...I hope

Proposal

I want to create an essay where I discuss the basics of FaaS, Serverless Technologies and how they can be used to DevOpsify an application. I also possibly want to talk about the potential for a technology such as Google Cloud Run

The topics that will be discussed in the essay:

• Basic Introduction to Cloud
• Basic Understanding of Serverless, relevant terminology and how it relates to DevOps
• How Serverless can be leveraged to simplify the production of large-scale application
• How Serverless can be leveraged to DevOpsify an infrastructure
• How leveraging Serverless and Containerization can be used to simplify the production of large-scale application

[Internet-Person-IP]

Hi @Internet-Person-IP,

Thank you for considering my suggestion.

Hopefully, this reduction in the scope is enough.

Yes, LGTM now.

[cesarsotovalero]

@Internet-Person-IP, I'm merging this PR now.

[Wkkkkk]

Hi, @isacarvid and I would like to give feedback on this essay when it is ready. PR for feedback proposal: #1075.

[Internet-Person-IP]

@cesarsotovalero Hi César, I am currently working on this essay and I am facing some issues. Currently, I have about 2200ish words for my essay however I am starting to realize that the topics covered ended up being something like this:

• Basic Introduction to Cloud
• Basic Understanding of Serverless, relevant terminology and how it relates to DevOps
• How Serverless can be leveraged to simplify the production of large-scale application
• How Serverless can be leveraged to DevOpsify an infrastructure

This is a bit different from what I originally merged. I faced this issue as I was trying to make the essay more self-contained since you need to understand some concepts of cloud to fully understand the utility of Serverless.

My question is:

Should I change the essay to fit the original proposal or is it okay that it diverged a bit from the original topic?
Should I minimize the word count? It feels kind of hard to minimize the word count without some of the text sounding a bit strange. Is there some form of upper limit that I can try and follow for example 2080 words?

Thank you for you time and I hope to hear from you soon.

Btw, is the appropriate way to come in contact with you or should I have sent an email?

Best Regards,

Taqui

[Wkkkkk]

Hi, I’m very glad to read this essay. Here are some feedbacks.

Serverless has been a hot topic in recent years, therefore it’s great to read such an essay for those unfamiliar with it. When I see this proposal, I found its title very intriguing and could not wait to read it. The concept of Cloud and Serverless is well introduced in the beginning, so readers could have a glimpse of the essay at once. Later, as different topics are covered, the writer chained these concepts together and explained their utilization to each other. In this way, readers can not only understand each of them but also see the relationships between these concepts clearly. In the next chapters, Serverless computing and storage are introduced in a detailed way, which gives the reader a deeper understanding of Serverless and its possible application scenarios. Some examples are listed in the essay, such as AWS, a Serverless computing vendor and its attached relational database Amazon RDS. The conclusion wraps the content of the essay succinctly and points out the benefits of Serverless as to traditional architecture. Dozens of references are attached in the end.

This essay helps me to figure out several benefits of Serverless and motives me to try it myself if possible. As mentioned, lots of newfangled Serverless applications spring up recently. They tend to show greater availability and elasticity at a lower cost and fit the DevOps perfectly as most operations are automated within the cloud. The provided infrastructure frees developers from tedious management of their application. Examples are some Serverless database services like Auroma and DynamoDB. These services are often leveraged to different Availability Zones and therefore developers don’t need to deal with backups, scaling or possible failures anymore. This helps us to design large-scale applications at ease.

However, it’s worth pointing out that some drawbacks of Serverless architecture are not covered in this essay due to the word limit. One example is the so-called “cold start” issue. As the cost of greater elasticity, it may require a significant amount of time to start up a suspended application, which brings additional latency. Also, diagnosing performance or excessive resource usage problems with serverless code may be more difficult than with traditional server code, because although entire functions can be timed, there is typically no ability to dig into more detail by attaching profilers, debuggers or APM tools. Furthermore, the environment in which the code runs is typically not open source, so its performance characteristics cannot be precisely replicated in a local environment.

In addition, it might be better if some unsuitable computing workloads for Serverless, such as high-performance computing, are mentioned in the essay. Because of the resource limits imposed by cloud providers, and also because it would likely be cheaper to bulk-provision the number of servers believed to be required at any given point in time. When introducing all these concepts, the writer listed lots of facts to illustrate his thoughts but it should be better if some figures are added.

Nevertheless, it’s a great essay to read and I’m really inspired by the introduced benefits of Serverless. Let’s see if Serverless is the real game-changer?

PS: One great essay I'd like to share with Taqui is 《Cloud Programming Simplified: A Berkeley View on Serverless Computing》. It covers lots of interesting perspectives about Serverless Computing.

[Wkkkkk]

Hi @cesarsotovalero,
I wonder if it's OK for me to leave the feedback here in this way. This is within 24 hours after the task submission.

Kun