You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The long term view of Miren is that application management isn't just about to manage the application once it's written, it's about providing tools to make developing the application as well. One reason we have this view is that development and deployment go hand in hand: in the cycle of application development, authoring new code is directly connected to new ideas AND the results of the currently deployed code.
One of the elements here is getting users away from wiki pages and Google Docs on how to setup their development environment, instead giving teams the ability to prescribe what is required to develop a particular application.
Using everything we've learned and built for running user workloads, we want to add "development environment" to the list of workloads that we can run for you. In practical terms, that means a few things:
Long running, ad-hoc environments. You can open code in an editor and having all the tool tools like Language Servers, AI assistants, etc available in a consistent way each time.
Development and Test services. Using what we've built for deployed services, allow you the ability to use a consistent, easy workflow to request services like databases, object storage, etc. These services are confined to just your needs while you're doing development and testing, and they're configured the way the team wants.
Runs where you need it. Following on with our self-hosted and flexible compute models, you should have the ability to get development environments on a laptop, on a server under your desk, or in the cloud.
The long term view of Miren is that application management isn't just about to manage the application once it's written, it's about providing tools to make developing the application as well. One reason we have this view is that development and deployment go hand in hand: in the cycle of application development, authoring new code is directly connected to new ideas AND the results of the currently deployed code.
One of the elements here is getting users away from wiki pages and Google Docs on how to setup their development environment, instead giving teams the ability to prescribe what is required to develop a particular application.
Using everything we've learned and built for running user workloads, we want to add "development environment" to the list of workloads that we can run for you. In practical terms, that means a few things:
Current (inconsistent dev setup):
graph TB D1[Developer A] --> W1[Wiki Page] D2[Developer B] --> W1 D3[Developer C] --> W1 W1 --> E1[Local Env - Mac] W1 --> E2[Local Env - Linux] W1 --> E3[Local Env - ???]After (Miren dev environments):
graph TB subgraph "Miren" C[App Config] end C --> E1[Dev Env - Laptop] C --> E2[Dev Env - Server] C --> E3[Dev Env - Cloud] E1 --> S[Same Services & Tools] E2 --> S E3 --> S