Sven Finke

"Serverless" is the one hot topic of the past years. "Serverless functions" can be incredibly useful and supported by all major cloud providers. I want to compare this to the beginnings of PHP and how we can do very similar things with low effort and without any super fancy tools.

"Serverless functions" are basically "functions as a service". But what makes this so special? And why did PHP do most of this from it's beginning? I want to show how things worked when I started with PHP >10 years ago and how similar this was to todays "serverless functions". How you can easily create specific endpoints that do one specific thing, without writing a single line of code that handles routing. Even without writing a single line of configuration. "Serverless functions" are something bold and awesome and new and fancy, but they are not es special as they might look on first sight.

The talk is supposed to be entertaining. I don't want to talk people into using "functions as a service" or into not using them. But it might be interesting to know where things came from and that PHP might have inspired this whole development of the past years.

Bugs, corrupt data or performance issues on web applications are often recognized far too late. In the worst case they are reported by the customer, so they probably have already done some serious damage - frustrated the user, made them lose trust or even corrupted their data. Finding these bugs or recognizing them early gets especially hard, if your application makes heavy use of background processes, daemons or cronjobs. They might even throw exceptions that are buried somewhere in the logs, and no one will ever be aware of them, until someone has a look into the log files.

I want to show a way out of this misery and provide different solutions in form of practical examples. These will include different levels of monitoring - from simple text logs on the servers up to a fully monitored application including hardware monitoring, extensive metrics, indexed and searchable logs of the whole environment, performance analysis and alerts if something odd happens. I'll show different examples and give ideas when such a fully monitored solution is a good idea, or when a "light monitoring" is applicable.