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.

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:

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.

Database Protection

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.

Security Features

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.

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.

Serverless architectures (infrastructure) from Google Cloud offer you the same concept of function outsourcing, platforms that scale automatically according to different use cases.

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.

As for downsides, Google Cloud Functions only supports JavaScript, Python, and Go languages. Additionally, it doesn’t have such a variety of integrations as Lambda. It’s also a little slower than other vendors: according to this research, the average time to perform a function for Lambda is 117.16ms and 176.80ms for Google Cloud Functions.

# 3: Microsoft Azure 💻

Microsoft Azure Functions supports .NET, JavaScript, Java or Python and is a part of more than 100 Microsoft Azure serverless tools for different aspects of building an app.

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.