Axioms For OpenLiberty Feature Design

When writing new features for OpenLiberty it is useful to consider the following points which have been established over the many years of developement.

• The right size of app server...
  • Always deliver features that keep OpenLiberty componentized
  • Maintain the ability to shrink package the server to just what's needed
  • Provided for reusable cross feature chunks, internal features used by more than one external feature
• Always seek to have simple configuration that:
  • Is minimized to real world use cases
  • Has sensible defaults
  • Is simple to understand and well documented
  • Maintains the same look and feel across OpenLiberty
• Maintain OpenLiberty's ability to self-tune:
  • Users should not have to tune for:
    • Different sizeapplications
    • Different workloads over time
• Enable zero migration cost across OpenLiberty releases:
  • CI/CD pipelines and others should always be able to upgrade OpenLiberty with zero impact
  • Maintain support for any released, non third-party, config format and API
  • Support 'as-is' migration from traditional Websphere, JBoss EAP and other JEE or MicroProfile environments
• OpenLiberty implements full JEE and MicroProfile specifications
  • This makes it easier for users to understand what they are getting.
  • Innovaton is great but seek to standardize to help users have portable apps long term
• Ever since 'develop on Liberty, run on (traditional) WebSphere' OpenLiberty has always had great developer experience and we will never degrade this. All features:
  • Must work well in loose applications from an IDE or command line tools
  • Must support source code debug (including any 3rd party jar libraries used)
  • Need to be able to 'step-into' user and server code (including protocol endpoints and reactive streams)
  • Support logging that enables user's data flow to be traced
• Fast start, high throughput
  • Do not implement features that degrade performance or which perfom noticably worse than equivalent alternatives for new features
• Class leading Kubernetes and Container integration - we seek to keep OpenLiberty the 'best in breed' JEE/MP app server for the container environment. This means:
  • Always consider how the OpenLiberty OpenShift Operator can delight its users
  • Support for container metrics and tracing
  • Enable good auxilliary tools support in Arquillion, MicroShed and TestContainers
• Continuous integration and service:
  • OpenLiberty ships full releases every 4 weeks, rolling up service fixes along with new features - are all upstream dependencies actively maintained to a level that can support this?
  • Is there a clear route for 'responsible disclosure', for example using CVE's, for any vulnerabilities in all dependency's libraries?
• A Hardcore App Server
  • Users frequently port large, heavily loaded, applications from traditional Websphere to Liberty. OpenLiberty will never stop being a great codebase for high load, large enterprise applications whether running natively or in OpenShift/Kubernetes. Any feature or design that weakens that will not be approved.
  • There is zero toleration of any thread, memory, connection, or bandwidth etc. leaks under long running and high loads - under any circumstances whether transitory, exceptional or unexpected error paths.
  • Support soft feature shutdown with polite work quiesing
  • Build-in tolerance of stress with managed ingress/concurrency and polite stress signalling
  • Instrumentation that enables customers, and at worse service teams, recover from the unexpected
  • No 'dark matter' with full oversight of threads, ports, files, and other resources available to developers and service reliability engineers.
  • Full support for first-failure data capture and collecting 'must-gather' information.
• Licences check out OK on all OSS and 3rd party libraries
• Accessibility - any screen interfaces follow our inclusive accessibility conventions
• I18N - translation of user messages supported where relevant