Software Development News A look at serverless and what’s involved in the monitoring of it.
Serverless computing puts more power in the hands of the developer. Rather than developing an application and sending it off to IT for deployment, developers can deploy a serverless application themselves, without having to wait on IT operations or their fellow developers.
But serverless as a term can be kind of vague. When people refer to serverless, they’re usually referring to functions-as-a-service, explained Ben Sigelman, CEO and co-founder of APM company LightStep. Popular examples of serverless providers include Amazon Lambda, Google Cloud Functions and Microsoft Azure Functions. Functions are an individual piece of code or programming logic.
According to Sigelman, the basic driver for serverless comes from management. Companies are recognizing that if they are to exist and succeed, they have to be built around software. “There’s certainly a lot of evidence for what happens to companies that don’t become digital companies,” Sigelman said. “If you’re going to develop software that involves hundreds of developers, which I think is also going to be necessary if you want to actually win in that sort of digital economy, you cannot have hundreds of developers working on one piece ofsoftware. They have to be split up into smaller pieces. That’s where the desire for microservices and serverless comes from.”
A benefit of serverless is that it allows developers to deploy code separately, which results in faster time-to-market. “The move to serverless is kind of an extreme way of allowing individual developers to deploy their code separately from each other, and the units of deployment are very, very small because a serverless function is almost the smallest possible thing that you could deploy separately,” said Sigelman. The functions are also, by design, stateless. This means that if they’re deployed correctly, they won’t disrupt your database as they’re being deployed, said Sigelman.
Another benefit that comes from developers deploying code separate from one another is that they don’t have to waste time worrying about other developers’ breakages as they’re trying to deploy their software. This is another reason why monoliths are slow to deploy; everyone in the organization needs to have a clean codebase before something can be deployed, Sigelman explained.
But for all the benefits of having code broken up into small functions, this also causes one big problem: it’s hard to get a global view of the system. Looking at the functions on their own doesn’t tell you much about how the whole system is behaving, Sigelman explained.
“You’ve intentionally designed your architecture to allow for individual people to work autonomously and to abstract away the rest of the organization, but then for things like monitoring and security, you do need to have a global picture in order to make sense of what’s happening in production and serverless has actually made that a lot harder… You should begin the transition, not finish the transition, with some kind of monitoring solution that’s able to understand the big picture of how transactions actually behave in your application.”
According to Sigelman, this is why there has been a lot of disruption in the monitoring and security of serverless functions.
According to Sigelman, the use cases for serverless tend to be very diverse, with developers using serverless to achieve a wide range of functionality. For example, serverless can be used to create ETL (Extract, Transform, and Load) applications, which are applications that take in external data for use in their own applications. Another popular use case is building latency sensitive applications, where a user will tap something in their mobile device, which invokes various serverless functions and then returns that information to the user, Sigelman explained.
Since serverless functions are so diverse, their monitoring strategies are also diverse, Sigelman said. “They’re being used for a lot of different things and depending on the application, the monitoring strategies are really quite different.”
Serverless may result in better code
Unlike in traditional monolithic software, where a developer writes code and then hands it off to IT operations,in serverless, developers are responsible for the code after it’s deployed. That means they are the ones doing the monitoring, typically.
That added responsibility on developers tends to result in cleaner code, Sigelman explained. “When developers move to serverless, they have a natural incentive to build things that are reliable,” said Sigelman. This results in higher-quality software, Sigelman explained.
According to Sigelman, this is the mentality that all software developers should have, whether they are writing serverless applications or are working on monolithic software. “I don’t think it’s a good idea, serverless or otherwise, to have complex software written in a way where people who write software aren’t on the hook for its reliability,” Sigelman said.
Differences for monitoring serverless apps
According to Ory Segal, co-founder and CTO of PureSec, there are two different types of monitoring strategies for serverless applications: performance and security.
