Deciding between different technologies, frameworks or architectures is a big part of developers' and enterprise architects' life. However, the rules of software development are changing, and teams should always think about their architecture or computing environments before coding their business functionalities. 

One of the main discussions which confuses IT professionals recently is the difference between serverless architectures and containerized architectures. We have seen a lot of reference architectures, comparisons, and suggestions over the last five years.

Amazon introduced lambda in 2015, the same year that Kubernetes was released. Both technologies gained a lot of attraction. After a few years of stabilization, they are used by many different organizations and companies who want to move their workloads to the cloud.  

As a result of all these discussions, we all need a clear picture of when or in which conditions we should apply those architectures to our design. Let's briefly investigate the use cases and how we can benefit from both.

A serverless computing model helps teams reduce infrastructure or platform management costs to almost 0. Basically, you give your function code to a cloud computing provider (AWS, Google Cloud, Microsoft Azure) and say, "Please run this function for me whenever there is a request. I accept the way you run it and I don't care about maintaining the infrastructure, operating system, or the application's scalability or availability." Cloud providers put some official limitations to make this happen for all accounts such as execution time limits and memory limits. You don't know where is your function executed or how your function is isolated or how your source code is compiled. You can simply you trust the cloud provider's official specifications depending on your security/compliance policies, and choose whether to accept them or not.

Moreover, the serverless workloads are not only limited to function execution, but it is possible to get a fully managed serverless data storage, authentication mechanism, and many more. So, if you believe your computing needs can fit within the limitations of the serverless services in terms of execution speed, security, and resources for individual operation and cost, there are a lot of possibilities which can speed up your development and business agility.  

But let's assume that you need a lot of computing power, and have complex procedures which are non-manageable and are costly to divide into functions. In this case, containers and orchestration frameworks come into the picture. Another decision point to containerize your computing logic would be to avoid vendor lock-in. Decisions to move containers are not limited to these concerns solely, of course; with containers, you can manage the network communication and define access policies with the help of the container orchestrators. In short, you can apply almost anything which you can imagine in a regular data center by keeping your workload in the cloud.

I believe the most accurate decision would be combining those two different architectures to maximize efficiency and agility. The most critical workloads can still be containerized to avoid vendor lock-in, manage the security policies, or get a strong execution resource pool (CPU, memory, disk). But, it is wise to externalize some third-party integration logic, reporting or content sharing which is not critical for core business functionality to serverless execution environments.