The document presents a comprehensive overview of the Actor Decision Science Platform with a focus on technological aspects such as cloud-native applications and the twelve-factor app methodology. It emphasizes the importance of scalability, multi-threading, and efficient processes for modern software development while also detailing the architecture and user experience considerations. The platform's goal is to enhance data analysis and predictions for companies through high-quality cloud-native solutions.

1. ACTOR DECISION SCIENCE PLATFORM:
A TECHNOLOGICAL POINT VIEW
Carmine Spagnuolo, PhD
ISISLAB, Università degli Studi di Salerno
ACTOR, Computer Science R&D

2. PROBLEM SOLUTION
FIGHT
PROBLEM VS SOLUTION

3. PROBLEM SOLUTION
BIG
DATA

4. PROBLEM SOLUTION
PROBLEM
COMPLEXITY

5. PROBLEM SOLUTION
HARDWARE
LIMITS

6. PROBLEM SOLUTION
ALGORITHMS

7. PROBLEM SOLUTION
MACHINE
LEARNING

8. PROBLEM SOLUTION
OPTIMIZATION

9. PROBLEM SOLUTION
SIMULATION

10. PROBLEM SOLUTION
BETTER
HARDWARE

11. PROBLEM SOLUTION
Moore’s
law

12. Moore’s Law
Stay here We come
back to the fight in few
minutes
Gordon Moore, the co-founder of Intel, predicted the rate of growth
in computing power that became known as Moore’s Law back in
1965.

13. PROBLEM SOLUTION
Parallel computing
Cloud computing

14. Free Lunch Is Over
Is an article from Herb Sutter (C++ expert) published in 2005.
It stated that microprocessor serial-processing speed is reaching a physical
limit, which it leads to two main consequences:
• processor manufacturers will focus on products that better support
multithreading (such as multi-core processors), and
• software developers will be forced to develop massively multithreaded
programs as a way to better use such processors.

15. CAN DO?
WHAT
WEDESIGN

16. Twelve-Factor App methodology
• The twelve-factor app is a methodology
for building software-as-a-service apps.
• Minimize time and cost for new
developers joining the project.
• Maximum portability between execution
environments.
• Deployment on modern cloud platforms.
• Continuous deployment for maximum
agility:
– and can scale up without significant
changes to tooling, architecture, or
development practices.

17. Codebase
• There should be exactly one codebase
for a deployed service with the codebase
being used for many deployments.
• Your codebase should be tracked in a
central version control system that is
easily accessible to all your developers. I

18. Dependencies
• Explicitly declare and isolate
dependencies.
• Your application might rely on external
libraries and packages to run.
• You should never assume that these
packages exist on the target system.
Instead, your application must declare all
dependencies and their correct version
explicitly.
II

19. Config
• Configuration that varies between
deployments should be stored in the
environment.
• Configuration options should never be
hardcoded.
• We rely on environment variables to
handle this configuration/sensitive
information.
III

20. Linkable Backing services
• All backing services are treated as
attached resources and attached and
detached by the execution environment.
• A backing service is one that requires a
network connection to run, like MySQL.
• If the location of such a service changes,
you should not have to make code
changes.
• These details should be available in the
configuration.
IV

21. Stages of creation
Build, release, run
• Strictly separate build and run stages.
• The build stage is fully controlled by the
developer.
• The release stage prepares the build for
execution in the target environment.
• The run stage executes the application
and should not need any intervention.
V

22. Stateless Processes
• Applications should be deployed as one
or more stateless processes with
persisted data stored on a backing
service.
• Stateless applications are designed to
degrade gracefully. That means if a part
of your application stack fails, the app
itself does not become a failure.
VI

23. Port binding
• Export services via port binding.
• Your application service should also be
accessible via a URL, just as your
backing services are.
• This enables your application to be fully
self-contained.
• Self-contained services should make
themselves available to other services by
specified ports.
VII

24. Concurrency
• Concurrency is advocated by scaling
individual processes.
• Every process inside your application
should be treated as a first-class citizen.
• That means that each process should be
able to scale, restart, or clone itself when
needed.
VIII

25. Disposability
• Maximize robustness with fast startup
and graceful shutdown.
• Fast startup and shutdown are advocated
for a more robust and resilient system.
• When you deploy new code, you want
the new version to start right away and
be able to deal with incoming traffic.
IX

26. Dev/Prod parity
• Keep development, staging, and
production as similar as possible.
• That means working on the same
operating system, using the same
backing services and the same
dependencies, and so on.
• This reduces the number of bugs and
downtime and allows your organisation to
have a much more rapid development
cycle.
X

27. Logs
• Applications should produce logs as
event streams and leave the execution
environment to aggregate.
• However, your application should not be
concerned with the storage and
management of these logs. XI

28. Admin Processes
• Run admin/management tasks as one-off
processes.
• Any needed admin tasks should be kept
in source control and packaged with the
application.
XII

29. Cloud Native (CN)
Applications
• Cloud-native technologies are used to
develop applications built with services
packaged in containers.
• Deployed as microservices and managed
on elastic infrastructure.
• Usign agile DevOps processes and
continuous delivery workflows.
• With some features…

30. Massively & Dynamically Scalable.
The ability to..
1. Grow the deployment footprint
dynamically (Scale-up) as well as to
decrease the footprint (Scale-down).
2. Gracefully handle failures across tiers
that can disrupt application availability.
3. Accommodate large development teams
by ensuring that components themselves
provide loose coupling.
4. Work with virtually any kind of
infrastructure (compute, storage and
network) implementation.
I

31. Support a range of interfaces
• The User Experience (UX) is the most
important part of a human facing
application.
• End users could not care less about the
backend engineering of these
applications as they are focused on an
engaging user experience.
• CN applications need to natively support
mobile applications.
II

32. High automated Provision-Deploy-
Scale lifecycle
• CN application:
– needs to be abstracted completely
from the underlying infrastructure
stack.
– automatically scaling to meet demand
and resource constraints and
seamlessly recovering from failures.
– in providing resiliency, fault tolerance
and in generally supporting very low
downtime.
III

33. Built using CI (Continuous
Integration) and CD (Deployment)
• Reduce the vast amount of manual effort
witnessed in monolithic applications.
• From a CN development standpoint, the
ability to quickly test and perform quality
control on daily software updates is an
important aspect. IV

34. Support for Playgot Data Model
• The RDBMS has been a fixture of the
monolithic application architecture.
• CN applications, however, need to work
with data formats of the loosely
structured kind as well as the regularly
structured data.
• This implies the need to support data
streams that are not just high speed but
also are better suited to NoSQL/Hadoop
storage/Graph QL.
V

35. Deep Support to APIs
• APIs have become the de facto model
that provide developers and
administrators the ability to assemble
digital applications such as microservices
using complicated componentry.
• CN applications use APIs in multiple
ways:
– to interface loosely coupled.
– to interact with the overall cloud
infrastructure services.
VI

36. Microservices Architecture
• Microservices are a natural
evolution of the Service Oriented
Architecture (SOA) architecture.
• The application is decomposed
into loosely coupled business
functions and mapped to
microservices.
• Each microservice is built for a
specific granular business function
and can be worked on by an
independent developer or team.
VII

37. Non-Functional Requirement (NFR)?
We have many ways to cross the ocean...

38. NFR
HOW ? systems engineering and requirements engineering, a non-
functional requirement (NFR) is a requirement that specifies criteria
that can be used to judge the operation of a system, rather than specific
behaviors.
WHAT? NFR are contrasted with functional requirements that define
specific behavior or functions.

39. NFR Guidelines
Don't miss the objective!

40. Our value is people
Solution
Modeler
Solution
Developer
Front-end
Developer
Back-end
Developer
Core
Developer
Product client
Maintainer
Product
Designer
Product
Delivery
Platform
Developer
Data Solution
Developer
The platform mission is to help these people to do
suddenly their best with less effort!

41. Don't be in love with technologies
but…takes advantage of the best!

42. Our Vision
• Bloomy Decision Platform
• An holistic SaaS platform to support
companies data analysis/predictions
applications, based on the ACTOR core
products.
• Provide complex solution as a immediate
Service for our clients, on any kind of
platform.
• High Quality - develop Cloud Native
applications, according to the twelve app
methodology.

43. Our platform architecture
ACT Cloud
or Amazon AWS – Google CP – IBM Bluemix – Microsoft Azure
or On-premises Environment
ACT Cloud Orchestration (e.g. Kubernetes)
Enable the users to
develop the ACT core
product in scalable
and efficient way.
Moreover, provides
the data support and
integration with
customers data.
Core
Provides services to
interact with
different instances of
ACT core services,
servicers for building
and running ACT
workflow.
Platform
Enable the users to
develop the process
workflow, combining
the ACT score.
Moreover, easily
supports users to
develop the product
views, and data
model definition.
Dashboard
Provides the ACT
product frontend.
Moreover, allows the
customers to
personalize/create
the views and easily
change the workflow
parameters.
Frontend

44. The idea is
delegate as
much as
possible the
solution
scalability
to the
platform.
Having a fast car doesn’t make you a better driver!
Our MANTRA is Scalable Solution

45. What is scalability?What is scalability ?
The scalability requirement measures the capability of the system to react to the
computational resources used (e.g. It is desirable that our system provides better
performance when the number of nodes involved increase).

46. Large-Scale Web Applications
Avoid Spaghetti Code! Take your time!
Or (re)use good solution!

47. Platform User Experience

48. CSPAGNUOLO@UNISA.IT
THANK
YOU