Serverless Application Development
There’s been a great amount of interest in this subject for some time now. I was introduced to server-less architecture about a year ago. The technology was still in its infancy and needed a good amount of development before any production grade applications can call it home.
Fast forward and there are quite a few startups who have products based entirely on this architecture. Here’s what its about.
What is it
The traditional server is a web application written in a language of the developers choice which sits on a always on device receiving and responding to your requests. This setup consists of a database, a middle logic layer and the fronted. – the so-called three tier application. Or this was the case about a few years ago.
Since then it made sense to have the back-end of the application handle just that – the back end logic of the application and to develop the app as an API. and moving the UI, UX to a rich front end or a single page application or a mobile application. Server-less offers another layer of abstraction on how an app is constructed and also how its designed.
Server-less is not an entirely honest name for the concept. You do have a server of sort which awaits your requests and responds to it as needed. What it essentially is, is consolidating some of the commonly used features of a server application and leave customisation and configuration in the developers hand.
A Server-less offers an event based eco system. i.e something happens when something else triggered it. For a developer its fairly easy to boil an application down to this schema. – its like function calls. In-fact this service is mostly referred to FAAS – function as a service. All the logic layer a web application ever had was functions calling other functions as needed.
FAAS having abstracted some of the application needs only the functions defined to provide a usable service.
So effectively your application is now reduced from custom code based on a language framework to few functions wired up and your server side is done. These functions can be as complicated as your application dictates though there are some restrictions on run times.
There are quite a few FAAS service providers including Microsoft Azure Functions, Google Cloud Functions and Amazon Lambda. These Services are much about the same with each one playing innovation and catch-up.
Like I mentioned before FAAS reduces code base – by a lot.
All advantages of lesser code follow –
Lesser time to code
More economical application
Faster time to market
Lesser bugs, better testing.
You can code each function in any language supported. – JS, python or any JVM language is supported.
I haven’t even touched the best part. FAAS services are scalable by default. i.e service providers scale the function up or down any configuration necessary from you. – much lesser systems administration and maintenance,
Disadvantages or Problems?
Some technical aspects of FAAS implementation are still immature at this point. There is a good amount of development put in by service providers and eagerly waited by the developer community. Some of these are API gateway, Version controlling, local development setup and testing, packaging.
Load times – this is typically the first request after a period of inactivity of a function. Depending on the language used in the function, the response time may be from 10 milliseconds to 5 seconds. JVM languages need more time to load. Once loaded you can expect normal response times.
Different scheme of things – The architecture being different requires the application design to be different. Something that may or may not fit with most applications. Keeping functions alive needs to be a part of application design.There are limits, but most of the applications we encounter can quite comfortably fit into the schema.
For the most part, your application is abstracted by the vendor service and you rely on it for proper working of your application. Each vendor may implement the this framework differently – which means your code may-not be portable and you end in vendor lock-in. (Unless the opensource community comes up with a standard for implementing the framework and packing and deploying code.)
This may appear like bigger list of advantages and a shorter one of disadvantages. Frankly most of the disadvantages are technical in nature. There are workarounds, hacks and patches for these issues but
You can code each function in any language supported. – Not much of a disadvantage you can choose a language is stick to it if you like.
Is it for you?
Well.. Here are some facts.. There are
disadvantages problems currently with this architecture, but the advantages are just great. It offers a simple means to build an fast, economical, robust, scalable back-end system with a lower cost of development, maintenance.
I think the ayes have it. It seems to be a right step forward in application development.
There are currently many open-source projects in production to circumvent some of the technical problems of code management, setup etc. We will get over them shortly.
If you are looking to develop a new application – you should certainly think about Serverless.