The idea is to separate your App into front-end tasks from back-end tasks: Your front-end tasks are customer facing so they need to be executed quickly. Hence move everything which can take long to the back-end. There, tasks can take much longer without being annoying. The most common approaches are utilizing queues and scheduling execution times. The Worker is an optional Component for your Apps to achieve exactly that.
Read all about how to leverage the Worker Component in our help.
Differences to Old Workers
We have first introduced Workers in August 2013. Now — with all the learnings — we are releasing a redesigned solution. Most notable is that there is a new, smaller and much more affordable entry level plan — which was a hugely requested. This opens the range of use cases for smaller applications. Apart from that, there is a price drop of 15% - 30% across all plans. And last not least: the New Workers are easier to understand and work with.
The New Worker is now available for all New Apps, the Old Worker stays available for Old Apps. If you are already familiar with the Old Workers, here is what you should know:
- runs on a dedicated SSH Node (full Linux instance)
- managed via
scheduler.ymlfile & remote SSH
- plans vary in different RAM sizes and CPU power
- log access via SSH file + tail (10 seconds delay)
- runs in a container (different visualization layer)
- managed via Dashboard & SSH CLI
- plans vary in dedicated RAM sizes and number of active Jobs
- live log access via SSH CLI command
Pricing changes in detail
|Old plan||Old specs||Old price||New plan||New specs||New price|
|—||—||—||Worker s||128 MB, 1 job||5 €|
|Workers xs||400 MB, micro CPU||17 €||Worker m||512 MB, 4 jobs||15 €|
|Workers s||1.5 GB, small CPU||35 €||Worker l||1 GB, 8 jobs||30 €|
|Workers m||3.5 GB, medium CPU||80 €||Worker xl||2 GB, 16 jobs||60 €|
|Workers l||3.5 GB, high freq CPU||140 €||—||—||—|
Now, these pricing specs might look mostly same at first glance. But please be assured that the New Workers are much faster. They run on the CPUs which are two generations ahead and are backed with SSDs. Also note that the RAM for the New Workers is fully available reserved for the tasks to run, while the Old Workers shared the memory with the Linux system. The old "Worker xs" was considered for development only. The new "Worker s" advertised to use in production (and we tested that).
We do not offer high availability options for Workers at this time. Apps should be resilient and not rely on the availability of a Worker anyways.
Old > New migration time-line
When is best time to move from Old App to New App? Well, now is good — but you still don't have to. It depends on your needs: should your App rely on Workers it just got way more attractive.
We are currently working on the last mile stone to make the New Apps feature complete: The "asset storage", a way to work with files generated by your App.
As soon as this feature is released, we will actively push the move towards New Apps. The plan is still to migrate all Apps by mid 2016, but it will take as long as it will take. We will listen to your feedback and will help you as much as we can.
Thanks so much for your interest and your trust in is so far. What do you think of this release? Do you have any other ideas? Your feedback helps us heading in the right direction.
The worker photo above makes use of this image by Kheel Center.