Johno2518 Posted August 9 Posted August 9 In moving forward, Invision should release a Docker Container image (via a registry of course) in addition to or instead of zip files. I would imagine the preference would be for a Linux container only. This keeps everything simple and consistent. If add-ons are required then they can be downloaded and "installed" to persistent storage attached to the container or someone can build ontop of the official release. I would think this is the approach Invision have taken for deployment/maintenance of the Cloud offering and so it would simplify and align the classic offering. asd937 1
Marc Posted August 9 Posted August 9 19 minutes ago, Johno2518 said: would think this is the approach Invision have taken for deployment/maintenance of the Cloud offering and so it would simplify and align the classic offering. Good guess, but nope 🙂 asd937, AlexWebsites and Ryan Ashbrook 1 1 1
Johno2518 Posted August 19 Author Posted August 19 On 8/9/2024 at 7:51 PM, Marc said: Good guess, but nope 🙂 What are the show stoppers?
Marc Posted August 19 Posted August 19 42 minutes ago, Johno2518 said: What are the show stoppers? What are the show stoppers for what? Im not sure what you are asking here
Johno2518 Posted September 3 Author Posted September 3 On 8/19/2024 at 9:20 PM, Marc said: What are the show stoppers for what? Im not sure what you are asking here What are the show stoppers or considerations for not using container images?
Marc Posted September 3 Posted September 3 6 hours ago, Johno2518 said: What are the show stoppers or considerations for not using container images? I'm not sure I said that there are show stoppers for not using container images. What I said is its not how our cloud platform works. In fact a cloud site is actually implemented quite differently to that of a traditionally hosted platform Its worth noting, that when looking at feedback and suggestions, there has to be a value add for us to make such changes. In the case of this, it would be quite a large change to our current methods of deployment, for quite little payback. This isnt to say that a decision has been made not to (that would not be mine to make). I'm just saying its not quite as simple as saying "This hasn't been implemented because there are showstopping issues that stop us from doing so". Most suggestions are perfectly doable, its just most dont make sense to do within the scope and vision of our platform.
Johno2518 Posted September 12 Author Posted September 12 I think there is varying definitions of traditional platforms. To me traditional is standing up infra to host the application. The modern approach is to use containers which removes the issues of what to include or not and how it's hosted. Spin up a container with required parameters and it's up and running - no need to think about which PHP version is needed, which Apache version or NGINX or whatever is needed etc. I would think this would be of significant value considering this is one reason Invision doesn't support the product on Windows/IIS - understandable you don't want to support a myriad of different platforms and configurations which is one thing containers address. I'd also think this add's a ton of value to the cloud offering. When you say "vision of the platform" - part of that is how to modernise the deployment and upgrade/rollback experience and it would be good to know what options have been considered and why certain things have been ruled out because it gives us insight into what Invision is thinking about it's product and services.
Marc Posted September 12 Posted September 12 6 hours ago, Johno2518 said: I would think this would be of significant value considering this is one reason Invision doesn't support the product on Windows/IIS - understandable you don't want to support a myriad of different platforms and configurations which is one thing containers address. I'd also think this add's a ton of value to the cloud offering. As with the above assumption on how our cloud platform works, this is also incorrect. We dont actually support any environment. We support the product, and state the following Quote Our software works with all modern web servers (Apache, nginx, lighttpd, etc.) that can support secure versions of PHP (with GD, mbstring and all default extensions) and MySQL. The added line related to windows server is in absolutely no way at all related to how its set up. Its related to the fact we have seen on many occasions issues when people are using IIS. Usually surrounding things like permissions etc, but often related to the underlying server setup. Not necessarily just IIS. Quote I'd also think this add's a ton of value to the cloud offering. I have to admit to being a little confused as to why you believe this to be the case? We don't "spin up" a new box when someone creates a new cloud instance. Its essentially just an account. While it will have it owns files (things that people have uploaded) and its own data, it doesn't necessarily mean it will have its own instance of the software. You are thinking of this in terms of an installation that is done on self hosted, and cloud just doesn't work in that manner in any way. 6 hours ago, Johno2518 said: When you say "vision of the platform" - part of that is how to modernise the deployment and upgrade/rollback experience and it would be good to know what options have been considered and why certain things have been ruled out because it gives us insight into what Invision is thinking about it's product and services. We are not likely to get into the decisions made on a daily basis for each items we decide on. Its simply not feesable. We have too many things we make decisions on daily. However I can put this into some context for you by asking you a simple question. If in your job, whatever that happens to be, you could do something that would add nothing at all in terms of value as a company. Would you do it? The reality is, the 'self-hosted' product is a shrinking market. We have made changes to the licensing to ensure that its viable for the immediate future for our customers. But we need to be selective over what we spend development time on, and things such as these are not really of huge value. Note again, it's not a decision that I would personally make. However I'm giving you the reasoning why its probably unlikely. G17 Media 1
G17 Media Posted September 13 Posted September 13 (edited) On 9/3/2024 at 1:37 AM, Johno2518 said: What are the show stoppers or considerations for not using container images? IPS won't do this because their cloud system doesn't work like this. However, we actually locally maintain our own Docker "master image" which has all of our custom apps and tweaks to IPS - as well as custom written ability to automatically upgrade (e.g. automatic database and IPS formatted application upgrades) as well as automatically install for testing branches etc. It doesn't actually require any changes to IPS' core code (at least for v4 😆), so you can definitely hire a developer or work on doing the same in-house if you want a serviceable Docker image. IPS give us the software, it's up to us how we chose to install/deploy/configure it. Edited September 13 by G17 Media Ryan Ashbrook, Nathan Explosion, Daniel F and 2 others 5
Johno2518 Posted September 29 Author Posted September 29 On 9/14/2024 at 3:58 AM, G17 Media said: IPS won't do this because their cloud system doesn't work like this. However, we actually locally maintain our own Docker "master image" which has all of our custom apps and tweaks to IPS - as well as custom written ability to automatically upgrade (e.g. automatic database and IPS formatted application upgrades) as well as automatically install for testing branches etc. It doesn't actually require any changes to IPS' core code (at least for v4 😆), so you can definitely hire a developer or work on doing the same in-house if you want a serviceable Docker image. IPS give us the software, it's up to us how we chose to install/deploy/configure it. I'm quite capable of doing this - however it would be much better if Invision were using modern methods for delivering their software.
Johno2518 Posted September 29 Author Posted September 29 On 9/12/2024 at 5:14 PM, Marc said: I have to admit to being a little confused as to why you believe this to be the case? We don't "spin up" a new box when someone creates a new cloud instance. Its essentially just an account. While it will have it owns files (things that people have uploaded) and its own data, it doesn't necessarily mean it will have its own instance of the software. You are thinking of this in terms of an installation that is done on self hosted, and cloud just doesn't work in that manner in any way. If you believe "spinning up" a new box is required then it sounds like you don't know how containers actually work. There are a couple of methods to make an application multi-tenant. One method is to spin up container instances that service a specific tenant (customer environment). The other is that the application is natively capable of operating in multi-tenant. I would imagine that the former is being used - only - it may not be containers. It could be you're deploying directly from the CI/CD pipeline. Nevertheless, it would make sense to use containers moving forward. Invision is still providing "self-hosted" software so while it does then it should invest in modern deployment technology especially where this makes sense to use internally as well. I don't see containersing as adding no value - while no information is provided on how Invision runs it's cloud there aren't that many configuration on how it could be run efficiently and at scale. Further, the cloud plans offered are quite expensive for the value provided. If this was different then yes you'll probably find most if not all customers would be on the cloud plans (except for one caveate, currently there are only two locations offered for hosting which may not be suitable for some customers). Self-hosting will most likely be around for a long time unless Invision progresses the cloud plans quite substantially to make it worth the jump. The updates to the cloud plans have been extremely slow to say the least (I check on them from time to time).
Recommended Posts