Should you develop on-premise or in the cloud? The answer is the one we in IT love — of course, it depends, but you’ll hear why. Allegedly, most companies prefer on-premise servers (it was 98% in 2019, according to Spiceworks) for their software environment. It’s a bittersweet approach to application development that on one hand provides the most stability and security, but on the other requires resource-draining infrastructure management, which, eventually, pushes CTOs to find ways of optimizing development with cloud services.

You won’t hear about going cloud-first, because that’s unrealistic with most projects, as you’d still like to keep the option to tweak your architecture. But since upkeeping your own on-premise data center breaks the bank, staggers app deployment, and causes accessibility problems, you might wonder what magical innovation the cloud can offer this time.

What if you could run a part of your app’s services from the cloud, but pay only when they’re active?

That’s what cloud computing services offered by AWS, GCP, or Azure are about. The big promise? Cutting time-to-market and boosting scalability efforts, which contribute to much easier software deployment. I’d like to argue that among the two most popular cloud computing models — infrastructure-as-a-service (IaaS or the public cloud) and function-as-a-service (FaaS, often called serverless computing) — the second one delivers a highly competitive scalability environment, although it comes with one inky asterisk.

Let’s explore why multi-million dollar companies such as Netflix and Coca-Cola dare to use the serverless compute service to streamline development. Is this cloud gizmo something you can use?

Facts, please: what is serverless computing?

Serverless computing is a pay-for-use cloud technology for code execution. The cloud service provider handles 100% of server management, which includes traffic optimization, development environment updates, resource allocation, and backend configuration. Amazon’s AWS launched it in 2014 at the re:Invent summit as a technology that cuts down needles resource management developers get sucked into.

Imagine your cloud admin turned into a robot. You’re only concerned with creating functions to trigger events through code with component integration done for you. Rich in newfound time, the team refocuses on sprints to provide business value with apps delivered faster. Coding for serverless requires you to form a new mindset around the rules of cloud-native software development. If you worked with microservices before, you’ll find the learning curve manageable.

In that serverless gift box, there’s a framework for auto-scalability optimized to provide a stable development/deployment environment. You’re charged only for the time when a trigger event is active. As a bonus, serverless providers such as AWS, GCP, or Azure maintain high-availability hosting through their data center networks, so that worry is also out.

Now, in your skepticism, you might wonder why would anyone expand a proven on-premise environment (level 0) to the public cloud (level 1) or serverless computing (level 2) to ensure continuous software scalability. Down that road, you’ll most likely adopt a hybrid set-up that combines on-premise architecture with cloud services, so let’s see what are the realities between the three levels.

Resource management for on-premises, the public cloud, and serverless compared

Let’s set the stage for this investigation. Your app can run on an architecture that utilizes either, some, or all of the three, as scalability, availability, and performance can be optimized in many cases. I wouldn’t like to debate that. But as business owners tighten budget approvals, CTOs are looking to minimize non-critical spending, and that’s where our comparison starts.

On-premise architecture gives you full control of the runtime environment, which matters especially to enterprises in industries affected by cybersecurity issues. Budget optimization is rough, as the round-the-clock billing includes administration, operating system management, and talent retention (being a sysadmin used to be cool, now there are a few). If you need to scale up, you need to invest heavily in server deployment and the infrastructure around it.

Here’s when CTOs think about IaaS or PaaS public cloud. Scalability options level up, as regardless of how much you rely on cloud computing, you only need to calculate how many servers the app requires and request them from the provider. Depending on which one you call, you may still have the option to control server parameters, or you avoid that altogether, but now you avoid setting up any of them. Like with your phone plan, you pay for as long as the service is active. In practice, cloud servers can scale infinitely, but even when it’s less costly than with on-premise architecture, time and money are again a problem. Before scaling up or down, you need to add or remove application instances, which extend your billing period. We’re talking about thousands of dollars per month in some cases (see case studies below).

Serverless computing brings scalability-readiness up a notch, as without server management, everything’s faster when you can fixate on server-side code development. Developers who get used to the framework feel so much elevated in their project, as they’ve always preferred to work on providing technological output.

After you optimize the code to trigger functions in response to the event, the application will scale automatically post-deployment in response to the traffic flow. A sudden spike in demand will less likely break your system on a serverless architecture. TSH projects rely on the AWS Lambda service, which grants between 128 MB and 10,240 MB for each Lambda function the app uses while allowing from 1000 to hundreds of thousands of concurrent executions.

That — at least potentially — lets you use the serverless framework for simple system-state data collection or even machine learning trade predictions. The computing power is comparable with what IaaS or PaaS services can offer, but the pricing model is the deal-breaker, as serverless plans charge you solely for the execution time. When the app stays idle, you don’t pay, which is the no. 1 factor for serverless usage among the case studies I reviewed.

Why serverless computing matters for scalability

Tl;dr: with a potential 70-90% reduction in server costs because of its “pay per use” model, the serverless framework energizes rapid software development as teams cut down on handyman work. Without the bustle of infrastructure and server maintenance, you can deploy applications within minutes rather than months, using a rich bank of building blocks that can support full-stack coding in Node.js, Python, Java, Go, C#, or Ruby. You also deal with the problem of high latency that on-premise servers have. When it’s configured correctly, serverless architecture responds in 1-3 seconds through a cloud proxy closest to the user’s location, and it’s a near-guarantee that there always will be a data center available for all regions.

So the question is — what is it good for? We’ll look at the answers of the community around serverless.com with AWS Cloud (leading by market share) as our service of choice:

• (32.3%) Backend APIs

You can build low-latency RESTful and WebSocket APIs with Amazon’s API Gateway, which will process hundreds of thousands of web, mobile, IoT and 3rd party calls in real-time with automatic traffic management.

• (20.7%) Data processing

The serverless framework can be used for second-by-second data stream operations to process transaction requests, generate metrics, clean data, filter logs, or analyze social media. 99% of our apps generate image thumbnails with Lambda.

• (16.9%) Integrating 3rd party services

Sync your application immediately by connecting serverless components through webhooks to external APIs. If there’s a tsunami of requests, auto-provisioning will keep the system alive.

• (16.5%) Internal tooling

Slam overhead costs for your team’s custom-built app. Using serverless for simple applications — such as our internal HR tool — can bring the bill close to zero, if you have a load-read-click situation. It works for Machine Learning too.

• (7.8%) Chatbots

By using the serverless architecture, you can access a packaged chatbot framework with automatic configuration and deployment that communicate with other apps through an external API.  Want to stay informed on your preferred messenger? Program a chatbot to collect notifications from various sources that land in your Slack channel.

• (5.8%) Internet of Things

Even in this area, serverless can be a battery for innovation. Industrial, commercial, and private space monitoring with beacons works faster thanks to low-latency data transfers. Think about this: NASA uses the AWS IoT service because it comes with preventive security mechanisms.

Reduced costs, automated provisioning, response times counted in milliseconds. Got it. You now also know of a range of applications where serverless functions can carry your software’s load. How does the technology work in practice? Let’s consider four scenarios where CTOs decided to go serverless.

Case studies: how the serverless cloud changes development

Even though serverless remains a figure-it-out framework for some IT departments, several established companies implemented it to improve their deliverability with meaningful results. In some cases, Engineers built entire applications from scratch on the serverless framework, securing their service’s swift availability for international traffic that otherwise would down their servers during peak events (flash sales; breaking news; public holidays).

• Engineers at the Shamrock Trading Corporation moved over 100 services from Docker to serverless in 6 months after their proof-of-concept reduced server costs by x10.
• BBC’s Head of Architecture migrated BBC Online website onto a serverless computing service that handles over 100M invocations per day under a predictable cold start time.
• Cloud Forecast successfully crash-tested a $100 MVP application based on serverless functions which expanded into a stable SaaS platform.
• With serverless, Coca-Cola fought off vending machine maintenance costs, reducing them from $13000 to $4500 per year.

In 2019, Alban Diquet, a Palo Alto software engineer for Data Theorem, concluded: “Overall, we learned that with serverless, even though scaling is simple at first, someone eventually has to manage it. However, the good news is global scalability with serverless delivers better than anything we have seen in private data centers or anywhere else in public cloud infrastructure. 

For most cloud projects, my team uses the same stack including the Serverless Framework, Lambda/StepFunction, Node.js, TypeScript, and quite often PostgreSQL and DynamoDB.  AWS Lambda is our serverless playground of choice for MVP apps aiming to upgrade business processes here at TSH. The choice is simple. When once per year one of our developers is unoccupied, we challenge them to explore cloud solutions in-between projects, with serverless being easy enough to adapt and fast enough to build a prototype in a week or two. There’s a caveat, though.

When not to use serverless

As with many cloud technologies, choosing one requires compromises (or trade-offs) you should have in mind. If you’re facing aggressive deadlines, expect your developers to cling to their tools rather than to master serverless. With enough transition time, it might make sense to roll with the framework, unless it meets these conditions.

• The app you want to auto-scale has a steady traffic flow

Under a pay-for-use model, the monthly bill for using serverless or the public cloud evens out or extends, and the options that remain aren’t attractive enough to make a switch.

• Your team is inexperienced in cloud-development

Serverless requires your code to be re-modeled around functions and events. Sure, cloud basics can be learned in three months, but the know-how of how to work with them requires you to source talent with proven projects.

• Your app’s processes are heavy

There’s a limit for the time and number of tasks serverless can process. Users uploading large files on many fronts can cause a DoS.

• Vendor lock-in is a problem

To maximize the gains of using the framework, you should develop with the high-level services prepared by the cloud provider. But as the app evolves, refactoring to 3rd-party services for components like the database might be too much of a challenge, as it can require a major overhaul there’s no time for.

Cloud-native rapid development for the daring

As you see, adopting serverless computing for monolithic projects is a swift no. I’d recommend it as a solution for teams of backend/frontend developers who know their cloud if they don’t have infrastructure handlers in the office. If you can develop with pre-made services, the technology can be an answer for minimal-code apps that need to be deployed fast. Prototypes and MVPs built on serverless can show results in the very first sprint, which is super-motivating for the whole department.