RabbitGCF: Optimizing your Google Cloud Functions one hop at a time
The Big Three. During World War II, it was the allied powers Great Britain, the United States, and the Soviet Union. In basketball in the early 2000s, it was Tim Duncan, Tony Parker, and Manu Ginobili. In modern cloud architecture, it is Amazon’s Amazon Web Services (AWS), Microsoft’s Azure, and Google’s Google Cloud Platform (GCP). These three tech giants command an incredible 66% market share of all cloud service providers as of Q4 2023 and are consistently growing year after year. As technology advances, so does infrastructure and we are currently in the middle of the age of cloud infrastructure. In 2023, worldwide revenue of cloud services reached an astounding $669.2 billion, a 19.9% increase from 2022.
What is Cloud Architecture and Serverless Functions?
Now, if you’re not well versed in cloud services, you might be asking “what are cloud services and why should I care about it?” Before cloud services were introduced, companies and developers needed to have tons of equipment and components crammed into a room in order to create their network infrastructure and servers so that their applications could run as intended. Although these setups work, they have various downsides:
- Infrastructure equipment takes up a significant amount of space. Server racks are quite bulky and as applications start scaling for more users, more and more equipment will be needed and space will easily become a constraint.
- Server equipment will need frequent maintenance to ensure that everything is running smoothly. This is costly in monetary value and in time especially as infrastructure size increases.
- They lack innate disaster recovery. In the instance that your data center fails, such as in the event of a power outage or a fire, all data stored could be potentially lost and at the very least unavailable for an extended period of time.
Cloud computing can alleviate these issues. In cloud computing, a cloud service provider, such as Amazon, Microsoft, or Google, owns a robust infrastructure and network of equipment that they build and maintain themselves. For a fee related to how much you use their system, they will allow you to access their servers for any tasks or computing you might need. Within their extensive infrastructure are safety measures to ensure availability and backup protection in case any disasters arise and thus limiting any downtime. In essence, it is like being able to hand your stock portfolio to an investment expert to handle all the research and trades on your account for you instead of having to test the Wall Street markets yourself. In many cases, this might be the most reliable and financially sound option.
One such usage of cloud computing is Google’s Cloud Functions. Cloud Functions allows you to deploy pay-as-you-go functions as a service. These Functions are stored in the cloud and do not require servers or containers in order to deploy. You can simply insert your code block and then configure a Cloud Function to execute either from a HTTP request or a trigger. Google handles all the operational infrastructure themselves at a rate dependent on the function getting executed and the configuration settings applied to the Function. Only time in use will be charged since idle time is not factored into the cost. However, when a function is in the idle state and a request is made to execute your Function, there will be a start-up delay as the server needs to be fired up and running before the Function can be run. This delay could be problematic depending on the usage of your application, so you can specify a number of instances that are always in a ready state and will not go idle. Although this avoids any start-up delays, there is the caveat that these instances will not go idle and thus will be charged on a constant basis.
Problems with Serverless Functions
Cloud Functions sound great and all, but there are a few problems with them. The main issue is something prevalent in all cloud computing: unoptimized configuration settings may lead to incurring extra costs. Since you are borrowing servers from the cloud service provider, you need to specify ahead of time what hardware you require from the provider. Borrowing better hardware means that the provider will charge you more for allowing you to use it. In addition, as mentioned earlier you are only charged for when the server you requested is in active use as idle time is not charged. Any minimum instances configured in your settings will be actively charged. If you are not careful with the hardware and minimum instances settings, you will find that the bill from these providers will ramp up quite fast.
Another issue is that it can be hard for developers to compare the effects of changing the configurations of Cloud Functions on the total cost. Developers would have to change the configurations and redeploy their Functions in order to witness the effects on cost. Not only is this a hassle, but it could potentially lead to being more costly as it is a trial and error type procedure and the changes could lead to even more unoptimized Functions.
Introducing RabbitGCF
We developed RabbitGCF as an Open Source Google Cloud Function (GCF) optimization tool for developers to better understand their Functions. It comes with a visualizer that presents the current performance metrics of your Functions in clean, readable graphs. It also comes with a powerful forecast tool that predicts the cost of your Functions based on the historical usage metrics and the configurations of the Functions. This tool allows you to change different configuration settings and watch the costs of your Functions change, allowing you to better understand the ideal settings for your Cloud Functions. The overall goal of RabbitGCF is to help developers save time and costs by streamlining the decision making process for what types of optimizations to deploy for their use case without having to redeploy and incur the cost of manually testing the function.
Current Features:
Functions Page
The Functions page aggregates all of your GCFs created within your Google Cloud Project and presents them in one view. Each function listed will be coupled with corresponding navigation buttons that will take you to either the Metrics page or Forecast page, with the details of that function already pre populated within the fields of the selected page. This added layer of navigation makes traversing the website more seamless and reduces the number of clicks to retrieve the information you want.
GCF Monitoring
The Metrics page allows you to monitor the performance of your specified GCF as set in the focus field. Four graphs are presented on the page that inform the user on the selected GCF’s number of invocations, execution time per invocation, memory usage, and Network Egress over a specified time range. We offer time range options between 1 hour up to 30 days by default but also provide the ability to enter custom time ranges. Additionally, we provide the user the ability to zoom in and out of each graph, providing the visibility to both those invocations and corresponding details that occur within a very limited time range as well as those spanning across longer periods of time for better trend analysis. Through monitoring the performance of your GCFs, RabbitGCF users will be able to identify potential improvement areas in UI/application flow based on the number of function invocations, or more specifically in code dependent on analysis across execution time, memory usage, and network egress.
GCF Cost Forecasting
The Forecast page provides the user the ability to forecast costs of various GCF configurations as the number of invocations scale. The forecasting algorithm will calculate the cost to invoke the selected GCF based on its current execution time and memory usage, using the GCF configurations entered in as parameters on the page, and extrapolate that cost across the number of forecasted invocations set by the user. In doing so, RabbitGCF users can determine the cost impacts of GCF configuration changes without having to deploy such changes and invoking the functions to model the costs. This will save time on testing various configurations and will assist with identifying the optimal configuration combination for the selected GCF based on business and developmental needs.
Feature Pipeline:
Currently, RabbitGCF is in the Alpha stage as there are more features we would like to incorporate into our Open Source developer tool. These are some features we are actively working towards implementing:
Support multiple google cloud projects for 1 user
Currently, RabbitGCF is only set up to monitor GCFs for one Google Cloud Project at a time. In the near future, we will provide users a way to set up integrations with multiple Google Cloud Projects that they have access to. Once set up, users can toggle between different projects and monitor GCFs within each without having to log out and log in with different sets of login credentials and information based on the Google Cloud Project they are accessing.
Additional charting analysis tools
At present, only four graphs are offered as part of our monitoring tool on the Metrics page: invocations, execution time per invocation, memory usage, and network egress. Information on such graphs are limited to those four categories and the only customization users have are time range considerations. As a result, we intend to build in additional charting analysis tools that support additional chart presentation types and data options to further monitor GCF performance in a more comprehensive manner.
Launch via VM
Currently, RabbitGCF requires users to clone the repository and run it locally on their machines. We plan to launch containerized versions of our application within Google’s Compute Engine so that users can directly use the tool without having to host it themselves and avoid downloading packages.
GCF Optimal Configuration Suggestions
Using the current version of the forecasting tool, identifying optimal GCF configurations for your GCF requires running different configuration combinations in the tool to see if the cost impact is within the desired range. In the pipeline, we intend to build a way to recommend configuration combinations that achieve the desired cost at the designated number of invocations.
Works Cited
Marcus Lu Article/Editing: . “The World’s Biggest Cloud Computing Service Providers.” Visual Capitalist, 21 Mar. 2024, www.visualcapitalist.com/worlds-biggest-cloud-computing-service-providers/.
“Worldwide Public Cloud Services Revenues Grew 19.9% Year over Year in 2023, According to IDC Tracker.” IDC, https://www.idc.com/getdoc.jsp?containerId=prUS52343224#:~:text=NEEDHAM%2C%20Mass.%2C%20June%2010,Semiannual%20Public%20Cloud%20Services%20Tracker. Accessed 10 Aug. 2024.
