Gurpreet Singh

Hi Chris,

Your viewpoint regarding the ping to the function in the morning for new users is a good idea. In fact, AWS does provide a similar service via CloudWatch Events. You can schedule the time to wake up the function in the morning. Even Lambda itself provide an option to schedule the trigger using schedule expression or cron. This will save some money as well.

I also believe that serverless has endless potential. AWS has already come up with serverless Aurora DB. Many other AWS services are also following the serverless principle. Opensource serverless platforms can be extended to any level.

Hi Christophe, Thanks for giving your viewpoint. I agree that serverless is not only meant for Batch/Background jobs. My point was that it makes more sense for this kind of services. Serverless can be used for API's and that is a good practice which is currently being used by many developers. Even AWS API gateway supports serverless API's at its best. Moreover, AWS lambda functions have an option to wait for 45 minutes to 60 minutes before auto-termination. If a website does not receive a traffic for those 45-60 minutes then you will be billed for those minutes without any use. Best would be to use S3 for static website hosting. For Dynamic websites, there are many other solutions based on similar concepts. And if we will just ping the container every 5 minutes to keep it live then what is the fun of having serverless functions.

Moreover, AWS Lambda functions can run up to 15 minutes per execution. Earlier, the maximum execution time was 5 minutes. So now performing big data analysis, bulk data transformation, batch event processing, and statistical computations does make more sense using Lambda.

Azure functions have an option to run for 10 minutes. Google functions can run for 9 minutes at max for now.

PS: I have changed the cannot to should not to avoid any confusion over my statement.

You are right in saying the scaling advantage of Microservices and sprawls as a disadvantage. Security and Latency are dependent on the architecture. Security can be an issue in every kind of deployment be it Micro, Mono or Modu (Interesting name btw), If not handled well. Running Microservices on a single host won't make any sense if you need to scale or the host goes down. In distributed, cloud-based microservices troubleshooting may be a problem initially but once the processes are in place, any kind of issue can be easier to troubleshoot. For example, If in your application Microservice of registering new users goes down then the complete application won't stall, users would be able to login to the application. If we talk about any website like Dzone or Medium, If users are not able to comment (If the Microservice is down) then it won't stop users to browse through the articles. In distributed microservices, you can define the underlying infrastructure as per the requirement of the particular Microservice eg. Loading comments may need more CPU (DB stuff you know) then login to the website. Of-course latency would be a great advantage of modulith, but running the complete system on a single host does not make it different than the monolith.