Skip to content

Latest commit

 

History

History
179 lines (148 loc) · 6.71 KB

ROADMAP.md

File metadata and controls

179 lines (148 loc) · 6.71 KB

this issue will try to sum things up about where otoroshi is going, what otoroshi can be and how everything will work.

Roadmap

  • Q1 2022
    • implement the new proxy engine
    • implement basic views for the new proxy engine
    • implement some enterprise plugins (payload transformation, soap, etc)
    • implement secret vaults support
    • implement tracing plugins
  • Q2 2022
    • implement views for the new proxy engine
    • implement a "try it" view for services
      • REST
      • GraphQL
      • reporting
    • implement secret vaults
    • implement grapql plugins (except federation)
  • Q3 2022
    • rollout new proxy engine
    • implement k8s SMI spec support
    • implement k8s Gateway API support
  • Q4 2022
    • use wizard to help resources creation
      • use @maif/react-form

versioning

after releasing 1.5.0 we plan to make a new release immediately with version number 16.0.0 as previous minor version where actually major ones. We will not make a 15.0.0 as there are already alpha releases of the 1.5.0.

authentication and security

provide the authentication modules needed for most cases and associated tools

  • Local (in memory)
  • LDAP
  • OAuth1
  • OAuth2
  • OIDC
  • SAML v2
  • support ocsp, aia, public keys access through jwks.json
  • support oauth2 client_credentials flow
  • pluggable authentication modules using the existing discovery mecanism
  • plugin to handle basic auth calls
  • plugin to handle OAuth1 calls
  • plugin to handle OAuth2 calls
  • more integration of biscuit tokens
    • add biscuit playground to the UI
  • access control helpers
  • spikes and DoS detection and arrest
  • beyondcorp like setup helpers
  • secret management from pluggable vaults
    • apikey secrets
    • jwt verifier secrets
    • certificates keypairs
    • datastore credentials
    • auth. modules secrets
    • data exporter secrets
    • config. file secrets
    • global config secrets

plugins

  • versioning helpers
  • orchestrator plugin (based on flow plugin work)
  • access control helpers
  • eureka compatibility
  • representation plugins
    • protocol transformations
      • rest to soap
    • payload transformations
      • json-to-xml
      • xml-to-json
  • graphql plugins
    • graphql query as REST
    • graphql proxy with validation
    • graphql federation
    • graphql composer

backoffice

  • multi-instances
    • where to store access_keys ?
    • multi-cluster monitoring
  • customizable embbeded dashboarding
  • UX enhancements
    • introduce simplified wizard to enhance user experience
    • introduce graphical service creation/design mode to enhance user experience
    • "try it" feature with debug mode

container orchestrators

  • support for kubernetes ingress controller api
  • support for custom kubernetes CRDs to configure otoroshi
  • optimize kubernetes CRD job
  • support for SMI spec
  • support Gateway API

clustering

  • support postgresql as leader datastore
  • support S3 as leader datastore
  • support cosmos db as leader datastore (should be already true with cassandra support but needs to be checked)
  • master - master replication (leader / follower at least)
  • experiment around lightweight workers
    • written in rust (based on sozu or hyper ?)
    • written in c++ and lua (based on envoy ?)

observability and data exports

deprecations and renaming

  • rename everything master/slave in the api
  • rename everything blacklist/whitelist in the api

language

  • upgrade to scala 2.13.x
  • upgrade to scala 3.x.x

multi-tenancy

  • support multi-tenancy through organizations and teams in the UI and admin API

platform

  • investiguate graalvm build and perf boost
  • build a graalvm native image
  • investiguate using polyglot api and embedded languages of graalvm for better scripts
  • investiguate using WASM as script language (run with wasmer-java)

otoroshi.next

at some point we will have the opportunity to rewrite otoroshi with major breaking changes

  • remove play framework
    • rewritte http engine using akka http
  • split admin api http server and http routing server with default routing for admin api
  • modular architecture rework
    • default template (customizable) for services with standard plugins
    • make it the default
    • powerful reporting mecanism that can support debugging
    • rewrite http handler to be mostly plugin based
    • targets should be a separate entity to allow reuse
    • store targets as entities ???
    • extract standard plugins from legacy http handler
  • configuration enhancements
    • move all app.* config. keys to otoroshi.* in config lookups
    • move all app.* config. keys to otoroshi.* in config file
    • move all app.* config. keys to otoroshi.* in documentation
    • all env. variables about initial data should start with OTOROSHI_INITIAL_
    • merge app.* and otoroshi.* to avoid confusion
    • all env. variables should start with OTOROSHI_
  • rewrite datastore layer to be less redis specific and offer better performance improvement possibilities
  • rewrite entities
    • each entity has a creation timestamp
    • each entity has an update timestamp
    • each entity has an id that is human readable ${entity_singular_name}_${uuid}
    • each entity has a name
    • each entity has a description
    • each entity has metadata
    • each entity has tags
    • each entity has a version
    • each entity has a json write function

storage

  • switch default redis driver to lettuce and remove rediscala
  • remove support for mongodb
  • remove support for leveldb