Serverless. It’s likely you’ve already come across this term somewhere, but what exactly does it mean? Well, to start, serverless, or serverless computing, doesn’t really mean there aren’t servers involved, because there are, rather it refers to the fact that the responsibility of having to manage, scale, provision, maintain, etc., those resources now belong to cloud providers, such as AWS Lambda, Google Cloud Platform, Microsoft Azure, and others. Serverless computing can be a huge benefit to organizations that don’t have the necessary resources or teams to manage physical resources, like servers/hardware, and all the maintenance and licensing that goes along with that, allowing them to focus on developing their code and applications.
Benefits of a Serverless Model
In serverless architecture, when applications are developed, they are typically composed of many different services. When they are deployed in response to a request, those services are deployed as individual functions, also known as FaaS, or Functions as a Service. Again, the benefit being that the code within your containers or virtual machines is managed by the cloud provider. No more having to worry about maintenance, patching, or scaling. Other benefits to serverless architecture include the following:
Obviously, without the need to have to rent or buy physical servers, it can be more cost-effective for organizations to forego the traditional route of having to manage their physical infrastructure and only pay for the time and memory utilized to run your code/applications.
Like we previously mentioned, most of the responsibility of managing the server resources are put on the cloud provider, including scaling up and down. Developers don’t have to put in additional time to fine-tuning the system, or rely on other teams for support, as it’s done automatically with the cloud provider.
Focus on Application Development
With most of the management, maintenance, and polices pushed to the cloud provider, developers can focus their efforts on perfecting their applications.
Disadvantages of a Serverless Model
There is plenty to like about moving to a serverless architecture, but there can be some disadvantages compared to the traditional, monolithic model. The primary challenge being not able to access the underlying infrastructure metrics. Another factor is that serverless applications are distributed, and sometimes across different cloud platforms, making it difficult to manage in the process. Organizations must decide what they’re willing to part with when moving to a serverless environment. Some other disadvantages of the serverless model including the following:
Due to the nature of the pay-to-play model that serverless provides, there are limits to the resources that can be used and for how long code, requests, and other third-party resources can run. For workloads that require high performance, organizations would be better suited by purchasing their own servers.
When code isn’t in use, the cloud providers typically throttle it all the way down. However, when the time comes for resources to be requested, there can be latency in the time it takes to for that code to start back up. Applications that are running continuously on a dedicated server aren’t as impacted by latency issues.
Security & Privacy
You may think that giving up control of your server resources to a major cloud provider would make it safer, but that’s not necessarily the case. While cloud providers do their part to protect clients from attacks and vulnerabilities, the sheer volume of components and elements that must be protected far outweigh what would be necessary for traditional infrastructure. And
In serverless environments, monitoring can be harder to accomplish, as you lose the visibility and control of the back-end performance metrics of your applications. This can also make it difficult to know exactly how and what you’re being charged for resources to run your applications. And in order to find out where an issue occurred, you may still find yourself digging through hundreds of pages and groups of logs to find it.
Monitoring Serverless Applications
Without having control of the full application stack like you would in a traditional setup, monitoring in serverless environments can be a bit tricky. Not having insight to the server-side metrics, render times, and element-level performance breakdowns can make it difficult to fix issues when they arise. Even with your applications in a serverless environment, there are still elements that you need to monitor in production. You can’t just set it and forget it. You’ll probably be tasked with troubleshooting any unforeseen issues, and obviously, optimizing performance of your application. There are several things to watch out for, and we’ll discuss them below.
Obviously, you’ll want to know when applications or requests fail, as well as what caused them to fail, so errors are a critical factor to monitor. Sometimes, errors happen without anyone knowing. It may take a few days for anyone to notice that a critical step or component in an application is down.
The time it takes between an action and a response is latency. For example, in the case of a web application, it could be the time it takes after a user hits the submission button on form. It’s critical to know the time it takes between a successful and failed request because it’s key to the overall user experience. In serverless environments, when your application isn’t running, it’s throttled down, so no additional resources are being used, and you’re not charged. However, when it’s spun back up, there can be some latency in the time it takes to process the necessary resources. This is known as a cold start. If there are many cold starts, this could impact user experience.
Traffic refers to how much demand is being placed on your system, which depending on the service, is typically HTTP requests per second.
Monitoring Serverless Applications with Dotcom-Monitor
Serverless computing providers, such as AWS Lambda, allow you to deploy your websites, web applications, and APIs from the regions of your choice, however, it’s also necessary to monitor those sites and web-apps from those same regions, so you know that they’re performing as intended.
The solutions within the Dotcom-Monitor platform allow you to set up real browser-based monitoring for your websites, web applications, and APIs. Set up monitors by location, with pre-defined performance thresholds, and uptime alerts, so you know exactly when your applications or sites aren’t performing as expected. Additionally, our Web Application monitoring solution, along with the EveryStep Web Recorder, gives you the ability to script multi-step user transactions, such as a shopping cart process or forms and login pages, and monitor steps for any unexpected errors. The EveryStep Web Recorder easily adds additional monitoring opportunities such as Keyword Validation Monitoring. You can learn how to monitor for keywords on this Wiki article. If there are, you get an immediate alert notification so you can fix the issue before it impacts more users. Check out all the Dotcom-Monitor solutions.
Conclusion: Monitoring Serverless Applications
Time is money. And when you’re paying cloud providers by the millisecond for running your applications, every second counts. Likewise, the experience your users have with your applications can make or break a deal. Ensure your users are getting the best experience they can and make sure to monitor your applications and sites for any unexpected downtime and performance-related issues.