What is Serverless Architecture?
Before we know what it is, it is easier to clarify what it is not. Contrary to its name, Serverless does not really mean there are no servers. Serverless is a development paradigm where the effectiveness and execution speed of the code is the only thing a developer should care about.
The idea forms its basis in the fact that procuring and managing servers provides little to no differentiation for most businesses. As such, there is a lot of business advantage when it comes to time to market. The lesser time developers spend on analyzing how to run their code (whether it be legacy/on-premises/containers), the more time they can spend on providing differentiated business value. All a developer needs to know is that when they need a piece of code to execute, the code will be executed in a reliable and scalable fashion.
Can you think of a requirement where your request handling capacity should go from zero to a million hits in a fast and predictable
time frame (minutes or seconds, not days)?
Or another one where your servers and other resources are used seasonally, but sit idle for the greater part of a year?
Or another one where you are perhaps mashing up a number of APIs and adding some contextual processing in your system to provide more meaningful information?
Or perhaps you are just frustrated by clients not being forthcoming on what an actual load could look like on the go-live day, and you are uncertain how you are going to evaluate how many Oracle licenses you need to support whatever it is the client might need? Would a single license be okay? Would you need two just in case?
If you answered yes to one or more of the questions above, I believe Serverless is the way to go. Scratch that, you might want to think Serverless from the get-go when designing your software. Today (Dec 2016) that is the future, and the future is already here!
So how can you go Serverless? Well today, Amazon is the leader that can help you go Serverless with their
AWS offerings of Platform-as-a-Service. They have myriad solutions to pick from, and they have really
left Microsoft and Google a bit behind (as of Dec 2016, Alibaba has also entered this space).
Actually if you look at it, Amazon is really helping the industry in the sense that it has created a market, and while other players have not yet caught up, consumers will soon benefit from the seriousness of intent Microsoft and Google have shown. Oh, and I almost missed it, but Oracle has also realized that AWS can really eat into its enterprise business fiefdom - so expect some fireworks there.
There is also a Serverless Library out there that actually helps developers go Serverless, but this article is not about that.
Today any talk of Serverless has to talk about AWS Lambda, which has become synonymous with Serverless. However,
Lambdas are not the be all and end all of Serverless!
If you have never heard of it, essentially a Lambda (as in mathematics) is a function of single input. This function returns the same result when invoked multiple times, i.e. it is unaware of any context. An AWS Lambda models this behavior where in it performs an action based on this single input.
So you can trigger a call to a Lambda based on some event, and Amazon will execute this function for you in response to that event. The key thing here is to understand that Amazon will ensure your business logic gets executed. You will be charged only for the time your code would execute. This is pretty awesome as you can ensure your code is efficient and executes fast, and Amazon takes care of everything else.
Some Trivial Use Cases
Hopefully this gives you a general idea of what it means to be Serverless.
Here are some abstract ideas I feel suit a Serverless mindset. You could try building these to grasp the concepts in a better manner (don’t get bogged down by the ideas though – you can pick something that is simple enough for you).
Use Case I: I need a Service that can accept an RSS Feed and return a JSON-response of this feed.
Use Case II: In response to user making a restaurant reservation, I want to be able to send to the user estimated traffic conditions two/three hours before their actual reservation time.
Use Case III: In response to a user registering with my patient-care system, I want to verify this person’s SSN and Citizenship.
Use Case IV: In response to a spoken input, I want to be able to play a game with the rules defined by the players themselves (rip-off from Alexa samples)
Use Case V: Given an IP address, determine if a request has originated from the dark web.