IDG Contributor Network: Who needs monitoring in a serverless world?
Like many, I was at the AWS Re:Invent conference in Las Vegas in December. No surprise—lots going on in the fast-moving world of cloud computing. In particular, the rise of serverless technology left many asking, what monitoring do you really need if it’s all taken care of in the cloud?
A serverless technology primer
Serverless is essentially functions-as-a-service. It allows a development team to upload its application code without worrying a bit about provisioning and patching servers or containers, managing scaling, or redundancy. Pricewise, it’s often a win because you only pay for an actual code execution, not idle servers. It’s a continuation of the evolution we’ve seen in IT over the past decades from bare-metal servers to virtual machines, and then containers.
Amazon was first to the punch with its well-received offering of AWS Lambda in 2014, and Microsoft and Google have followed suit with Azure Functions and Google Cloud Functions in 2016.
Overall this has been well received by the development and devops communities. It’s an abstraction that makes sense, and if Amazon and others can show they can be relied on to handle the messy work of load balancing, provisioning, and high availability, most teams are ready to hand over their money.
So, if serverless is our future, what’s the role of monitoring in this new paradigm?
First, it’s worth acknowledging something we often forget as we move further away from the monolithic service design of applications: As we remove complexity from the services, we add complexity to the system of services. So, if we want to understand how our application is performing, it’s critical that we understand how services are performing, as well as how the system (meaning communication between services) is performing.
The legacy model of monitoring individual servers, checking CPU and memory certainly won’t work. Even if you wanted to, in most cases it isn’t possible to access the actual instance the code is executed on, and the reality is that you have limited recourse if you did discover an issue at that level.
Instead we need to change the way we think about monitoring, and focus on understanding the application performance and dependencies. With this in mind, there are four critical components to monitoring your serverless application successfully.
- Native metrics
- Application instrumentation
- Dependency monitoring
- Unified view
Native metrics
These are the metrics provided by your serverless platform. In the case of AWS Lambda, it means Cloudwatch. This will provide you with a view of details like functions executed, errors reported, and execution time.
Application instrumentation
Some APM vendors have released support for serverless technologies, although it still feels a bit immature, which means you may need to be resourceful for this piece.
Beyond the native metrics provided, to fully understand the performance of our application, we need to measure the number of requests to other services, internal latency, and anything critical to your application health. This will vary per use case, but can be the most valuable piece of the puzzle if done thoughtfully. As always with monitoring, focus on actionable information; instrumenting everything or creating too many metrics simply makes it more difficult to diagnose quickly.
Dependency monitoring
Where are you storing your data? Do you rely on any external services or APIs? If so, they should be part of your monitoring solution. Most likely your functions are still interacting with a database, and that database should be closely monitored, both from the perspective of individual queries as well as from an overall health and performance.
Unified view
This isn’t unique to serverless, but I always remind folks that truly useful monitoring solutions combine all the information you need in a single tool. So, whenever possible, that should be your goal.
Adnan Rahic offers an entertaining account of life in this serverless world:
Making my life less miserable
What if I didn’t need to push code to AWS every time I wanted to test something? All heroes don’t wear capes. Like a knight in shining armor, Serverless Offline comes barging in to save the day! At least now I can test all my code locally before pushing it to AWS. That’s a relief.
So, here’s to embracing the serverless world, and adapting to the new paradigm of monitoring.
This article is published as part of the IDG Contributor Network. Want to Join?
Source: InfoWorld – Cloud Computing
Recent Comments