Understanding RADON’s core concepts and assumptions | Usage scenarios

In order to understand the technical and research vision for the RADON framework, in Deliverable D2.1 ‘Initial requirements and baselines’, we presented the primary usage scenario for the toolchain and a few secondary usage scenarios where specific RADON assets and methods may help to execute selected activities.

Primary usage scenario: serverless application development

In this scenario, an independent software vendor (ISV) intends to build a novel high-value software service to be added to its product line. The ISV wants to do so by leveraging a composition of serverless FaaS and backend cloud services. Such a decision normally follows an initial expression of interest by a customer for a simpler FaaS-based prototype, hence a willingness and resources for the ISV to invest in more substantial development are available. The company then needs a suitable toolchain to support the underpinning development and delivery effort for the novel software product, possibly using multiple teams in parallel.

RADON will tackle the above scenario with an integrated toolchain that holistically enables the teamwork to define the high-value software service, covering multiple phases of the production including initial architecture design, coding, testing and continuous delivery.

Secondary RADON usage scenarios

1. Fast prototyping

In this scenario, one may envision the use of a DevOps toolchain to help the rapid prototyping of a demo application based on FaaS. This is not a primary scenario because one may not always want to use an advanced toolchain to create a small prototype. If used in this context, though, RADON would still offer many benefits such as graphical design of the topology, function reuse and debugging, and automated orchestration

2. Monolith decomposition

In this scenario, the ISV owns a legacy monolith that needs to be decomposed into microservices or serverless functions. It seeks for appropriate methods and tools to carry out the refactoring. This is not a primary use case scenario for RADON because FaaS enthusiasts and consultants advocate it to define new services that sit in parallel to existing application, rather than to rework existing logic. However, this is still an important usage scenario for the microservices-based architecture which RADON will support. RADON tools for decomposition, optimization and verification can help to conduct the monolith decomposition.

3. Data-intensive system

In this scenario, a data-intensive system needs to apply atomic data processing, filtering, and transformation across multiple data pipelines. This is not a primary usage scenario since FaaS suffers at the moment a data-goes-to-code anti-pattern and furthermore functions often rely on object stores to read/write data. However, there exist situations where ease of programming, maintenance and decomposition is more important than performance. FaaS can be used in such situations as well. RADON treats data pipelines as first-class citizens and therefore will provide modelling and orchestration abstractions to easily link a complex data workflow with a data processing function via events generated from the data.

To summarize, FaaS spans a rich technology landscape in which RADON will position itself to support the development process of complex high-value software services that start right after the initial decision of business investment. In doing so, it will also define tools and methods applicable to specific classes of applications and business situations that do not fit in this primary usage scenario.

You can read Deliverable D2.1 here.

Photo by freepik.