UK Smalltalk User Group Meeting - Monday, October 30th - PharoLambda: Smalltalk running serverless on AWS

Tim Mackinnon wrote
> Tim Mackinnon will show…

So jealous! That sounds like an awesome presentation :)



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Thanks Sean - hoping to do a bit of deeper dive into the Screencast I posted a while back - but I’m also hoping we can get some discussion around the kinds of things we can do with serverless that match the strengths of Smalltalk.

I’ve got a few ideas - but wondering what others think - and we’ll share the results here.

Tim

NOTE for anyone that is coming and is reading this: We’ve had to change the venue to the pub around the corner - The Crown Tavern.

I promised to give a little summary of the meetup.

After some initial “smalltalk” (in the talking sense - where we covered chrome books, cloud development, squeakjs and how you might develop in smalltalk on a Chromebook in a web world…. I did say smalltalk right)….

I did a quick intro to the components of writing a traditional Alexa Skill and Lambda functions on AWS using Node JS… this wasn’t Smalltalk related but it set the context of what the environment is like and was quite interesting to the group to give some some background.

We had some interesting side conversations on the social aspects of having a device like an Echo Dot in your living room (is it like the revolution we’ve had with phones? Does it feel natural etc). Some interesting debate on this.

Then we covered how the recent’ish advancement with an OpenSmalltalk 64bit vm have given the ability to easily run Smalltalk no Lambda where you don’t have a lot of control on what is installed on your target instance (essentially you upload a zip file of your environment)

We then walked through the GitLab CI/build system I used to automatically create a zip file to upload (the minimal image work done here was the power behind this - and GitLab ci is quite a nice build system that is fast/efficient and simple to use).

Then the real eye-opener was looking at the small amount of code needed to create a service (not so amazing actually) - but the kicker being the implications of how you can easily debug a failed service. This got the conversation flowing.

The 2 interesting points that came out:

- restarting a failed service (and being able to keep restarting it in a debugger) is neat - but services often have other elements like a database or other service that also need rewinding. Given the tiny amount of code that I showed that serialises the context to S3 (again, sponsored by this community - thanks) its not unimaginable to snapshot a database and be able to restore it when you dematerialise your execution context (and also do it again if you decide to restart again). These are things developers in other communities don’t even dream of doing it seems. (As a side point - how hard would it be for our debugger to truly let you rewind memory when you step back in the stack?)

-  AWS feels like a new operating system. And just like we handle restoring windows and other resources on an OS like windows - should we be viewing AWS as a similar thing we should run on (albeit in a slightly different way). But can our tooling/environment make for a more pleasant and cohesive view on top of a cloud OS? It feels like it could somehow.

- Another side point - I recall early demos of IBM distributed smalltalk where you could literally highlight nodes of execution that were slow because they were far apart and just drag them near to each other so that message calls didn’t have the same network latency. This feels like the new cloud world might benefit from some of these old ideas… not sure if there are any video of this in action to inspire people.

Anyway - not sure if any of this is useful to anyone reading, but it may be a reminder to me of things to follow up on.

Tim