A developer with M.Sc. in Computer Science. Working professionally since 2010. In my free time I make music and cook.
Also I don't and after the recent events will not have Twitter.
Location
Budapest
Education
Eötvös Loránd University (ELTE - Budapest Hungary) Computer Science M. Sc.
First of all, I think that the node.jsdependency and indexing problem is a totally different discussion. I will comment instead on the debugging and managing microservices problem.
Reading some of the comments and being familiar with the problem (corporate secret: blame the frontend guy if they can't run your super-duper microservice cluster locally!) I think the problem is that AWS, Google Cloud, Azure and the rest don't provide integrated solutions. So either they create an end-to-end solution with the IDE shipped or it won't happen. But there are privacy, security and vendor lock-in concerns.
There are still people in 2021 who think you should handcraft every .yaml file for your kubernetes cluster - because "control". People still want an editor that is not provided by big, evil corporation and expect that it will magically work with big, evil corporation's infrastructure. And everyone is figuring out their very own custom solution for managing services, testing them and hoping they can roll back if shit hits the fan.
So I think step number one is not an IDE, but standardizing and completely hiding the variability of the infrastructure. Setup should be as easy as to select with a checkbox if you need a dev, a stage or a production cluster. You press the button and then it creates everything necessary on your local machine to interact with the dev and stage environments. And then the debugging/managing functionality of an IDE will be just pretty UI over existing services. Can't really see without total vendor lock-in.
Thanks for this valuable and educated view. The IDE for us at Codesphere is 'just' a front end. Figuring out all the very own custom solutions plenty of resources and productivity. This is unnecessary in 2021.
A developer with M.Sc. in Computer Science. Working professionally since 2010. In my free time I make music and cook.
Also I don't and after the recent events will not have Twitter.
Location
Budapest
Education
Eötvös Loránd University (ELTE - Budapest Hungary) Computer Science M. Sc.
First of all, I think that the
node.js
dependency and indexing problem is a totally different discussion. I will comment instead on the debugging and managing microservices problem.Reading some of the comments and being familiar with the problem (corporate secret: blame the frontend guy if they can't run your super-duper microservice cluster locally!) I think the problem is that AWS, Google Cloud, Azure and the rest don't provide integrated solutions. So either they create an end-to-end solution with the IDE shipped or it won't happen. But there are privacy, security and vendor lock-in concerns.
There are still people in 2021 who think you should handcraft every
.yaml
file for yourkubernetes
cluster - because "control". People still want an editor that is not provided by big, evil corporation and expect that it will magically work with big, evil corporation's infrastructure. And everyone is figuring out their very own custom solution for managing services, testing them and hoping they can roll back if shit hits the fan.So I think step number one is not an IDE, but standardizing and completely hiding the variability of the infrastructure. Setup should be as easy as to select with a checkbox if you need a dev, a stage or a production cluster. You press the button and then it creates everything necessary on your local machine to interact with the dev and stage environments. And then the debugging/managing functionality of an IDE will be just pretty UI over existing services. Can't really see without total vendor lock-in.
Thanks for this valuable and educated view. The IDE for us at Codesphere is 'just' a front end. Figuring out all the very own custom solutions plenty of resources and productivity. This is unnecessary in 2021.
Agree, we aim to build exactly what you describe.
With the difference that we build the full workflow first, with these steps:
1: private-project-scale,
2: mvp-scale,
vision: production-scale
It's not a vendor lock in because you can just download all the config and deploy it elsewhere (or change and we deploy it for you).
Think of it as a cloud provider that generates your setup where the UI is an IDE :)
That sounds great! Good luck with that!
Maintaining production replicas is a joyless task that takes too much time away from actual coding.
Thank you, that is the idea :)