SERVERLESS VS CONTAINERS - WHAT TO CHOOSE?

Portability

Containerized applications can be deployed on different OS and hardware - Windows, Linux, MacOS, cloud, on-prem, FPGA.

Less resource consumption

Becasue containers don't need to emulate hardware - theycontainers consume less resources compared to than VMs and other alternatives

The highest control level

Developers can choose what programming language is better to use and how to pack the container. They have control over the ecosystem inside the container and the way the app behaves. Proper container allows to setup the main dependencies at the beginning and avoid situations like "It works on my machine".

No vendor lock-in

Since containers are portable and independent, you are autonomous from the vendor.

Version control

Environment versioning and image tagging allows developers to rollback to the previous version very quickly and eliminate needs of maintenance mode. At least from infrastructure perspective.

Limitless

Containerized applications may be as complicated as you require. No constraints like timeouts or memory limitations compared to serverless architectures.

Difficulties with management and setting up

Сontainers require deeper skills to be set up and managed. For example, when you add more logic into the application - more containers need to be added which may lead to the slower initial setup and infrastructure can become more difficult to manage.

Code optimization needed

If you want to leverage full power of container architecture additional changes in the application may be needed. Those are always good changes to the code, but you should be aware of them anyway.

Risk of additional technical debt

Incorrect initial setup and use of containers may add more to your technical debt that already exists ( let's be honest ) So it's crucial to make sure that you set up them in the right way from the beginning.

Higher costs as opposed to serverless

When it concerns serverless, you are charged only for the time of the function execution. What concerns containers, you need to pay for server usage even if there are no running computing operations. It is important to mention that we are talking about fine-architected serverless infrastructure. Otherwise the price for serverless can be multiple times higher compared to containers.

No-Ops Autoscaling

The resources are scaled automatically when a sudden increase in traffic is predicted.

Zero administration required

A FaaS vendor assumes the burden of the infrastructure management.

Higher availability

Almost 100% availability can be easily gained because of autoscaling and automated infrastructure management. If an Ops specialist requires some time to handle a problem, a serverless vendor solves it within a few seconds.

Great pricing model

You are charged only for the resources you utilize, i.e. you pay for the time when the function is executing.

Microservices

Microservices-based architecture is the best case to use serverless.

Quicker time-to-market delivery

Submit new features to the consumers faster! Upload the code and the changes are initiated at once through calling API.

Timeouts

Function timeouts cause the failure of some long-running computing operations.

Cold starts

Even though vendors scale your applications automatically - by default functions cannot handle big spikes of load quickly. You need to understand the load of your application and pre-warm the functions to better handle spikes in the application.

Basal time-lag

For some limited number of businesses, any time-lag may be catastrophic. For the wide circle of industries, even millisecond time-lag is hardly noticed.

Time- and energy-consuming transition

Migration to the serverless architecture may occur to be costly and resources-consuming since it requires many significant changes not only in the code and IT infrastructure but in cultural aspects.

Difficulties with monitoring and debugging

The app is broken down into pieces and each piece has its own bugs and issues. Sometimes it's challenging to gather everything under control and see the whole picture.

Vendor-dependency

Once you have chosen a FaaS provider, you get "lock-in" and it becomes a headache to use third-party services.

User's role

A user takes under control the whole process of container initiation.

The process is hidden from the user.

Management

Needs an Infrastructure engineer to manage and update a container.

A serverless vendor takes over the responsibility for infrastructure management.

Testability

Easy to test because containers are run on the same platform where they are deployed.

Difficult to test because of challenges with the backend environment replication on the local environment.

Timeouts

Continuous working until the container finishes the required event or is simply destroyed.

Max 15 min (900 sec) can be set. It is required for application to be able to work with timeouts or handle chunks of data instead of all-in-once.

Payment peculiarities

Needs a running server to stay available.

Pay for the function execution time.

Programming languages

Any. Containers allow heterogeneous development.

A vendor specifies the supported programming languages. Usually, the vendor supports Node.js, Python, Java, C#, Go (AWS Lambda).

Time-to-market

Takes a bit more time to get set up and developed, but once the container is configured, it takes a few secs to deploy.

Easy to deploy within milliseconds because there is no bundle with the system dependencies.

Heavy data processing

Allows to run long-lasting data processing jobs, there are no limits on resources by default.

If it takes more time to process a heavy resource, a serverless function must support beaking request down into smaller units.