Trampoline
Trampoline copied to clipboard
ErnestOrt
Trampoline Cloud
Grat app. However, it would be nice if it could be used as a cloud container.
In order to do that, it should implement at least: #71 security #70 monitoring #37 process API #45 Rest API for continuos deployment
Hi @andresoviedo
Thanks for your kind words and feedback!!
However, the original goal of Trampoline is to help locally developers. Not sure if this project need to see it in a cloud level. Don't you think there are much more powerful tools released and much more mantained.
Thinking that, I would not do any security development since I guess could be really anoying to have to log in each time in a user level, taking into consideration this local app nature.
What do you think @cforce??
Cheers
Many of the tasks can be achieved by using Spring Cloud Skipper as library to manage the cloud deployment, but actually there is no web UI got it, just shell. https://cloud.spring.io/spring-cloud-skipper/
Spring boot admin also implements some things. But I dont know if it implements deployment of new microservices.
Sure it does - at least for Cloud Foundry an Kubernetes, which is available on Azure, AWS and GCE. Trampoline could run the skipper and provide UI for the skipper rest api, that also provides oauth
Andres Oviedo [email protected] schrieb am Mo., 13. Aug. 2018, 17:29:
Spring boot also implements some things. But I dont know if it implements deployment of new microservices.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/ErnestOrt/Trampoline/issues/72#issuecomment-412558983, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYARpKU1kM5kGUnEgqqTunEl9umqr-Eks5uQZs9gaJpZM4V5OWj .
I'm going to start a conversation with Skipper development group then. It could be interesting to set up a discusion and ideas exchange as well for both sides.
Have a great week!
@ErnestOrt @andresoviedo I'm late to the party here I know, but I wanted to throw in my 2 cents as a developer in the microservice/cloud native world.
When I am working locally day to day, I prefer to focus on the services themselves and be able to code and test without the complication of cloud configs, security, deployments, etc so I can turn code around quicker. I save all those bits for later as part of integration tests. This does involve me often having 10+ local services running and its a pain trying to remember whats running in what terminal, whats on which port etc, a problem shared by most of my team until I read about trampoline. The simplicity was it's appleal and adding all the cloud based aspects of development would turn it into another feature heavy tool with too many options.
However, this is just my own personal experience and opinion, I still would agree with both top comments and I think there is value in what @andresoviedo suggested. Maybe the best approach would be to create a separate fork or project (eg. trampoline-cloud) which focuses on managing cloud based stuff and leave trampoline as a separate tool for simple local development only? Users can pick and choose then depending on their workflow needs? I know eventually I would need to use the features suggested later in my dev cycle but I like a cloud free zone to start with 😄
Personally, I love your service and it has helped a lot - For use also on older windows servers that cannot use virtualization. There are still some corporate environments that are behind the times.
Not everyone always has access to virtualization, and hence docker/kubernities or cloud providers like azure/aws.
At one of my customers, we have windows housing containers where virtualization has been turned off for us. So, the only solutions are to manually deploy flat jars, jenkins, or to use trampoline.
@menelaosbgr Thanks for sharing your thoughts! Happy to hear it has worked for your use case :)