Environments have been introduced more than 10 years ago. Really great stuff in these times. But to get smarter and more powerful we need to cut things off which can be solved differently today. But first what are environments?
🧐Environments for staging
Environments are used to define multiple servers already in your project like development, testing and production - known as staging. So you are able to configure your database configuration, rest client configuration and web service client configuration for multiple stages already in your project.
Sounds great. Use it or not. Your decision.
🧐Environments for multi-tenancy
After the launch of environments the years went by and more and more clients required approaches for multi-tenancy. Our solution was "use environments". For each tenant create a new environment at runtime. Configure all our database configurations, rest client configuration and web service client configuration for each single tenant.
Sounds great. Use it or not. Your decision.
🚀Ivy is strong and has come a long way
We have a great platform with great capabilities. Ivy is more than 20 years and a successful platform which has grown and grown adding new features. It's really crucial to decide which features are still important and which are not. We need to be smart.
So what are the downsides of this feature?
For us and for YOU. The environment feature adds a new layer of complexity to all features. It's not just a feature like Rest Client or Databases. No. It's adding a new layer for all of those features - which makes it harder to implement each single "real" feature. And it also makes Ivy harder for you to understand. All of our user interfaces are more complicated. Our editors in the Designer and also in the runtime in the Engine Cockpit. You always have to understand what an environment is and how it behaves.
🚔Configure productive systems in your code.
Are you really defining productive systems in your project with productive users and passwords? I don't think so. And this is mostly the only things which differs - user and password.
🚔Does not really solve the multi tenancy problem.
All features which are environment aware are looking the same for each environment. You may not need a complete additional database for each single tenant. It's maybe mainly in the data. You will need to pass the tenant id to the queries. You can pass it because you are able to define the active environment on Application, Case, Task and Session level. But this must be fully controlled by you. And things can go wrong here. Seeing data of another tenant is a no-go!
🚔Can't scale multi tenancy environments.
In my personal opinion as professional software engineer, I can not recommend to use environments as multi tenancy feature. Just because you are not able to scale. If you have 10 active tenants. You can add and add more tenants. You will need more and more power in terms of CPU and memory. You can add CPU and memory to your machine but someday, that will not be possible anymore. Then you will need to move some tenants to a new Axon Ivy Engine. There is no built-in support for that. You will need to make your own SQL scripts to export the data and importing it on a new Axon Ivy Engine. And it's getting even more complicated if you want to down scale. Moving one tenant to an existing Axon Ivy Engine installation will be really hard to handle - all those unique ids in each single table can collide.
If environments are bad what should I use?
👍Solution for staging
Just don't use environments. Configure your project for your personal development. Deploy it to your staging environments and configure your staging environments in the engine cockpit. If you search a way to automate this - which I really would recommend. You are nowadays able to add an
app.yaml to your application zip, where you can fully define all necessary configurations for this staging environment.
👍 Solution for tenants
Running multiple tenants on the same node has always one big risk: Seeing the data of another tenant. In modern environments containerize your tenant infrastructure. Run independent containers for each tenant. This will make it possible to make canary deployments or blue/green deployments.
We'll still support environments. But we won't invest effort in new editors and features. Do not use environments in new projects. Come and tell us your story if this is not a valid approach.