Serverless architecture – just hype or the future of applications?

A brief version of the brief history of time

Once our planet was dominated by dinosaurs. After that change happened and dinosaurs disappeared.

What was clearly a tragedy for some proved to be an opportunity for others.

It took hundreds of thousands of years for mankind to get from sparkling the light of its first fire, to building its first production server. Later on it took just a few years to get rid of traditional servers in favor of cloud and “serverless”.

Is serverless a mass extinction event of planetary magnitude – or simple evolution, taking us to a whole new green field of many opportunities to plant good seed in a good soil, grow it big and strong, before sawing the fruit of the new tech leap forward?

Let’s first explore the three approaches to build an application – monolith, microservices and serverless.

Monolith

Dinosaurs did not have a lot of problems. Actually, they had just one, coming at high speed. Monolith applications have a lot in common with dinosaurs. They don’t have a lot of problems, but they don’t have a lot of solutions either.

If your product is relatively simple, you won’t bother updating legacy systems in a not-that-distant-future or the complexity of updating it is not taking away from your good night sleep, you’ll be just fine building monoliths.

Microservices

Counterintuitively, sometimes less is more. In other words, smaller is better. In the case of microservices, there is a third interpretation – less Devs is more Ops.

Using microservices, you break the large monolith into smaller pieces and develop, test and deploy each one separately. You can probably see a little farther down the line– more microservices translate to more deployment, much more complexity and, on the plus side, more flexibility.

Do you gain or lose – or break even – moving away from monolith apps to microservices? Each case needs to be assessed separately.

What was that last one?

We have to be perfectly honest with you: so far, servers are doing better than the huge monsters that once roamed this planet, back in Jurassic era. They plan to stay around for the foreseeable future. Servers will not disappear, they will just hide, taking away your burden of managing them.

After all, serverless isn’t really serverless. It’s the plain old cloud – but for functions.

“Serverless” aims to split your application in functions: each task is separated in its own logical unit – a function – and executed separately in the cloud.

The upside is that at the end of each month, you only pay for what the functions have used – it certainly should be less than running the whole monolithic codebase all the time. On top of that, you know exactly what your application needs are – someone might say, to the function call.

It comes at a cost, of course: “wiring” the application, documenting it and troubleshooting issues is no walk in the park.

Serverless architecture could prove to be really beneficial for small projects or startup PoCs. For example, a customer asked us recently to migrate the static portion of his website to a CDN, and migrate the dynamic part to lambdas. After a few months, his website bill was significantly smaller percentagewise. We then proceeded with migrating parts of his monolith application – and achieved a smaller, more manageable and less resource-hungry application. But we never broke the core monolith – it would mean too much work for inconsequential savings. That’s why we suggest in-depth analysis of the pros and cons of such a move.

Not always greener on the other side

I hope no huge object coming from outer space would hit the Earth – at least not in our lifetime. Unfortunately, we have little to no control on that – same thing with serverless, by the way. We still hope it would work out just fine – but you know, there are risks.

A big downside of is the vendor lock-in. Benefits from using third-party providers come at the cost of giving up control. You have to dig in your soul and ask yourself how much do you trust them, beside the fact how much you are willing to pay them. Also, changing vendors is complicated – you’re largely locked in, unless you’re ready to take on a huge load of technical debt.

Furthermore, serverless is inefficient for long-running application calls. Sometimes, using long tasks can be much more expensive than running your own server or virtual machine.

Here’s another optimal example of serverless, using Azure as its backbone:

So, who is the lucky winner?

From a business perspective, it’s the startups. Certain cloud providers offer up to a million requests for free and you can have your MVP at virtually no cost. Then, you may scale as you please.

There is no better option for short real-time or near real-time tasks. Great examples are the IoT applications, where triggers manage your application’s behavior.

Chatbots are another candidate for serverless migration.

Image heavy applications can provide images with different size to different users and going serverless can decrease loading time.

Serverless is the ultimate agile approach: any time you have a piece of code done, it reaches production bar the burden of deployment.

One size certainly doesn’t fit all

If you’re looking for silver bullets, let’s set the record straight: serverless architecture is not suitable for every case. Do your homework, think about all pros and cons and draw the line.

Each new technology is just like the first sunrise of a new world, full of opportunities. What happens in that world, is, after all, up to us.