Putting on my best Anney Reese impersonationā¦āServerless Cloud Applicationsā¦ what is it?ā
Basically, it comes down to the fact that applications can be deployed in the cloud without end users or organizations having the ability to administer it. Itās a misnomer. Of course, the code is running on servers. The difference is serverless computing hosts applications on infrastructure that I would not be able to manage.
Admittedly, that feels really weird to me. How do I interact with these systems? Do I interact with them? Sure, I can get to the front end, but what if I need to tweak something on the back end? How do I do it? Can I do it?
Glenn Buckholz walked through a simple example of a serverless application and the answer is that there is a fair amount of specific testing we can do and direct interaction we can perform. However, as far as the idea of a āphysical serverā, that philosophy goes out the window. Rather than saying you are deploying your code on a server in AWS, for example, you are loading your code in AWS. Thatās basically it. If your code allows API access, the API can access it. If your code has unit tests, they can be run. Integration tests? Same. The difference is that the name of the server(s) you used to have to keep track of are no longer part of the equation. Also, the comfortable ssh connection we all take for granted is no longer there. Yeah, Iām working to wrap my head around that.
What does this buy us? In a word, scalability. Rather than having a complex (from our end) load balancing and scaling methodology, Cloud providers allow for the scaling to happen behind the scenes. That is both awesome and a little scary. Nothing comes for free and this implementation could be slowly dynamic or it could swell in a second or two. Imagine a DDOS attack on your site. The Serverless structure could literally expand to absorb that attack. Great for resiliency, but it could become rather expensive to have to run the app at that scale.
On the whole, it seems that the approach to these serverless applications is to help enforce ways to get the information with the application and infrastructure without the overhead (and potential for mistakes) that ssh or RDP would allow. There are some areas where testers will struggle to do common and expected things. Errors that we are familiar with and how they are generated will change in character. Our expectations of error handling need to adapt. Getting code coverage stats will be a little more challenging as the AWS or another cloud provider will have its own quirks and ways of displaying or making that data accessible. Also, these environments are shared. We donāt have control over what we are given access to and for how long or how much. In short, fine-grained control is lost. Also, the cloud provider will need to be consulted and worked with if meaningful security testing is to be performed.
Thus far, I havenāt had to consider or look at this option but wth the notion of multi-tenancy for applications becoming more and more pressing, Iād not be surprised to see this become a part of my future at some point.