I am eager to start using PASOE. I was wondering if anyone can offer some advice on how to make a switch from "classic" appserver. Some of our biggest challenges in moving forward are non-technical.
Given that "classic" appserver is essentially deprecated (and is not receiving much innovation or investment or support) we'd like to switch to PASOE. Our technical evaluation of PASOE shows that it will be a suitable replacement, and my interaction with Progress tech support leads me to believe that there is ongoing development on PASOE (unlike with "classic" appserver).
Unfortunately non-technical issues are delaying our migration to PASOE, and may prevent it altogether.
The main problem is in the negotiating of the price for changing from one type of appserver to the other. Progress sees these as two totally different products and will give us only a small credit for "classic" appserver purchases that we have under maintenance. It seems that customers are basically being asked to start from scratch as we attempt to migrate to PASOE. This is a very hard thing for Progress to ask - since the portions of PASOE that we are prepared to use (APSV transport against standard ABL applications) are largely the same as they were in "classic" appserver.
Ideally there would be an "Express" version of PASOE that would remove new functionality (SOAP, REST transports, scale-out architecture, etc). Such a version would allow "classic" appserver customers a migration path without forcing us to re-purchase something from scratch that feels substantially the same as what we already have with the "classic" appserver.
Keep in mind that the new bells and whistles are only a small factor in the drive to make the switch. This switch is mostly about staying on a well-supported product which receives ongoing software maintenance. Our yearly maintenance dollars that are intended for "classic" appserver support are probably being re-invested in PASOE, since little has been changing on the "classic" side of things. It seems that the past five years of those maintenance dollars should be counted as credit towards PASOE as well, right?
I'm interested to hear any alternative perspective, or tips on how we might move forward. Does the idea of a PASOE "express" version have any potential? That would allow Progress to charge customers for new features (in a separate "advanced enterprise" edition), while not imposing their costs on customers who don't necessary need them.
Finally, I was wondering how long it might be before Progress has their own reasons for encouraging customers to get out of "classic" appserver. Perhaps they won't want it to be included anymore in OE 13 and will be removing these significant barriers that are preventing customers from switching.
All I can say is that we struggle with the same thing.
We currently don't publish a large enough number of APIs to make it a problem. We don't have scale issues. Also we would have to rewrite a large routing/url-rewriting system (based on the location of the cgi script). Cost would increase and we don't see a lot of great advantages. A hard sell indeed!
I can't speak about Progress's upgrade policies but in case a less 'classical' alternative could be considered take a look at our node.js powered application server - akera.io, we've just updated the price list to make it more ISV friendly ;)
That seems like an interesting product. I've wondered what would be involved in writing a custom appserver solution on top of the OE runtime.
I think one of the main concerns I would have is related to the performance overhead (given that ABL is already a bit slow). With classic state-free appserver clients we can make round-trips in under 3 ms for some cases.
I guess it all depends on what is happening on the back-end, for a simple procedure that takes the customer number as input and then goes through all customer's orders and invoices to compute the total amount of ordered items and what was invoiced the average call time is around 60ms and that's including establishing connection for each call. However, the overhead of establishing the connection is next to nothing... the only overhead at this time is because of the JSON serialisation routine that uses 4GL string manipulation :(
Have you ever tried to measure your fastest-possible round-trip on your appserver (ie. send in the customer number and get out the customer name)? If you did that a thousand times, would your average be under 5 ms?
So if I understand, it sounds like you may be using OE-AVM processes that are running in batch mode (ie. each is a standard single threaded progress.) And you communicate with them by using ABL's TCP ports and you typically send/receive JSON for your serialization format (for the sake of performance).
I'm wondering how that works from a Progress licensing perspective. If the database is on a remote server then the only Progress-related licenses needed would be their so-called "client networking", along with necessary DBMS licensing, right?
I think the big advantage that PASOE has over this solution is faster serialization/deserialization between "openclient" and server, and it also has the multi-threaded AVM processes for better use of memory resources on the computer. Progress also has their proxygen for strongly-typed clients, and a bit more investment in the developer tools for ABL programmers. Either way, Progress shouldn't be requiring customers of "classic" appserver pay a premium to re-purchase something that amounts to the next version of appserver. Nor do I think they should pretend as if these are two different products that will both continue to be developed in parallel; the "classic" one is already at the end of its road, and soon they will probably discourage any new purchases of that one. From what I've seen, the bulk of the improvement in PASOE as compared to "classic" can be credited to the use of the free tomcat server. While I understand there is a lot of integration effort to make OE work well in a tomcat host, they should not be charging us for tomcat itself - and that is essentially what they are doing by claiming that this PASOE is a totally "new" or "different" product as compared to "classic".
They did the same thing when version 10 came out "It's a new product". In that case PSC was trying to get rid of all the "unlimited" licenses they'd sold in prior years and get customers to pay more for the current version.
Since the average calls we see are nothing like this and normally the actual business logic processing takes way more time than serialisation/deserialisation I don't really try to beat them at the fastest-possible round-trip category :)
|
Right you are Peter, technically when I say 'process' it doesn't imply it's a single thread Mike :)
Does this mean that the OpenEdge Rest Adaptor will be deprecated in a future version?. What about customers who still need to use the classic App server but also need to maintain a Web Interface also
> Does this mean that the OpenEdge Rest Adaptor will be deprecated in a future version?
I'm sure the official Progress statement would be that "classic" appserver is not going away, and will always be fully supported. (ie. they will continue to pay it lip service)
Lets just say that when you need to open a tech support case, is quite a different experience for "classic" appserver than for PASOE. I've worked on both types in the past couple of years.
