Non-technical questions about moving from "classic" appserver to PASOE - Forum - OpenEdge General - Progress Community

Non-technical questions about moving from "classic" appserver to PASOE

 Forum

Non-technical questions about moving from "classic" appserver to PASOE

This question is not answered

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 Replies
  • 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 ;)


    Marian Edu

    Acorn IT 
    +40 740 036 212

  • 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 :(

    I guess there are not that many installations of really old versions out there so it's probably safe now to move to using the JSON serialisation added in 11+.   

    Marians-MacBook-Pro:akera-api marian$ node test/test-load.js 100 1
    completed 100, failed 0 in 7.371 seconds
    min: 61.85133, max: 110.458242, avg: 65.48201832000002 (milliseconds)

     
    Marian Edu

    Acorn IT 
    +40 740 036 212

  • 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 :)

    Besides, it sure depends on the hardware used for testing and for me 60ms the round-trip for a server running in a docker container on an entry-level server connecting over wifi seems fair enough and closer to the typical usage we see when exposing REST micro-services for web/mobile apps.

    This is a typical akera.io memory footprint while a light configuration of Tomcat uses something between 128-256MB... YMMV I guess.

    root@e4dec28e3fed:/opt/akera# akera-server -h . demo status
    Running for : 51 days, 2 hours
    Load        : 0 %
    Free        : 4
    Busy        : 0
    Requests    : 1384
    Completed   : 1384
    API calls   : 2984
    Memory      : 36.42 MB
    Heap        : 17.84 MB
    Agents information:
    |     PID |        State |    #Req |    #API |                    Last request |
    |      32 |    Available |     345 |     705 |             3 hours, 42 minutes |
    |      35 |    Available |     345 |     760 |             3 hours, 42 minutes |
    |      38 |    Available |     347 |     789 |             3 hours, 42 minutes |
    |      41 |    Available |     347 |     730 |             3 hours, 41 minutes |


    If the database connection is done over the network then you're right, on top of database licenses Client Networking runtime is required.

    One can get faster JSON serialisation/deserialisation from OE 11+ onward, still quite a few OE10.2 installations hanging around so we have to work something out that can still support the older OE versions if we move to JSON parser available in OE11.

    The 'new' PAS is technically a new product, it did make sense for PSC to drop the middle man (AIA) for REST services so they decided to simply move the old appsrv inside tomcat... as for the 'multi-threaded agent' I still fail to understand what is that exactly since the 4GL runtime clearly is still single-threaded. Having one thread/process managing multiple 4GL runtimes and call the 'bundle' multi-threaded agent looks more like a marketing thing to me but hey I'm more of a technical guy and don't really understand sales :)
      
    Marian Edu

    Acorn IT 
    +40 740 036 212

  • The multi-session agent is NOT 1 thread per agent process as you write. You can have multiple threads in that agent process. It’s 1 thread per ABL session (or call it ABL runtime). The ABL is still single-threaded in the way that you cannot leverage multi-threading threads from ABL code. But multi-threading is used - for more light weight ABL sessions (ABL runtimes).
     
    It’s not that difficult to understand once you’ve looked that the ABL agent log.
     
    Von: marian.edu <bounce-marianedu@community.progress.com>
    Gesendet: Freitag, 27. April 2018 18:52
    An: TU.OE.General@community.progress.com
    Betreff: RE: [Technical Users - OE General] Non-technical questions about moving from "classic" appserver to PASOE
     
    /cfs-file/__key/communityserver-discussions-components-files/26/22780.image001.png
    Update from Progress Community
    /cfs-file/__key/communityserver-discussions-components-files/26/1586.image002.png
     

    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 :)

     
    Besides, it sure depends on the hardware used for testing and for me 60ms the round-trip for a server running in a docker container on an entry-level server connecting over wifi seems fair enough and closer to the typical usage we see when exposing REST micro-services for web/mobile apps.
     
    This is a typical akera.io memory footprint while a light configuration of Tomcat uses something between 128-256MB... YMMV I guess.
     
    root@e4dec28e3fed:/opt/akera# akera-server -h . demo status
    Running for : 51 days, 2 hours
    Load        : 0 %
    Free        : 4
    Busy        : 0
    Requests    : 1384
    Completed   : 1384
    API calls   : 2984
    Memory      : 36.42 MB
    Heap        : 17.84 MB
    Agents information:
    |     PID |        State |    #Req |    #API |                    Last request |
    |      32 |    Available |     345 |     705 |             3 hours, 42 minutes |
    |      35 |    Available |     345 |     760 |             3 hours, 42 minutes |
    |      38 |    Available |     347 |     789 |             3 hours, 42 minutes |
    |      41 |    Available |     347 |     730 |             3 hours, 41 minutes |
     
     
    If the database connection is done over the network then you're right, on top of database licenses Client Networking runtime is required.
     
    One can get faster JSON serialisation/deserialisation from OE 11+ onward, still quite a few OE10.2 installations hanging around so we have to work something out that can still support the older OE versions if we move to JSON parser available in OE11.
     
    The 'new' PAS is technically a new product, it did make sense for PSC to drop the middle man (AIA) for REST services so they decided to simply move the old appsrv inside tomcat... as for the 'multi-threaded agent' I still fail to understand what is that exactly since the 4GL runtime clearly is still single-threaded. Having one thread/process managing multiple 4GL runtimes and call the 'bundle' multi-threaded agent looks more like a marketing thing to me but hey I'm more of a technical guy and don't really understand sales :)
      
    Marian Edu
     
    Acorn IT 
    +40 740 036 212
     

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

    Das Bild wurde vom Absender entfernt.
     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Having one thread/process managing multiple 4GL runtimes and call the 'bundle' multi-threaded agent looks more like a marketing thing to me but hey I'm more of a technical guy and don't really understand sales :)
     
    As Mike notes, the AVM/runtime is still single-threaded. The AppServer agent process is now capable of processing multiple concurrent requests (using threads); this is why we call it the “multi-session agent”  and not something else ;). The multi-session aspect also means you need to think more about administration since if you kill the process you will terminate many sessions, not just one as per the Classic AppServer.
     
     
     
     
  • Right you are Peter, technically when I say 'process' it doesn't imply it's a single thread Mike :)

    From the outside the multi-session agent looks like a 'classical' appserver so the new PAS can simply be seen like a bunch of classical appsrv instances working together, so the main 'broker' dispatch requests to one of the ms-agents and depending on the available ABL sessions the request is executed in an 4GL runtime.

    But we're hijacking the OP thread which was a non-technical question... good think it's Friday, hurray.
     

    Marian Edu

    Acorn IT 
    +40 740 036 212

  • Nice description :)
     
    And hurrah for Friday/
     
  • Thanks Peter, glad you like it... thought to open with the 'appsrv on steroids' but went to the long version instead :)


  • 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.