How serverless architectures change development process and project business

This blogpost gives a short impression of serverless architectures and serverless computing, what these terms stand for, and which benefits and drawbacks they involve. You will get some information about the impact on the development process and the business model, which is required to determine if the serverless model is suitable for your current or future projects.

The serverless computing paradigm came up in the past years as a disruptive architectural approach for creating modern applications, services and backend solutions. Serverless applications allow developers to focus on their application code without worrying about provisioning, configuring, managing and scaling the backend infrastructure. This speeds up development and release processes and reduces the complexity of creating scalable and reliable applications.

These benefits have a huge impact on the profitability of smaller applications, minimum viable products (MVPs), and even productive legacy systems. Serverless computing has the potential to provide significant cost savings and efficiency increase.

So what does serverless mean?

Serverless is a cloud computing execution model, where the cloud provider dynamically manages the provisioning, administration and scaling of application servers and backend infrastructure. There are two different types of serverless computing that can be distinguished.

1. The first type refers to web or mobile applications that leverage cloud services to manage the server-side logic and state. These services are generally known as Backend-as-a-Service (BaaS).
   
   Applications can use a wide range of cloud native services like databases, storage, messaging or authentication services, which are provided by the cloud provider via SDKs and APIs. Developers can link to these services in a consistent way to manage backend data. They do not need to create their own backend for each of the services that their apps need to access. This allows the application developer to focus on the frontend development.
   
   
2. The second type of serverless computing is Function-as-a-Service (FaaS). FaaS is the next evolution of cloud computing services, where the handling of backend infrastructure like containers, runtime environments and application servers is abstracted.
   
   The server-side logic remains the developer’s responsibility, but runs in stateless, ephemeral compute containers, which are triggered by various kinds of events. The business logic can be implemented in different programming languages and is executed as independent functions.
   
   Applications are separated into individual functions, that can be invoked, scaled and executed independently of each other. The execution of functions is entirely managed by the cloud provider. This reduces the technical complexity in developing, deploying and maintaining an application and increases productivity and agility of the whole development process.
   
   

Serverless is currently the highest abstraction of cloud computing and the evolution of Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) solutions.

IaaS allows you to reserve computing resources and infrastructure, such as CPU, storage, and network, based on virtual machines or containers. With these resources, you can provide and manage your operating system, runtime and application software.

PaaS manages the operating system and runtime components for you and provides a complete development and deployment environment in the cloud. You can run existing containerized applications or provide application code to run web service or worker applications, based on the managed software stack.

With the serverless model, you only provide the implementation of individual function code without the complexity of having to manage infrastructure, resources or scalability. Functions are triggered in an event-driven architecture and provide separated and individual functionality within your application.

There are some characteristics which can be used to describe the serverless terminology.

“Run code, not servers”

There is no need to manage physical servers, virtual machines, or containers. They are fully provisioned and managed by the cloud provider and hidden from the developer or operator.

Developers don’t have to think about infrastructure capacity, operating systems, provisioning, security patching, configuration, scaling, concurrency, and load balancing. They can fully concentrate on application features, usability, and design.

Pay as you grow

The cost model of serverless applications is execution-based. You pay for the resources you consume as opposed to provisioned capacity. This means that you will never pay for idle computation time. Since capacity is scaled automatically per demand, your costs will increase or decrease based on the usage of your application.

Availability and scalability

The cloud provider is responsible for availability and fault tolerance of the serverless services. You don’t need to architect for these capabilities since the services running the application provide them by default.

Serverless services and applications have autoscaling built in. One of the biggest advantages of serverless is its extreme elasticity. Its immediate and seamless provisioning of compute capacity for functions means you can scale your application in seconds to handle sudden bursts of traffic.

The underlying system will automatically handle things like load balancing and the provisioning of appropriate infrastructure capacity, based on the current demand. There is no need to estimate any capacity requirements of the application, which would typically lead to over- or under-provisioning.

What is the impact on development processes and project business?

One key aspect of serverless computing, which influences the development and business of a product, is the fact that the huge burden of providing, configuring, managing and scaling the backend infrastructure is fully managed by the cloud provider.

A fully serverless solution requires zero system administration. This means that there are less DevOps engineers required in the project to provide a highly available, performant and reliable backend system.

Removing the heavy lifting in the management of the underlying infrastructure lets the team move faster and removes the time-consuming coordination needed to provide a stable and production-ready infrastructure.

This means less organizational communication overhead and more time for innovation.

Human cost of infrastructure

Providing and managing the infrastructure on your own might appear cheaper if you look at plain operation costs compared to using managed services. However, you always need to consider the Total Cost of Ownership (TCO) of your infrastructure, which are incurred during the lifetime.

Your DevOps engineers need plenty of time to configure, automate, test, and deploy the services on a production-ready basis. How many engineering hours does this require, and how much do they cost?

When the system is deployed, you’ll have ongoing security and maintenance responsibilities. You are responsible for the functionality and stability of your services. All scripts and configuration files must be documented and kept up to date, which can often increase the amount of technical debt.

All these factors increase the TCO and needs to be considered in the decision for a technology stack. You can assume that a huge amount of the project budget will have to be spent on infrastructure administration and maintenance.

Wasted server utilization

Server infrastructure, which is rented with fixed capacity is generally over-provisioned to ensure that any traffic spikes wouldn’t exceed the limits and break the application. This decreases server utilization and leads to wasted capacity and idle times.

In the serverless model, however, you will only have to pay for consumed capacity. Thus you can smooth out that utilization, so that operational costs increase or decrease linearly with demand and profit. This increases the productivity and efficiency of your application.

Operational costs are thus proportional to your application usage and (hopefully) profit, which makes it easier to estimate the profitability of your product’s business model.

 

Focus on features

Using managed services allows you to spend more time and resources for higher-value engineering and development tasks, like improving customer-facing features and usability. This provides a lot of opportunities to gain a competitive advantage and to create a better and more innovative product with the given project budget.

Faster time to market

Due to technology abstraction and complexity reduction, large backend systems could be created in less time compared to traditional technologies. This speeds up the development process and usually results in a faster time to market with faster delivery and business growth.

Additionally, you will have the opportunity to continually try new things and rapidly update the existing product with low friction and at minimal cost.

Free tier offerings

AWS offers many serverless services, which have a huge free tier pricing model. AWS Lambda, for example, is charged according to the number of function requests and the duration of code execution. However, you are only going to be charged if you exceed 1 million lambda invocations per month.

The user authentication and identity broker service AWS Cognito has a free tier offering, where you start paying a service fee only if your application has more than 50,000 monthly active users.

The fully-managed NoSQL database AWS DynamoDB includes a permanent free tier of 25 write capacity units and 25 read capacity units, which is enough for many small applications to work with.

Also, the messaging services SNS and SQS have permanent free tier offerings, where you can make 1 million requests each month for free. Some applications might be able to fully operate within this free tier limits.

This pay-as-you-go pricing model makes serverless application the perfect fit for small applications and MVPs. It allows you to start cheap and pay (more) with the growth of your business. These combined benefits give you the required velocity to be able to compete with other products with larger teams and budgets.

To get an impression how much you need to pay to run a serverless API on AWS which handles over 2 million requests per month you can check out this scenario calculation.

As you can see, serverless architectures have a lot of benefits in comparison to the traditional manual provisioning and administration of application server and backend infrastructure. But as always, everything has its downsides, and also serverless architectures comes with significant trade-offs.

Drawbacks of serverless computing

There are some potential drawbacks that might make serverless unsuitable for your business or project. The knowledge of these drawbacks can help you to make the best decision regarding your backend infrastructure.

As with all new technologies, you should carefully evaluate the application requirements and the pros and cons, before aligning with serverless services and architectures.

Loss of control

Many of the limitations of serverless are related to the fact that the platform itself is developed and operated by a third party, which involves the loss of control of the software stack running the application. With serverless, you do not manage the infrastructure. However, this also implies that you lose control over server hardware, runtimes, and configuration.

The available configuration options may be limited or abstracted from how the actual underlying software is configured, which makes it difficult to adjust the system for an optimal operation state. For example, AWS Lambda has a limited number of configuration parameters and has no control over JVM or operating system runtime parameters.

Serverless platforms hide the details of program execution in multiple layers of virtualization, which makes it difficult to predict or optimize the performance of the application. In observations of benchmarking code execution with AWS Lambda, it has been shown that identically configured Lambdas can have different performance characteristics, as the platform automatically adapts scheduling priorities and resource allocations in response to demand.

Vendor lock-in

Running applications in a serverless environment can tightly couple the applications and services to your platform provider. Many of the serverless offerings are proprietary with unique features that simply cannot be ported to another cloud provider or on-premise systems. With API and protocol differences between serverless platform providers, any potential shift of the applications to other providers can cause a significant rewrite.

Operational costs can overflow on massive scale

Operational costs with serverless architectures for low and medium workloads are usually lower compared to using EC2 instances. They can even be free, if they fit in a monthly free tier.

However, there are certain workloads that require extensive compute resources, which makes the serverless model less cost-effective, especially on a higher scale.

The costs of a serverless application are hard to predict, due to it’s event-driven architecture and on-demand pricing model. There are many pricing pitfalls, which should be considered to get a realistic view on you costs.

Understanding the true costs is complex.

You should understand your compute workload very well and consider the costs of all services used in your serverless applications and how they increase on scale. When your backend reaches a massive scale, the cost-per-invocation model of Lambda, API Gateway, CloudWatch, and other serverless services, as well as the data transfer can become expensive.

Try to estimate the operational costs of your application for an optimistic production scale. If the costs are substantially higher, you might want to run your application in a container or on virtual machines.

Cold start

One of the most common performance issues in conjunction with FaaS is known as cold start. This refers to the instantiation of the function container executing the code, as well as some initialization of the code itself.

These slower cold starts occur when Lambda functions are invoked for the first time or after having its configuration adjusted. The latency depends on many variables like the programming language, the amount of included libraries, code size, environment configuration, or whether you need to connect to Amazon Virtual Private Cloud (VPC) resources.

The cold start leads to certain delays, especially if many functions are chained as part of a step function to create a complex workflow. Additionally, you have to consider that Lambda functions, which are integrated within a VPC, introduces huge latencies, due to network interface provisioning and IP address assignment.

This could increase the cold start duration by a factor of 10. You can attempt to minimize the cold start time by sending scheduled ping events to your functions to keep them “warm” in an initialized state. Additionally, you should implement your functions with minimum logic and dependencies, as cold starts increase with code size and memory.

Development, debugging and testing

Serverless applications are often based on an event-driven architecture (EDA). While designing serverless-based solutions that go beyond simple use cases, the architecture is more complex and the execution flow is harder to reproduce.

While a serverless architecture simplifies many things for the developer, the platform abstraction requires you to re-think the way in which you build applications.

EDA-based programming is not intuitive and generally harder to monitor and debug. With distributed applications, you need to rely much more on log traces to reverse-engineer the root cause of an issue. The classic runtime debugger that allows introspection and line-by-line stepping is currently not possible for many serverless services.

Debugging is generally more complicated, because developers cannot look into backend processes and the application is broken up into separate, smaller functions. With no control on the underlying server, you have to rely on the built-in logging and monitoring capabilities of your provider. Services like AWS X-Ray, however, are starting to enable distributed tracing and latency debugging of messages across serverless components.

Local integration testing of Lambda functions can be done with various tools, like AWS SAM. The local environment, however, can hardly fully simulate the remote cloud environment.

Testing a complex serverless application against a remote system is challenging, because it is difficult to replicate the serverless environment in order to see how code will actually perform once deployed. You also need to ensure that testing does not impact production resources and that account-wide platform limits are not exceeded.

Conclusion

Serverless is the next abstraction level in the evolution of cloud service technology. With serverless architectures, we can focus on innovating applications and solutions, rather than spending a lot of time on setting up and maintaining infrastructure.

This can decrease time to market, system complexity, and operational costs. The advantages are obvious: demand-based resource consumption and automatic scaling make it possible to cope with sudden load peaks or unexpected growth scenarios. Provisioning takes place in seconds instead of hours or days. And all that at reasonable costs, thanks to the pay-per-use payment model.

With all these benefits, serverless becomes more than an architecture choice, it becomes an important strategy. However, the promising arguments in favor of serverless infrastructures also introduce new challenges, which always needs to be considered.

The stateless and event-driven nature of serverless architectures involves different procedures and concepts when implementing requirements and solving issues. Developers need to have a clear understanding of that pattern, need to know the best practices and should be aware of all supporting tools and upcoming new features and technologies.

A technically meaningful treatment of exceptional situations and errors as well as the creation of an automatic test concept are further important parts in that scenario.

What experiences have you had with serverless architectures?

Leave me a comment!