This KB entry was added yesterday. Does that mean that Docker is now supported ?
We are still working out our Docker support strategy, so stay tuned!
We are still working out our Docker support strategy, so stay tuned!
Any update? We have a target model at a customer who want to deploy a PASOE Application (11.7.x) in a Linux container. Is this supported by Progress?
Just curious, why would you want to deploy an application server in a docker container?
at the risk of annoying the progress gods, Let me turn that round .. why *wouldn't* you want to ? :)
It makes perfect sense to load PASOE in a docker. Because that will enable automatic loadbalancing for example. Not enough PASOE-instances? Spin up another docker dynamically.
In fact, we are trying to run our entire OpenEdge aplication backend inside a docker container. The PASOE, Database, etc.
to paraphrase (steal) my business partner's response on another docker thread :
"We have been working with Docker since 2014, and have also been working with OpenEdge in containers internally since we started with this. Most of the time we have been using Linux based containers, and this has worked very well. there are a few things to look out for, and I believe that Progress are looking into these as part of their work on this.
We have recently been trying out Windows containers and trying to get OpenEdge into images here. Although we have managed to get this working, there are some challenges with the initial install and with the subsequent, very large, images that are created. The size of the images is mainly an MS issue - as their images are very large. They have come down in size - but are still much bigger and heaver than linux images.
As far as I know, OE is not currently officially supported on Windows Server Core - which is the image that we have been using."
> On Jun 4, 2018, at 2:33 PM, jmls wrote:
> why *wouldn't* you want to ?
just because you can, does not mean you should.
virtualization has advantages and disadvantages and there are many kinds. blindly moving forward because someone touts the pros without considering the cons will get you into trouble for sure. also, some people’s hoped for advantages are never realized. i have seen lots of poorly performing systems caused by people believing sales droids and execs who read the magazines on airplanes.
that said, i do NOT say docker is the wrong thing to use. sometimes it is and sometimes it ain’t.
It's not only performance, that counts. If you have a swarm of docker containers running version 1 of your application, you can upgrade by rotating and slowly move all containers in the swarm to version 2 of the application without anyone noticing it.
OpenEdge is more and more a backend-solution, given the fact that most new / modern interfaces will be done in things like NativeScript, React, Angular and so on.
Having a fast and reliable way to scale your backend up and down is a big advantage.
Progress should, imho, really come up with a cohesive strategy to support Docker. Not only that Progress delivers us Dockers, but also that Progress makes sure we can create containers ourselfs.
Not joining Docker is like slamming the door shut to a future for OpenEdge as a stable, scalable and reliable, 24x7 up, cloud backend for Webapps, Nativeapps and the occasional Desktop user.
Gus - I couldn't agree with you more. There are loads of pros and cons , and if you don't set it up right , not only will you get poor performance but you could lose all of your data in a blink of an eye without knowing just wtf happened - several days or weeks later.
Yes, it happened to me. A few times. At least now I'm battle-hardened and battle-tested and know which commands *not* to use :)
I would also say that anyone who knows me would know that I am as far away from being a sales droid and exec as you can possibly be :)
Hi, I believe that running PASOE in a Docker container will work (and MAY offer advantages). BUT I am hoping that Progress can a) say that that is supported, and b) give guidance on licensing.
Does each container need a license?, what if they are hosted on same VM? I could see us deploying multiple containers with the same license and it working, but I do NOT want to break any T&Cs or rob Progress. I am reluctant to start building such an environment until there is some word on how licensing will work with Docker swarms.
I think that in general, your question on support and licensing should be answered by Product Management or your account representative.
However, I wanted to say that there is a new project to provide a baseline Docker image with PASOE that Progress can support.
If you are interested on future development work, you could join the OpenEdge CVP (Customer Validation Program) to participate on the program, access builds of the software (once available) and provide feedback:
Regarding licensing, from what I understand, the Named User license model could be an approach to handle the license in a Docker environment.
There is no specific mention of containers, however, this type of license can be associated with a Non-Human operated Device and it is not limited by Core, CPU or Server count.
Please confirm with Product Management / Account representative on this.
I hope this helps,
I am the Product Manager and I can confirm what Edsel wrote above. We are looking at how best to support Docker containers and will be collaborating with customers and partners about this in OpenEdge CVP user group, so you may consider joining it.
I like the idea of Docker for PASOE too. (Probably not so much for the database server.)
I think I understand the reasoning behind the recommendations for moving to "Named User" licenses in conjunction with Docker. Please correct me if I'm wrong. In the EULA , the "Named User" license is the only one that doesn't have this docker-killing statement "A <Whatever-Alternative> License may not be transferred from one Server or Platform to another".
The problem I see with "Named User" licensing is that it is not a cost-effective way to manage general-purpose back-end services like a database or a generic application server. Progress is taking a licensing model used for front-end applications like MSOFFICE, and AUTOCAD, and trying to apply it to a back-end server platform where it doesn't belong. I don't think many companies will want to use Docker if there is a condition that they have to buy named user licenses for anyone who might ever connect to any ABL-based application code or make an OE database query.
The next problem with PASOE on Docker is performance. Whenever I run ABL code with client/server (TCP) connections, I am constantly reminded how slow things are as compared to a direct, "shared-memory" connection to the database. Unless the OE database *and* PASOE are both put in the same docker container, then OE customers won't be able to take advantage of Docker without losing their direct "shared-memory" connections.
While there are "check-lists" to make client/server connections work better (primarily by leveraging NO-LOCK loops and removing nested loops), it only goes so far. This type of remote database connectivity is not a place where OE ABL has excelled. Its interesting to read some of the KBs (eg. https://knowledgebase.progress.com/articles/Article/18342) which contain the client/server performance "check-lists". In that article - all about improving the performance of client/server database connections - there is a section at the end with the title "THE APPSERVER ADVANTAGE". It seems to say that your best bet for performance is to avoid client/server database connections after all, and to connect to an appserver instead (presumably one that shares memory with the database directly). The section at the end seems to undermine the purpose of the article and tells the user something that they are already painfully aware of.
Aside from the licensing issues and the client/server performance issues, I am pretty eager to be able to use Docker for PASOE deployments. Docker would greatly improve the story of being able to "continuously deliver" ABL applications into production. We use a ton of home-grown solutions for that type of thing, as most Progress customers probably do.