On Demand Functions Invoked By A Cloud Provider As A Service
Recently the term "serverless" has been thrown a lot in reference to provisioned, On Demand Functions Invoked By A Cloud Provider As A Service. Obviously we're not going to call them ODFIBACPaaS, so most of the web has decided to call them "serverless" instead. Simply put, you provide a block of code and define a trigger, a 3rd party cloud provider invokes this trigger and your code runs with inputs from the cloud provider. AWS Lambda (what is AWS Lambda?) and Azure Cloud Functions are the two most popular ODFIBACPaaS providers currently, both of which having support for a number of languages and triggers.
"Serverless" infrastructure has been riding the hype wave very steadily. There are new frameworks, libraries and toolsets made specifically under the guise of optimizing serverless development iteration. Claudia.js, the aptly named Serverless Framework, and Zappa are all very popular right now, specifically because of their ability to easily manage and maintain serverless infrastructure.
Why You Should Use Serverless
Serverless is, in my opinion, a more extreme step beyond the microservices movement of the past few years, all of which was sparked by a developer hatred of being locked into legacy codebases that are too large and too complex to maintain. Before serverless, the microservices movement pioneered the idea that you could deploy many services, all of which could be in different languages with different internals, that could work together to solve the same problems of their monolithic counterparts, but without coupling an entire product or architecture to each other. Turning a single system into a distributed system in favor of increased flexibility.
Serverless is one step beyond microservices. Now, each service is effectively a single function, and those functions don't require you to provision infrastructure (kind of). Instead, you provide the code and create a contract with a cloud provider to invoke your code under specific scenarios. This way, you don't even have to manage the infrastructure your code runs on, just the code itself.
Why shouldn't you use serverless architecture
Both the microservice and serverless movements simply shift responsibility from one place to another. Microservices require more infrastructure, but each service is smaller (which usually means easier to maintain), and totally decoupled from the other services. Your data aggregation service could be in Python for the dynamic flexibility of a scripting language, while your RBAC system could be in C# for increased performance and type safety. In a traditional monolithic system, these decouplings would be much harder to achieve.
But there's no free lunch. By moving towards serverless, you've just shifted all of your problems to a different location. As in, does each serverless function require its own github repo? CI process? Testing environment? What about each lambda's trigger? Are those version controlled? What about monitoring? How can you guarantee all of your lambdas are logging and running correctly? It's much harder.
Another issue with the serverless concept is the running problem. Say you normally would've configured an EC2 instance with a number of tools and functions coupled under one "service" or "application." You now do not have direct access to those tools from one another. It's totally possible to have a lambda invoke another lambda, but the question should be asked: is it a good idea? I don't know, seems like a Code Smell to me. But if you don't break them up, or you're locked into (in the case of AWS) a maximum of 300 seconds running time, then this is your best option. 300 seconds may seem like a lot of time until you consider the types of jobs that are normally contained in a microservice, and how not every job is simply fulfilling a REST endpoint's database SELECTs.
So should I?
I'm not sold yet. It's pretty new, and I'd be interested to see how companies/people that've held up substantial serverless applications for longer than a few months feel, but I've yet to find any of them.
What AWS services are serverless
Once you are ready to take the plunge, you can dive in on the AWS compute side of things with AWS Lambda or AWS Fargate. Fargate runs serverless containers, and Lambda runs directly in AWS. Fargate, with its integration of Containers adds an abstraction layer (and some complexity), but brings the added advantage of portability to other Cloud providers (GCP, Azure, etc.).