How to Enable Serverless Architecture?
Serverless architecture is quite a topic to talk about — it has a lot of benefits, however, they work under specific conditions only. Even though the concept is pretty simple, such ambiguity around its usefulness stops many companies from enabling it.
Apart from that, 36% of companies hesitated about adopting serverless architecture due to lack of knowledge, 22% found its working mechanism complex, 15% weren’t satisfied with subscription fees, and 26% couldn’t explain the reason at all — all these stats were taken from Coding San's research on the modern state of serverless architecture.
If you feel like one of the listed reasons or uncertainty whether serverless would be the right option is keeping you from adopting such an architecture, read on — we’ll provide you with a detailed explanation of serverless’ ins and outs.
In this article, we’ll talk about serverless architecture pros and cons, cases when it might be suitable, give you some tips and insights on this topic, and review top serverless architecture providers.
☁️ Serverless Architectures: How & When to Use
Serverless architecture provides you with an opportunity to develop digital products without having to build and maintain a backend server. What normally happens is: you find a suitable serverless architecture provider, subscribe to their services, you get access to it, and you finally set it up.
It’s important to know that serverless doesn’t actually mean that there is no physical hardware used as servers. The main idea is that you as a client don’t worry about how and where the data is stored and processed.
Such an architecture has its pros and cons:
- Simple setup. With a subscription, you get an onboarding guide, but it’s really easy. Certain functions like authorization or analytics don’t require coding at all.
- Free tier. Some providers offer you to use their server without any fees on special terms. For example, here's the Free Tier of AWS Lambda.
- Costs. You pay for what you use since the server activates per request.
- Scalability. In case you suddenly have a rapid increase in the number of active users, the server adjusts to it automatically.
- No maintenance is needed. All backend infrastructure is maintained by your provider.
- Faster delivery. Since you don’t spend time on building the backend server, you reduce the deployment time.
- Lack of control. Since you use the vendor’s backend, you can’t directly influence its structure.
- Vendor switching difficulties. When using the services of a certain provider, it might be complicated to change the vendor since most of them offer different workflows.
- Cold Start. If a certain function isn’t performed for a long time, latency occurs. For example, if the payment gateway wasn’t used for too long, you might need to wait 5 seconds or more for it to launch.
- Security. Since you don’t have any control over the backend (and it’s normally large-scale), you have to rely on the vendor in terms of server safety.
- Servers multi-tenancy. Most likely, you will be hosted on the same server with several other companies. It can worsen the performance and increase exposure to system breaches.
Taking all benefits and downsides into account, serverless architecture might be suitable for companies that don’t have a continuous flow of functions that need to be processed frequently. For example, it can be an app active during certain seasons like apps for football matches. They’re mostly inactive but when match seasons start, apps require a rapid scale, which serverless architectures are able to provide.
It might also be reasonable to outsource only some functions that are rarely performed. It’s possible to build your own backend for the rest of the features but relocate the least used ones to serverless so as to optimize costs. However, don’t forget about the cold start problem — to address this issue, we recommend talking to your developers about it since different cases require different solutions.
Another use case can be if you don’t want to take care of server maintenance, or don’t have skills, resources or needed employees for it. Yet, if you need something more reliable, we’d recommend using it as a temporary solution.
❓ FAQ on Serverless Computing
In this section, we’ll answer some questions on serverless architecture. We’ll try to cover as many details as possible, but if you’ll have more questions left, feel free to reach out to us. We’d be happy to answer them.
Does Serverless Architecture Work for any Type of Digital Products?
In case you’re wondering if it’s possible to enable serverless architecture for your product, the answer is yet. You can build such for all types of products — mobile apps, web apps, web dashboards, landing pages, websites, etc.
Yet, you should pay attention to what frameworks each platform supports since the set isn’t always the same. Plus, frameworks matter if you want to switch the vendor. If a chosen platform doesn’t host products written in the framework you used, it might be reasonable to opt for another one.
For example, if you write a code for the AWS Lambda platform and then decide to start using Microsoft Azure, you would have to either fully rewrite the code or adjust a big part of it for a new platform.
However, there’s a way to make the code as universal as possible. There are some platforms like serverless that allow you to write codes as universally as possible. Thus, it provides you with higher flexibility in terms of vendor choice and switching.
How to Use Serverless Applications Securely?
Security of the server itself is actually a responsibility that your vendor takes over. It means that you can’t influence it directly and have to rely on them in this aspect.
On the one hand, it’s beneficial since you don’t have to spend extra time and resources on it. On the other hand, you might not find the level of security a vendor provides sufficient, but you can’t really do much about it.
However, there’s a way for you to increase security without changing the server: database protection rules and security features. Let’s take a look at both.
Firstly, make sure that a limited number of people has access to the server. Moreover, limit access of those who already have it to an extent that’s enough for them to perform assigned tasks.
Additionally, you can create different levels of access for groups of employees. For example, junior staff — level A, middle — level B, C-level — full access. This way, you minimize the risks of data leaks and narrow down possible leak sources. It will also allow you to easier find the breach source in case it eventually happens.
We’d recommend asking potential vendors if they apply data encryption to the database directly. One of the best ones is considered Advanced Encryption Protocol (AES).
AES provides a 3-level cipher system, each level encrypts and decrypts data 1 time. A recipient and a sender own the same key to encrypt and decrypt data, which isn’t a good thing in terms of security. However, it’s up to the provider whether to use it or not, you can just ask them if they do and decide what to do next.
Another useful tip is to always have backups or automatically created copies — something where you can restore data from.
In this subsection, we’ll talk about security features that apply directly to your app, not the codebase. This way, you increase the security level of the whole ecosystem. Yet, to have any of these features enabled on the server directly, your vendor needs to provide/support them.
One of the biggest security feature groups is multi-factor authentication. It includes multiple features that allow you to ensure reliable access control. You can assemble authentication layers out of:
- Password system. You can require employees to create complex passwords with capital letters, symbols, numbers, etc.
- Biometric authentication. It can be face scanning, fingerprints scanning, voice recognition, retina scanning, etc. Not all devices are suitable for such features. For a more detailed review of your use cases, we recommend talking to your development team.
- One-time passcodes.
- Email and/or phone call access verification.
- Personal security questions & others.
Another great idea is tracking all system log-ins and marking all data that you get from device fingerprinting (if you enable such). You can register old and new log-ins and keep track of each action performed on sensitive data. It might not be as effective in terms of preventing leaks but it surely will help you to find the source of it.
You can also make sure to comply with security standards and recommendations that security regulations provide. We’ve also talked about how following leading cybersecurity companies’ social media profiles might be useful on our Linkedin profile if you’d like to check it out.
Are There any Alternatives to Serverless?
If we’re talking about alternatives that provide the same usage conditions as serverless does, it’s not wrong to say that this architecture is one of a kind. Yet, it’s possible to have similar benefits while using other server options. For example, we at Stormotion have extensive experience with Docker (containerization tools). Let’s take a closer look at this type of architecture.
With containers, the functioning concept is the following: the application code and the so-called dependencies (things that are related to the product) are packed into a separate box (container). You can then place this container into any environment as long as it supports container runtime. The good thing is, you don’t have to take out what’s in the container — you remain isolated on any server.
Containers are different from serverless in several ways. For instance, containers can run on any Linux and some Windows servers, while serverless is only available over specific hosting platforms (mostly public cloud ones). Thus, containers provide higher flexibility in terms of choosing a server — they can be used locally as well as on public servers.
Additionally, you can set up a container environment by using an open-source code for free if you do it yourself. Yet, you’ll have to either manage it yourself as well or hire developers to perform maintenance. Another thing is that you can containerize a product written in any language as long as the server supports it, meaning that you won’t have to adapt it to switch the server.
To conclude, containers might be a better option if you want high flexibility in choosing the host, have knowledge and/or resources to manage the server yourself/hire developers to do it. It will provide you with full control over the app.
Plus, containers are more suitable for prolonged functioning since serverless shuts down right after the function is performed. It also means that it’ll cost you less to host frequently repetitive actions and actively used products using containers since with serverless, you would have to pay for each action separately.
At Stormotion, we always find a solution to unite the best of two worlds and provide you with a container solution that has all serverless benefits, for example. If you’d like to learn more about it and ask some questions about your specific case, feel free to reach out!
✅ Top Serverless Architecture Providers: Review
Even though there aren’t hundreds of reliable serverless architecture providers, it still might be complicated to choose one. To help you with it, we’ve decided to review 5 of the most trustworthy ones and talk about their pros and cons.
It’s going to be:
# 1: AWS Lambda 🅰
Amazon offers a serverless platform called AWS Lambda. It natively supports Java, Go, PowerShell, Node.js, C#, Python, and Ruby frameworks. However, they provide you with a Runtime API so you can use other frameworks if you want. To deploy your code, Lambda asks you to upload it as a ZIP file or even container image and then takes care of its maintenance automatically.
Amazon offers a free version that provides you with 1M requests and 400,000 GB-seconds each month (the runtime of a function multiplied by the memory consumed is 1 GB-second). The premium version will cost you $0.20 for every 1 million requests and $0.0000166667 for every GB-second.
To make the price comparison easier, let’s take these metrics as a rule: it takes 1000 ms (1 second) for a function to perform, there are 10,000 requests a month, the memory is 128MB. Plus, you’ve already used your monthly Free Tier.
- Total compute (seconds): 10,000 * 1s = 10,000s
- Total compute (GB-seconds): 10,000s * 0,125GB (we turn 128MB into GB; 1GB = 1024MB) = 1250 GB-seconds
- 1250 GB-seconds * $0.0000166667 = $0,02
With such usage, you’ll pay $0,02/month. We simply wanted to show you how it’s calculated but you don’t need to do the same since there’s an automatic calculator that Amazon provides.
One of the main benefits of using Lambda is its belonging to Amazon — since this company is one of the biggest and most large-scale ones in the world, it provides its customers with a wide range of additional Amazon Web Services for outsourcing even the most complex systems. For example, Amazon CloudWatch for monitoring and logins tracking, AWS Identity and Access Management (IAM) for managing access to all AWS products you’re using, Amazon RDS Proxy to improve an already automated database management, and many others.
However, the customization level is pretty low — the biggest part of the platform’s functionality is chosen for you. Plus, there’s a limit for your ZIP file with code to deploy. It can’t be more than 50MB zipped and 250MB unzipped.
# 2: Google Cloud (Functions) ⚙️
Cloud Functions is a serverless architecture solution from Google. Each function on this platform is isolated, with its own configuration and environment. To start using Cloud Functions, you’ll need to set it up by installing Firebase CLI to start the project, write functions, test them using the emulator, and finally deploy.
When it comes to pricing, there’s also a Free Tier that offers 2M invocations and 400,000 GB-seconds per month at no cost. After that, you pay $0,40 for 1M and $0.0000025 or $0.0000035 for 1 GB-second (depending on the region you’re in.
Let’s take the numbers that we used for Lambda calculations:
- 1250 GB-seconds * $0.0000025 = $0,003 (for Tier 1 regions).
- 1250 GB-seconds * $0.0000035 = $0,004 (for Tier 2 regions).
As you can see, it’s cheaper than AWS. Plus, it’s possible to get discounts for the long-term usage of services; there are also special packages for startups.
Plus, Cloud Functions platform (unlike Lambda) installs all product’s dependencies automatically so users don’t have to spend time on setting them up as well.
# 3: Microsoft Azure 💻
If you decide to use Azure Functions, you would have to create an Azure account first. It’s free and gives you a bunch of benefits for registration like 12 months of free services, $200 that expire in 30 days so you can test some services, and more than 25 services that are free by default. Then, you write functions in a supported language (Azure provides you with a short guide on how to do it). And before deploying, Azure recommends getting acquainted with Azure Functions Documentation.
There are various subscription plans that Microsoft offers. They provide potential customers with an informative overview for each one of them as well as comparative tables to choose the suitable plan. Generally, the pricing is similar to what AWS Lambda offers: 1M requests and 400K GB-seconds free on a monthly basis and then $0.20 per million requests and $0.000016/GB-s. Thus, its fees are almost the same as those of Lambda’s.
One of the main benefits of Azure Functions is its emphasis on cybersecurity — Azure provides access to multiple security tools for risk prevention, access management, data safety, etc. Additionally, you can deploy functions on other platforms as well. Apart from Azure Functions, you can use App Service (PaaS), Kubernetes, Azure Stack, and IoT Edge. These are not just alternative options but they focus on different deployment types — cloud, hybrid cloud, on-premises, edge, and IoT.
With more freedom of choice, you require more servers management knowledge. It’s also slightly slower than other options. One of the main disadvantages is its limitations in terms of possible functions to create. For example, a Premium Plan has a limit of 100 functions.
# 4: IBM Cloud Functions/OpenWhisk 🔧
Apache OpenWhisk is an open-source serverless platform that allows you to create functions in containers so you can use multiple deployment options. It supports a wide range of programming languages: Go, Java, NodeJS, .NET, PHP, Python, Ruby, Rust, Scala, Swift, Ballerina. If you want something they don’t cover, you can use Docker SDK and bring something fully custom.
Our headline also includes IBM Cloud Functions since IBM Cloud offers a serverless platform based on Apache OpenWhisk. Most of the information regarding this platform is on IBM’s website so we’d recommend looking for all information there.
IBM offers the biggest number of free monthly invocations — it amounts to 5M (provided that the action memory is 128MB). You also get 400,000K free GB-seconds. After that, they ask for $0.000017 per GB-second. Thus, the price is at the same level as Lambda and Azure Functions.
You can work with each component separately without having to disturb the whole system. Apart from a command line, OpenWhisk also provides a Graphical User Interface, which allows you to manage your product with help of graphic pictures and markers. However, many users report that their GUI isn’t intuitive and the command line requires a lot of technical expertise.
Additionally, the system has some tech limitations: the maximum size of the code is 48MB, the function can’t run more than 5 minutes, and you can’t scale the number of triggers higher than 5,000 per minute.
Serverless infrastructure is really beneficial, however, its advantages thrive under specific circumstances. Firstly, features and functions that you want to outsource using serverless shouldn’t be used frequently and/or constantly since it’ll cost you a fortune.
Moreover, you need to pay attention to the technical limitations that most platforms set. To make sure that these limitations won’t interfere with your workflow, you need to know the approximate metrics of your product. That is, how often each feature gets triggered and how long it takes to complete it (on average, of course).
To sum up, we’d like to say that the industry is really diverse and there are dozens of different ways to enable the server ecosystem. Thus, in case you’ll figure that serverless architecture isn’t something you want for your business, there’s definitely an alternative.
If you need any help with enabling serverless architecture or have some questions about your specific use case, feel free to reach out to us. We would love to help you!