Workflow-as-a-service (WaaS) is The last level of integration, positioned on top of the KaaS and IaaS layers, includes all the functionalities offered by the layers underneath it in order to allow users to quickly create operational and secure services without requiring any knowledge of neither the underlying container orchestration mechanism nor its underlying infrastructure. This layer is intended for users, who are not IT professionals but who have good ideas and want to implement them by combining existing services to produce added value. This layer, allow them to focus on developing their individual processing tasks, using whichever technology they are the most familiar with; then to push them through Git repositories which will be managed through a workflow management layer. Thus, users will be able to access all the services on top of this layer (such as access to the EarthSignature database and the other SNAPEARTH services). In addition, they will not have to worry about the large-scale processing, (e.g. to reach national, continental or even global land cover computing areas).
As yet another layer of indirection, WaaS provides a higher level of integration than KaaS or IaaS. The workflow abstraction allows application developers and operators to reason about applications as a series, or graph, of tasks to be executed, rather than an application to be deployed and maintained.
Resource constraints can be specified on individual units of work without having to worry about provisioning, allocation or deallocation of computing resources. Usage of the underlying infrastructure is thus tailored to the exact runtime needs of individual processing jobs or applications, increasing resource utilization efficiency and reducing costs.
Application developers can focus on developing individual processors, or tasks, using whichever technology they are the most familiar with such as any programming language packaged application or simple scripts. Data access can be made assuming data locality on the task’s POSIX-like file system by referring to distant objects via configuration only, leveraging efficient, automatic and cost saving data retrieval offered by the SnapEarth platform.
Workloads or applications requiring the consumption of external data sources or streams of events/data can also benefit from built-in ways to connect their processing tasks to ingoing or outgoing Web API/Web Hooks, event queues, storage watchers or scheduled (CRON-like) planning.
For a higher ease of use, the SnapEarth platform will also provide support for continuous integration and continuous deployment (CI/CD) through capabilities such as automated Git repositories watching (GitOps) so that operators and developers can easily push forward new workflow definitions, and let the SnapEarth platform perform deployment changes, without resorting to direct communication/interaction with their cluster.
You can request a small, medium or large cluster :
- Small cluster stands for : 1 Node, 1 Gateway, 1 Master
- Medium cluster stands for : 3 Nodes, 2 Gateways, 3 Masters
- Large cluster stands for : 6 Nodes, 2 Gateways, 5 Masters
Of course we can scale-up those default clusters if you need more nodes.
Important : EarthSelf is powered by Safescale so creating your own cluster with EarthSelf onto a specific cloud provider would allow you to move on to another cloud provider later on if needed.