There are plenty ways to deploy Smalltalk application online: Amazon cloud, Digital Ocean, virtual machines, dedicated servers and more. The deployment process for Smalltalk applications in this environments is basically same to the deployment process for any other application: configure Linux virtual machine to launch an executable with specified settings.
We believe that Smalltalk deserves more. Standard approaches of deployment ignore Smalltalk features and make the process far more complicated than it should be. As Smalltalk Image contains the whole environment (starting from system level functions up to web servers) we see that it is the only thing you should provide to the hosting to be able to run it.
Ephemeric cloud primary concept is Smalltalk Image as the main system unit. Developer works not with virtual machines but with Smalltalk Images deployed in the cloud. Hence to launch a new application only the Image is required to be uploaded to the cloud – let the system cares about all the other stuff.
Basically, Ephemeric cloud is a developer’s publishing tool for Smalltalk applications. However, the cloud might work both as a platform for ready application and as a part of development and testing process.
Moreover there is another system feature – it works through application programming interface: a standard HTTP REST API or a special library Pharo Ephemeric Cloud API. This allows to integrate the Ephemeric cloud with any part of your application and/or script. For instance, developer can add a button “RUN” to a web-site of his application and automatically publish a copy of his application on the cloud to his client. Ephemeric cloud can also be used as another step of continuous integration in auto-build and test systems or as a public server for build artifacts outputs. All told, due to the cloud application programming interface there are quite a few options to use it.
As for technical point of view Ephemeric cloud is developed according to so-known “Just in time cloud” concept. It means that the applications running in the cloud are stopped after some non-active time and respectively require no resources. On the next access attempt the application launches again, thus it looks like the application works permanently. Sounds great, right? Though such a concept has some restrictions on the applications to be run in the cloud.
First, the applications must be quit-tolerant which means the application should handle well sudden shutdown after some downtime and run appropriately after restart.
Second, to ensure images stable start and restart in the system, we made published images to be read-only in the cloud. This means it is impossible to “save” your image in the cloud and thus use Image persistence for your data. Theoretically, Image “update” is only possible in a way of publishing of a new image with amended data and removal of a previous image (see also “ "content-addressable storage” for more information on why it is done this way). However, it does not mean it is impossible to connect to any external systems available for data persistence, such as external databases and/or network drive: you are able to connect to any service provider using a configurable secure channel even through public networks.
Finally, the cloud is created for web-applications hosting and micro-services first, thus “activity” in our understanding means incoming http-requests. This being said, the cloud expects enabled web-server inside the image on 8080 port. Generally such restrictions should not be a problem for majority of web-applications.
As always, please contact me at firstname.lastname@example.org in case of any questions.