--- title: "PaaS vs FaaS: Which one should I choose to run my microservices on? — Armakuni" description: "PaaS vs FaaS: Which one should I choose to run my microservices on?" image: https://uk.armakuni.com/hubfs/Imported_Blog_Media/0*SV3plS2Q1-peelcH-Mar-21-2024-09-17-49-1137-AM.png --- [![Compant Logo](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6671668f339890cbef391d80_Company%20Logo.png)](https://www.armakuni.com/) What We Do ![Dropdown Arrow](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/66726ee2fd05cfd52e783a20_Dropdown%20White%20Arrow.svg) Who We Help [Finance](https://www.armakuni.com/who-we-help/finance/) [Healthcare](https://www.armakuni.com/who-we-help/healthcare/) [Supply Chain](https://www.armakuni.com/who-we-help/supply-chain/) [Telecom](https://www.armakuni.com/who-we-help/telecom/) [Entertainment and Marketing](https://www.armakuni.com/who-we-help/entertainment-and-marketing/) Where We Help [Consulting](https://www.armakuni.com/where-we-help/consulting/) [Accelerated Delivery](https://www.armakuni.com/where-we-help/accelerated-delivery/) [Cloud with AWS](https://www.armakuni.com/where-we-help/cloud-with-aws/) [Gen AI and ML](https://www.armakuni.com/where-we-help/gen-ai-and-ml/) [Data Engineering](https://www.armakuni.com/where-we-help/data-engineering/) [Client Outcomes](https://www.armakuni.com/client-outcomes/) [About](https://www.armakuni.com/about-us/) [The AK Way](https://www.armakuni.com/the-ak-way/) [Insights](https://www.armakuni.com/insights/) [Get In Touch](https://www.armakuni.com/contact-us) Written by Armakuni Jun 29, 2024 # PaaS vs FaaS: Which one should I choose to run my microservices on? ## Table of Content ![66cc264742ee0c42e4436149_DevOpsDays london](https://uk.armakuni.com/hs-fs/hubfs/66cc264742ee0c42e4436149_DevOpsDays%20london.png?width=1400&height=900&name=66cc264742ee0c42e4436149_DevOpsDays%20london.png) We all know that microservices are *distributed processes* that must be *independently releasable, deployable and scalable*. At first glance **Platform-as-a-Service (PaaS)** and **Function-as-a-Service (FaaS)** a.k.a. Serverless seem to be capable of bringing into the world the previous description. Both cloud computing models are also able to support incredibly short [lead time](https://www.agilealliance.org/glossary/lead-time/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'lead*20time))~searchTerm~'~sort~false~sortDirection~'asc~page~1)) during software development which promotes innovation and [continuous experimentation](https://books.google.co.uk/books?id=ivixBQAAQBAJ&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false). However when we delve deeper into their technical details, we soon realise they are not always suitable for the same use cases. #### **PaaS** Platform-as-a-Service is a cloud model where you provide your source code and the **platform will package, release, provision, deploy, run, monitor and scale out/in** your microservices. The best examples I can think of are [Cloud Foundry](https://www.cloudfoundry.org/), [Heroku](https://www.heroku.com/) and [Google App Engine](https://cloud.google.com/appengine). Your app will always have *at least one instance running* on PaaS. This comes in handy where persistent connections are required for implementing push notifications via SSE (Server-Sent-Events), Websockets or[ RSocket](https://github.com/rsocket/rsocket#rsocket-protocol). There are many other benefits as well, for example promptly processing incoming requests, keeping reference data in memory (a.k.a. in-process data cache), implementing [circuit breaker pattern](https://spring.io/projects/spring-cloud-circuitbreaker) for handling partial failures, or leveraging connection pooling for throttling workload and reducing response time. #### **FaaS** Function-as-a-Service implies a computing model where your code will be **packaged by the platform and run on demand as a result of some configurable event** (e.g. HTTP request, message arrival, file upload) for a limited amount of time and may be disposed of anytime afterwards. Here good representatives are[ AWS Lambda](https://aws.amazon.com/lambda/),[ Azure Functions](https://azure.microsoft.com/en-gb/services/functions/) and[ Google Cloud Functions](https://cloud.google.com/functions/). We can assemble our apps out of a multitude of *functions* but each one *needs to be configured and deployed individually*. That’s why FaaS is sometimes called **Nanoservices**. This computing model has some interesting consequences: - As aforementioned, a f*unction* life cycle starts when it is activated for a user request and finishes when it returns. The processing time is usually limited by the platform, for example 15 minutes on AWS as of the time of writing. - FaaS auto scales almost indefinitely and that might be seen as a blessing because it allows us to seamlessly handle workload spikes. On the other hand, a large number of function instances may start putting so much pressure on our architecture until something breaks somewhere and we end up [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) our own backends namely: databases, internal services, or third party APIs. - *Functions* tend to be more granular than *services*, therefore we end up with a larger number of deployment units to coordinate, integrate and manage. The more features we have to implement, the more complex a full-blown FaaS application will be. As Twin Tech Innovations pointed out: > Consider the chart below comparing lines of code between projects implemented using the Serverless framework (Lambda + API Gateway) against a project implemented in pure Node.js. For each non-trivial route (piece of functionality) added to a software system, the number of lines of configuration code needed to maintain the project grows at a steep linear rate when using a serverless architecture. Someone has to maintain all of that… In short, for a short term gain, serverless architectures mortgage the future. ![0*SV3plS2Q1-peelcH](https://uk.armakuni.com/hs-fs/hubfs/Imported%20sitepage%20images/0*SV3plS2Q1-peelcH.png?width=1371&height=778&name=0*SV3plS2Q1-peelcH.png) [*https://twintechinnovations.wordpress.com/author/twintechinnovations*](https://twintechinnovations.wordpress.com/author/twintechinnovations)   - There will be no *function *running if there are no user requests to process. This property is famously known as **scale-to-zero **and it’s the hallmark of FaaS computing. It allows for savings in infrastructure costs when the workload is low. - On the flip side, the costs of running *functions* might be more expensive under steady workloads. The graphics below compare the prices of AWS Lambdas vs EC2 VMs per workload. ![0*pYDhY3mb-MObhDUu](https://uk.armakuni.com/hs-fs/hubfs/Imported%20sitepage%20images/0*pYDhY3mb-MObhDUu.png?width=800&height=1200&name=0*pYDhY3mb-MObhDUu.png) [*https://www.bbva.com/en/economics-of-serverless/*](https://www.bbva.com/en/economics-of-serverless/) ***N.B.**** Please note the above graphics compare Lambdas with heavyweight VMs, not PaaS which have been using containers long before Kubernetes came into existence. Taking Cloud Foundry as reference, I have seen customers running 20+ different microservices per VM in highly regulated and very stringent production environments. That means the previous breakeven would happen at 5 requests per second on average for platforms underpinned by m4.4xlarge VMs.* #### **Developer experience** I have been witnessing colleagues advocating for and some companies moving wholesale into FaaS as a means to avoid the painful process of building and maintaining a large number of container images as well as orchestrating them across various environments. I couldn’t agree more with the much needed idea of abstracting away from developers the burden of managing infrastructure. However we have seen that both PaaS and FaaS are able to handle the [undifferentiated heavy lifting](https://aws.amazon.com/blogs/aws/we_build_muck_s/) on behalf of developers, including packaging, deploying, and auto scaling applications as well as managing security, routing and log aggregation. **There is no need to adopt FaaS just to avoid the complexity caused by running containers at scale.** If your goal is to solely improve developer experience, you might well find that PaaS fits your needs with lower complexity and in a less intrusive way when compared to FaaS. I believe that this idea is behind the growing adoption of the [Digital Platform model](https://www.infoq.com/articles/kubernetes-successful-adoption-foundation/). > A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination. #### **Wrapping up** Now that the hype on Serverless seems to be winding down (one can check [here](https://www.infoq.com/articles/serverless-stalled/)and [here](https://www.jeremydaly.com/the-unfulfilled-potential-of-serverless/)), I reckon that each model has its pros and cons and both are here to stay. As always there seems to be no one-size-fits-all solution to the challenges faced when moving our workloads to the cloud. A hybrid approach might help us to reap the best outcomes. My stance is currently as follows: - Both cloud computing models are useful for different scenarios - I find PaaS and FaaS offer far better developer experience than Kubernetes - I don’t think FaaS is a replacement for PaaS - I don’t think PaaS is obsolete; I actually see the Digital Platforms trend as a revisit to PaaS, but focusing on building rather than buying I would advise to take in consideration your own requirements and circumstances before jumping on some bandwagon, whatever it is, perhaps even **making some experiments** which is one of the greatest benefits offered by these both cloud computing models. ## Got Questions? Reach out, and we’ll have answers for you pronto. No items found. ### View all insights [![DevOpsDays 2024: The Next Level Pipelines Delivering Net Zero](https://uk.armakuni.com/hubfs/66f3efbcf44be373c8b19500_Insights%20and%20Innovations%20from%20the%20World%20.png) DevOpsDays 2024: The Next Level Pipelines Delivering Net Zero Discover how Armakuni and RES are driving the future of renewable energy through advanced DevOps strategies and innovative team setups for a sustainable, Net Zero future. Sep 29, 2024 ![Arrow](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6673ad82fd0af1bda76bdc60_arrow-up-right-small.svg)](https://uk.armakuni.com/armakuni-blog/devopsdays-2024-the-next-level-pipelines-delivering-net-zero) [![Better together: Simform's Acquisition of Armakuni Boosts GenAI Capabilities for EMEA Enterprises](https://uk.armakuni.com/hubfs/blogAK.svg) Better together: Simform's Acquisition of Armakuni Boosts GenAI Capabilities for EMEA Enterprises Discover how Simform's strategic acquisition of Armakuni enhances Gen AI capabilities for EMEA enterprises, driving innovation and transformation in the digital landscape. Explore more here. Jul 09, 2024 ![Arrow](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6673ad82fd0af1bda76bdc60_arrow-up-right-small.svg)](https://uk.armakuni.com/armakuni-blog/simform-acquisition) [![Relative Meeting Cost](https://uk.armakuni.com/hubfs/Imported_Blog_Media/1*Kh8glyrhKapB_1rKn61nDg.png) Relative Meeting Cost When arranging meetings, it’s sometimes useful to have a way to quickly gauge the cost of a meeting. A rule of thumb is more useful than an exact measurement as it enables us to calculate on the fly. Jun 29, 2024 ![Arrow](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6673ad82fd0af1bda76bdc60_arrow-up-right-small.svg)](https://uk.armakuni.com/armakuni-blog/relative-meeting-cost) [See all insights](https://uk.armakuni.com/armakuni-blog) [![Company Logo](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672a290df1c1d0cde1f57b9_Footer%20Logo.png)](https://www.armakuni.com/) [![Location](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672a42646d304b62cab21da_Location%20icon.svg) London 124 City Road London, EC1V 2NX](https://maps.app.goo.gl/H3ZD91goeQ7abbm69) [![Location](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672a42646d304b62cab21da_Location%20icon.svg) North America 2880 Cypress Grove Ct. Saint Cloud, FL 34772](https://maps.app.goo.gl/H3ZD91goeQ7abbm69) ##### Company - [About](https://www.armakuni.com/about-us) - [The AK Way](https://www.armakuni.com/the-ak-way) - [Client Outcomes](https://www.armakuni.com/client-outcomes) - [Insights](https://www.armakuni.com/insights) ##### Who we help [Finance](https://www.armakuni.com/who-we-help/finance) [Healthcare](https://www.armakuni.com/who-we-help/healthcare) [Supply Chain](https://www.armakuni.com/who-we-help/supply-chain) [Telecom](https://www.armakuni.com/who-we-help/telecom) [Entertainment and Marketing](https://www.armakuni.com/who-we-help/entertainment-and-marketing) up ##### Where we help [Consulting](https://www.armakuni.com/where-we-help/consulting) [Accelerated Delivery](https://www.armakuni.com/where-we-help/accelerated-delivery) [Cloud with AWS](https://www.armakuni.com/where-we-help/cloud-with-aws) [Gen AI and ML](https://www.armakuni.com/where-we-help/gen-ai-and-ml) [Data Engineering](https://www.armakuni.com/where-we-help/data-engineering) ##### Support - [Privacy Policy](https://www.armakuni.com/privacy-policy) - [Cookie Policy](https://www.armakuni.com/cookie-policy) - [Carbon Footprint](https://disclosure.positiveplanet.uk/directory/armakuni/) - [Modern Slavery](https://www.armakuni.com/modern-slavery) - [Privacy Notice for Job Applicants](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6735c30d604f09e9d63644d2_privacy_notice_for_job_applicants_1731561598429.pdf) ![Cyber Essentials plus](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672a971e7846b687ec22ad5_Cyber%20Essentials%20Plus.png) ![Great place to work](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672a971ac6be3f025f46543_Great%20Place%20Img.png) ![Crown commercial service supplier](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672a9719ba76f89b64ab2c4_Crown%20Commercial%20Service.png) ![Best Workplace](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672a971491f7c75adddbce2_Workplace.png) Copyright @2025 Armakuni Ltd. [![LinkedIn](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672aaf8e79f3e8fc41ac71e_LinkedIn.svg)](https://www.linkedin.com/company/armakuni/)[![Facebook](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672aaf89e8aef9dc6421969_Facebook.svg)](https://www.facebook.com/armakuni.uk/)[![Twitter](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672aaf86530f8732d39cdb9_Twitter.svg)](https://x.com/armakunihq)[![Instagram](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672aaf8b4c416c7b1cb97f9_Instagram.svg)](https://www.instagram.com/armakunihq/)[![Youtube](https://cdn.prod.website-files.com/66715ca64f9c8cdfe857c1d3/6672aaf8ce70652cf21e5d1c_Youtube.svg)](https://www.youtube.com/channel/UCy51sbIGNuwGsmx5wDQafLg) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Armakuni", "url" : "https://uk.armakuni.com/armakuni-blog/author/armakuni" }, "dateModified" : "2024-06-29T12:50:45.644Z", "datePublished" : "2024-06-29T12:50:45.000Z", "headline" : "PaaS vs FaaS: Which one should I choose to run my microservices on? — Armakuni", "image" : [ "https://uk.armakuni.com/hubfs/Imported_Blog_Media/0*SV3plS2Q1-peelcH-Mar-21-2024-09-17-49-1137-AM.png" ], "mainEntityOfPage" : { "@id" : "https://uk.armakuni.com/armakuni-blog/paas-vs-faas-which-one-should-i-choose-to-run-my-microservices-on", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://uk.armakuni.com/hubfs/2554%20Armakuni%E2%80%93Logo%20(Outline%E2%80%93RGB)%20(3).png" }, "name" : "Armakuni Ltd" } } ```