Guide to Serverless Architecture: What It Is, Its Benefits and Challenges

https://acropolium.com/img/articles/guide-to-serverless-architecture/img01.jpg

We’re used to servers being an integral part of software development. But recently, businesses have seen the rise of a new, serverless architecture. This way of running and building apps is gaining traction and has even caught the attention of the leading cloud vendors like Amazon, Google, and Microsoft. Does this mean we don’t need servers anymore?

Not exactly. The serverless architecture is not as “serverless” as it sounds, and it has much more to offer than eliminating servers.

“Serverless is good in some cases when you don’t want (or need) to bother with scalability and maintenance. But this architecture becomes a burden if you have huge volumes or complex logic,” says Oleksii Glib, Acropolium’s Founder.

Allow Acropolium to help you unpuzzle serverless architecture. After all, more than a dozen years in software development allow us to adequately evaluate buzzing technologies and use them to the client’s benefit. We’ve completed around 60 cloud migration projects, choosing the best tools and platforms to make our solutions secure, scalable, and cost-efficient. Serverless architecture, as well as serverless BaaS, containers, and frameworks, are part of our tech expertise. Keep on reading to find out:

• What serverless architecture is - and what it is not
• How serverless architecture works and when to use it
• The pros and cons of serverless architecture
• How to make the most of this app design

Market leaders are extremely optimistic about this kind of architecture. As businesses strive for faster time-to-market and more agile work culture, serverless architecture might tackle quite a few development issues. At the same time, it may become an expensive nightmare when used for the wrong reasons. So, let’s start looking for a balance.

What is serverless architecture?

Serverless architecture is an application design, or rather the code execution model in the cloud, where the service provider handles infrastructure management. This architecture is “serverless” for developers, as they don’t deal with system provisioning, maintenance, etc. So, in reality, there are, of course, servers; it’s just the cloud service providers that cover the backend part of development.

The key features of the serverless architecture are the event-based nature, automatic provisioning and scaling of the runtime environment, as well as capacity management, load balancing, security patches, and more. These features make the model attractive for enterprises of different sizes as they struggle to increase productivity and efficiency via cloud automation. And statistics confirm the interest: the global serverless architecture market is estimated to grow from $7.6 billion in 2020 to $21.1 billion by 2025, with North America keeping the largest share.

But the question is, should you jump on the bandwagon? It’s okay if you don’t know the answer yet. We’re here to explain serverless for you.

Serverless architecture covers two overlapping notions: backend-as-a-service (BaaS) and functions-as-a-service (FaaS). BaaS automates and manages the backend side, i.e., handles our need for highly scalable databases, messaging platforms, user management components, and more. FaaS, on the other hand, lets you run small self-contained, event-triggered functions in the cloud. They are deployed to a platform wholly managed by a vendor.

In a nutshell, serverless applications:

• require no management of server processes
• scale automatically
• operate based on cost-per-usage model
• offer implicit high availability (HA)

As you might have noticed, both BaaS and FaaS are united to create a serverless app. But note that the serverless model includes more than computing services only, which is a characteristic of FaaS.

Based on their purpose, we can differentiate several types of serverless systems:

• Core FaaS technology (compute/processing engine)
• Data layer (databases and storage)
• Event streaming and messaging
• API gateways

You can use various combinations of BaaS and FaaS components for a number of serverless architecture use cases. Still, it’s vital to differentiate them from another cloud model - containers.

Serverless architecture vs. containers

Serverless architecture isn’t the only one that’s cloud-based and allows deployment in small units. Containers (let’s think Docker) have many common features with the serverless design, even when it comes to the “no-server” part. Today, cloud-hosting container platforms like Amazon Elastic Container Service or Google Kubernetes Engine take the server management burden off the developers. Let’s take apart their differences.

Scalability

In serverless architecture, scaling is managed based on demand; it’s transparent and fine-grained. With containers, you had to manage the size and number yourself, but today, some self-scaling container clusters are available. There’s also a new thing like a serverless compute engine for containers - AWS Fargate. So, the scaling gap between containers and serverless design is narrowing.

Cost

The flexibility of containers puts a high price tag on this option, and they require more maintenance and setup than serverless services. If your workloads are dynamic, you should pay attention to the underlying services that power your containers and manage them effectively. In this case, the pay-as-you-go model of serverless architecture is more profitable. Still, containers will be cheaper when you have equal workloads all the time.

Maintenance

No maintenance issues for you if you’re dealing with serverless architecture. With containers, it’s the developer’s responsibility to manage the backend.

We can’t say that one design is better than the other; each fits the specific cases. For example, to move your legacy applications to the cloud, use containers as they can easily replicate your app’s running environment. But if you have unpredictable workloads, go for the serverless architecture since a container-based system is harder to scale up or down.

There are more cases where serverless architecture is a perfect choice. But to figure out the reasoning, let’s look into the mechanics of serverless.

How serverless architecture works

Compare serverless architecture to the traditional one. With the latter, we have several functions in the app and specific implementations of them. And with serverless, a new core is created for every function, the function is executed, and the system dies or becomes dormant. One function means one execution.

In the traditional scheme, the flow, control, and security are gathered in the central server application. But with serverless, components are more architecturally aware and, therefore, more flexible.

The pay-per-use model is critical here. In the case of functions, we pay for the number of times the function was called and the number of minutes it was working. The allocated memory for the function invocation is also added to the price. It is configurable, so the final cost of the function execution will depend on the configuration. If we talk about databases, we pay for the number of requests to the database and its data volume.

The scheme looks relatively cost-efficient, but we get many moving pieces to control, some security concerns since we rely on a third-party platform, and an increased need for distributed monitoring. To use all the benefits and avoid issues, we must understand when the serverless architecture works in our favor.

When to use the serverless architecture

Developing a serverless app is swift and easy. At Acropolium, we even had a case when our client managed to gather around twenty functions into a prototype in one month without a technical team. Just like this client, you can benefit from the serverless architecture advantages when you:

• Have a small project with simple mechanics
• Are building a PoC or MVP
• Need to start quickly
• Don’t want to bother with scalability and maintenance
• Unacceptable downtime
• Don’t want to administer the system
• Have large transaction volumes
• Need to jump from simple to complex architecture and don’t know the load beforehand

With serverless architecture, you can use the cloud more efficiently, sending your requests to various parts of the cloud and triggering a flow of events. Creating serverless single-page applications (SPAs) also makes perfect sense since they’re easy to deploy and update.

Still, serverless is not the best choice if your project implies long calculations, extensive memory consumption, and complex logic. AWS serverless architecture Lambda, for instance, has specific quotas for the amount of compute and storage resources you can use. So you should check whether the function configuration, deployments, and execution are still cost-efficient for a bigger project.

Also, note that you depend on a cloud provider and have limited control over your app’s architecture. This can mean anything from rate changes to forced API updates and may significantly influence your project. Let’s consider the serverless architecture advantages and disadvantages in more detail.

Pros and cons of serverless architecture

Before deciding on the architecture, evaluate your project and goals against the profitable use cases we’ve mentioned above. This way, you’ll be able to make the most of these benefits of serverless architecture.

Pros

The primary reasons teams choose serverless are the quick and easy start, minimal expenses, and effortless dealing with unstable workloads. Other benefits include:

Reduced operational, development, and scaling costs

Serverless allows you to work according to the “economy of scale” model: you’re paying less since the vendor provides the services to thousands of clients. So you’re saving on the infrastructure you share with other clients and the workforce you are sparing for other tasks.

As for the development costs, you won’t be bothered with anything BaaS can cover, like authentication or databases. The same goes for scaling - FaaS ensures automatic scaling based on the pay-per-use model. This is extremely profitable for inconsistent traffic and occasional requests.

Easier operational management

On the BaaS side, you support fewer architectural components. Scaling in serverless brings significant operational savings as well: it’s automatic, remember? Even if you use non-serverless auto-scaling, you still have to deal with setup and maintenance. Also, function deployment is easy when compared to server deployment (proven by the client we’ve mentioned earlier), and the solution doesn’t need any system administration.

Faster time-to-market

Function code is written faster. It’s easy to update, and developers can concentrate on the business logic, forgetting about infrastructure management. If we turn this into business value, less operational time means fewer people involved and faster time to market.

This also opens the way to experiments at a lower cost: we can test new ideas with low friction, bringing fresh ideas into the entire concept of product development.

The lower total cost of ownership

Reduced TCO is a result of the benefits mentioned above. The serverless architecture pricing model allows you to pay for the executed code and used memory only, involve fewer developers, optimize resources better, test and filter your ideas faster, and release MVPs more swiftly.

Summing up the benefits of the serverless architecture, you get a more agile business model, leverage cost-efficient pricing, your project is more flexible and easily scalable, and you profit from faster time-to-market.

But it’s not all roses, of course.

Cons

The critical thing you should remember about serverless architecture is that it’s far more expensive than other options if used for big, complex projects. And we’re talking not just about money but about the team’s efforts as well.

Vendor issues

First of all, you’re giving up control over your system to a third party, which can mean anything from rate changes to unexpected limits or system upgrades. Next, security issues arise due to multi-tenancy and other reasons. And let’s not forget about vendor lock-in: some serverless features are implemented differently across vendors. So if you decide to switch, you’ll have to do a lot of altering.

Cold starts

If the function hasn’t been called for some time, you will experience delays when sending a cold-start request. The latency can be quite significant, and the performance will be affected as well. For example, in AWS serverless architecture, the provisioning of the function’s container can take up to five seconds.

Time limits

Time-consuming or big data operations aren’t possible with Lambda functions as they have running limits (the current limit is five minutes). Also, big workloads with a long running time will be quite costly.

Configuration

You have a limited choice. And while AWS is dealing with the issue, you should be attentive to other, less mature platforms. It also makes sense to define the amount of CPU you need beforehand and choose not the cheaper but the more suitable configuration.

Complicated integration testing

While unit testing is not a problem within the serverless architecture, integration tests are not easy. As we use external systems, we don’t know how amenable those systems are to different testing scenarios. On the FaaS side, no local testing environment can fully simulate a cloud one. Sometimes, however, you can rely on cloud-based environments.

To wrap it up, the key issues with serverless architecture are giving up control over your infrastructure, some performance drawbacks, and significant security concerns. Some of the performance issues are already dealt with, but others, like vendor-related ones, don’t have a universal solution yet.

The bottom line

Serverless architecture, despite its confusing name, implies that you “outsource” your server-side operations to third-party vendors, making your development process “serverless.” This type of design unites two concepts - BaaS and FaaS, so serverless applications can use components from both concepts.

Having become a buzz term, serverless, however, is not a universal approach. You should use it for a PoC or MVP, when you want to start fast, or don’t know the traffic load. But for big projects with complex logic, where maintainability and complete control are vital and time lags are critical, choose the traditional server-centric model.

Though we tried to make the explanation easy, things aren’t this straightforward in real life. So if you need help evaluating your project and deciding on the optimal architecture or optimize your cloud cost, don’t hesitate to contact Acropolium. We will define your goals, calculate the expenses, and come up with a profitable business strategy together.