Developers & Practitioners
Getting the best of both worlds: Serverless and fully managed
When you decide to build an application in the cloud one of the first questions that you have to ask yourself is - will your application be built using serverless or fully managed services in the cloud. Well... let me start by saying that these are very loosely defined terms so there can be services in the cloud that fall in the middle (in between serverless and fully-managed) and some that are both serverless and fully managed at the same time. In this article let me share some of my perspective on serverless vs fully managed.
The general idea with serverless is:
“I code my application or service and I don't care where it run..just make sure my user is able to get to it when they try.”
No visibility into the machines - The machines that are being used to run your applications are shielded from you. They are not available to you to configure. In most cases they are created to service the request and disappear after the request is served. For example: When you run a query on BigQuery you do not know how many machines were used to compute that query and serve the response. Another example is Cloud Run, when you run an app on Cloud Run, a serverless containerization platform, you just write your code and leave the infrastructure and scale to Google Cloud.
No server management - you do not have to manage any servers or scale them. For example: Firestore is a serverless database where you just store the data and don’t have to manage any servers, location or data replication, it’s all handled for you.
Pay for what your application uses - usually per translation or per request or per usage. This can vary a bit depending on the service. For example Cloud Functions are priced according to how long your function runs, how many times it's invoked and how many resources you provision for the function while Vision API is priced based on per image and per feature you apply on the image.
The general idea with fully managed is:
“I care how and where my service runs because I have a specific type of service that needs more control over the underlying resources and… my application/team benefits from the extra controls.”
Visibility and control of machines - You can choose the number of machines that are being used to run your application. For example: When configuring Google Kubernetes Engine you get to create your cluster with specific types and number of nodes, number of pods etc.
Managed & automated - Fully managed means you don't have to set up any machines, the management, patching, backup are mostly all taken care of for you. The additional controls let you decide how you want to scale and handle High Availability (HA) and Disaster recovery (DR) situations with easy to set up configs.
Pay for machine runtime - You pay for however long you run the machines & other resources that your application uses. This means even if your application is receiving no traffic but your machine is running, you are paying for it. For example Compute Engine are priced according to the type of machine, vCPU and memory you use and for how long your machine stays running.
I hope this helps you make an informed decision the next time you choose a service in the cloud. Have additional questions, thoughts or just want to have a discussion with me? Let’s discuss on Twitter @pvergadia or LinkedIn