Graal Platform Documentation

Graal Platform Documentation

  • Docs
  • Help

›Security

Overview

  • What is Graal Platform?
  • Why use our platform?
  • How Graal Platform works?
  • Concepts
  • Jobs & workflows
  • Security

Quickstart

  • Quickstart

Tutorials

  • Get started with Python
  • Get started with Dask
  • Get started with XGBoost
  • Get started with Apache Spark and Maven
  • Get started with Apache PySpark
  • Get started with Apache Beam and Gradle
  • Use the API
  • Using the command line tool (graalctl)
  • Using secrets
  • Migration from Databricks
  • Get started with Tensorflow
  • Get started with Pytorch
  • Get started with Mxnet
  • Setting up the Hadoop bridge
  • Get started with Apache Flink and Maven
  • Get started with Dbt
  • Get started with Pulsar
  • Get started with Apache Spark Streaming Pulsar
  • Get started with Debezium
  • Get started with the SDK

How-to guides

  • Using Graal Platform with Azure Data Factory
  • Publishing your artefacts with Azure DevOps
  • Using Graal Platform with Apache Airflow
  • Publishing your artefacts with Jenkins
  • Spark
  • Network, VPN, gateway and firewall
  • Logs
  • Pricing

Security

  • Overview
  • Comply with requirements
  • Infrastructures under Graal Systems
  • Responsibilities

Troubleshoot & debug

  • Troubleshooting
  • Common issues
  • Debug jobs

Responsibilities

As a Platform as a Service, Graal Platform is responsible for maintenance and security of the underlying infrastructures. Customers are responsible for maintenance and security of their custom code running on the platform.

Graal Platform is always responsible for the following components at its platform level:

  • Operating system
  • Continuous monitoring
  • Anti-malware
  • Network security
  • Versioning
  • Scaling
  • Logging
  • Alerting

Deprecation policy

From time to time, it becomes necessary to deprecate a service, feature, or API. Below is our policy for doing so. In the description, service refers to a service, feature, API, etc.

In cases where a replacement service will be provided, we'll make the replacement service available before beginning the deprecation process. Deprecations happen in steps:

  1. We send an email to all customers letting them know the service is being deprecated.
  2. At least 30 days after the initial email, we stop allowing new instances of the deprecated service, but continue allowing existing instances to work.
  3. Every two weeks after we stop allowing new instances of the deprecated service, we email customers who are still using the deprecated service.
  4. At least 150 days after the initial email, we shut down existing instances of deprecated service.

Here's an example:

First, Graal Platform determines that the coffee service is not serving customers as well as a new espresso service might, and we decide to replace the coffee service entirely with the espresso service. First, we make the espresso service generally available. Next, we send out the general announcement to all of our users. This announcement goes out on April 3rd and states:

  • the coffee service is being deprecated
  • the replacement is the espresso service
  • as of May 3rd (30 days after April 3rd), no new instances of the coffee service will be created
  • as of August 31st (150 days after April 3rd), existing instances of the coffee service will be shut down

After May 3rd, we begin sending emails to users still using the coffee service, at least one message every other week. Finally, on August 31st, we shut down the last instances of the coffee service.

← Infrastructures under Graal SystemsTroubleshooting →
  • Deprecation policy
Graal Platform Documentation
Overview
What is Graal Platform?
Quickstart
Apache SparkApache FlinkApache BeamPythonTensorflowDaskDistributed XGBoost
Links
HomeConsoleCopyrights
Copyright © 2023 Graal Systems