Serverless architectures have enormous advantages for companies – given the right application. However, the model is not suitable for every app, for example when the project becomes complex and expensive.
The biggest benefit of the cloud-native development model, known as serverless, is its initial ease of use. Companies do not have to provide staff for the often tedious administration of server infrastructures, the respective cloud provider takes care of that. Other complex routine tasks such as provisioning and scaling are no longer the responsibility of internal IT departments.
For the provision of functions of an application, it is sufficient if the developers pack the corresponding code in containers and make it available via the cloud. After deployment, the respective functions are only executed as required and consequently only then incur costs. However, if the demand is particularly high, the purely cloud-based serverless model can quickly become expensive. It is particularly good for functions and services that are rarely used.
All beginnings are easy
Serverless architectures enable application developers to initially implement scalable, flexible and efficient functions and services in business applications at low cost. However, a risk remains, because even if the entry into the world of serverless is quite easy, the complexity increases very quickly when developers want to use more sophisticated resources, such as API gateways that sit between the client and several backend services and the calls manage.
The more the respective company builds on serverless architectures, the greater the danger of a vendor lock-in. Decision makers should keep this in mind if they want to define a serverless strategy that allows them to avoid long-term vendor and security risks. If there is a corresponding awareness in the company, it can use the advantages of serverless without having to fear potential pitfalls.
Please confirm your email address!
Click on the link in the email we just sent you. Also check your spam folder and whitelist us.
More information about the newsletter.
Serverless has to fit the application
A serverless architecture is not the right choice for all cases. If the designated “serverless” application requires significant scaling and generates very high traffic for long periods of time, it can become very expensive. In this case, a cheaper alternative is a compute cloud such as Amazon EC2, which provides computing capacity in the cloud. Serverless scenarios are also rather unsuitable for applications that require very short response times, such as real-time applications.
Decision-makers should therefore only decide on a potential switch to serverless on the basis of a detailed cost-benefit analysis. Unfortunately, tech teams all too often initiate serverless projects because they have succumbed to the shiny object syndrome, meaning they jump on trends and then drop them again as soon as a new technology hits the headlines. However, the risks and consequences of implementing serverless are severe unless the benefits have been demonstrated for a specific use case and the organization has properly considered the ultimate costs and outcomes.
Serverless architectures save companies time and money – provided the paradigm fits the concept of the business application.
The mindset of the developers must also match the special requirements of serverless. For example, it is imperative that they have an in-depth understanding of how serverless and event-driven architectures are built. Developers must also know the specifications and limitations of the platform used (e.g. AWS or Google Cloud) and, above all, keep an eye on application and data security. The learning curve of serverless is very steep, which is why the tech teams in particular – not just management – need to be sure that it is the right choice for the business application. And of course before the company invests in this technology.
Source of danger Vendor lock-in
Unfortunately, serverless architectures are often associated with a vendor lock-in, because serverless code is usually specially tailored to the platform. It can therefore be very time-consuming later on to port the functions and services of a business application to another platform. Often developers have to rewrite the entire application when changing platforms.
One way to circumvent this expensive and labor intensive circumstance is to use open source frameworks such as Apache OpenWhisk or Fission. However, since they are relatively new solutions, developers may have to put a lot of work into setting up and deploying the serverless framework. In any case, it is easier if companies use managed cloud service providers who support open-source serverless frameworks.
Security is also personal responsibility
A potentially big risk is the dangerous assumption that the cloud provider is entirely responsible for the security of the serverless application. Of course, in such a scenario, the platform provider is responsible for the security of the server, the operating system, the platform itself and the infrastructure layer. However, the responsibility for the code of the application and its security lies with the developing company. The internal IT department must ensure that they write the application code using secure programming practices and that they secure all data used. If the switch to serverless is in the air, it is up to those responsible in the company to train their teams intensively with regard to this responsibility of the new paradigm.
Organizations that choose serverless could also face a significantly increased number of threat areas and greater security risks. A few “blind spots” in the security strategy often show up. As application code gets smaller and runs autonomously, developers find it increasingly difficult to implement access controls. As a result, the security of data during transmission and at rest, as well as when exchanging information with third-party functions, libraries and plug-ins, is also endangered by ever smaller code bases.
Furthermore, due to their event-driven nature, serverless applications are the perfect target for a modified version of denial-of-service attacks: instead of denying users service, these attacks lead to an unnecessary scaling of the resource requirements on the serverless platform. It then becomes expensive for the operator of the application because they have to pay for the resources.
While the risks of implementing a serverless architecture are significant and must be addressed head-on. But in many cases, the potential benefits outweigh the potential problems. A careful and intentional approach to serverless adoption, with a focus on avoiding vendor lock-ins and reducing risk, is essential. By choosing the right tools and partners, organizations can embrace serverless modernization initiatives implement confidence.