Peter:
Welcome to the Unicast podcast. The one and only podcast about Uniface.
My name is Peter.
Henk:
And I am Henk.
Peter
This is the second episode, Henk.
Henk:
It is! Can we see how many listeners we had on the first episode? Or is it too soon for that?
Peter:
It’s very tempting to look at the statistics. The experts always warn not to focus on the stats too much. Especially in the beginning.
As long as we have just one listener, it suits the name of the podcast.
Henk:
Yeah yeah, that’s the theory. And in practice?
Peter:
Yesterday we had over 80 downloads!
(APPLAUSE!)
Henk:
Really? That’s great!
Peter:
That’s not a real natural growth. We mentioned the existence of the podcast during the Uniface event we had this week. I guess lots of participants looked it up.
Henk:
Shouldn’t that be our first subject for today? The 40th anniversary of Uniface? How did you experience the event?
Peter:
I really liked the event. It was well organised. The technical content was very informative. But most of all, I enjoyed the people. It left me with a very warm feeling. And you?
Henk:
Yes, I share that feeling. It was good to see this crowd coming together, not only to celebrate the past 40 years, but also to look ahead and get ready for what’s coming, The update on Uniface UX and the UX Interface was very interesting, the presentation on AI by Floris Hoogenboom really got me thinking, the customer presentations like Molis and Tribal were impressive, but most of all I liked the Workshops. I attended two workshops, one on security and another one on containerization, i.e. building a Uniface deployment environment from Docker containers. These things can be put to work without much effort, so it seems, although in real life things are always harder of course, but still. And the celebration reception at the end of the second day was good as well. It even gave the chance to meet some of the founders, who started Uniface 40 years ago on an attic somewhere in Amsterdam.
Peter:
We hosted a round table around the topic next gen community. That was very interesting and a topic to cover once in this podcast.
Let’s hope we have more frequent events like this again. In the meantime, we will have to provide the warm community spirit with our podcast, Henk. So thankfully, we were allowed to advertise our podcast during the event.
Henk:
I met several people would like to be guests on our podcast. I guess we can fill our calendar for the next few months already.
Peter:
We are definitely going to involve all of the people who have volunteered.
While we attended the Uniface event, I received a few comments on our first episode of this podcast. All were positive. Nothing to worry. One guy made a funny remark I want to share with you at the end of this podcast.
Henk:
You can share it now. Or is this a trick to make me extra curious?
Peter:
Haha, maybe it is. No, I want to see how this episode goes and see if that remark is valid. Please remind me to tell you!
Henk:
Sure will, don’t worry.
Peter
But before that, we are going to do it like the previous episode, where both of us tell something from recent experience.
Henk:
Shall I start?
Recent is a relative term, this one dates from a few years ago and is all about performance.
Peter:
Oh yes, performance is a tricky one. I have one related to that subject. Are we really going to tell the same story?
Let me guess. A dramatic drop in performance and nobody changed anything.
Henk:
Not quite. The customer was in the process of moving their client applications from on-premises to hosted applications in the cloud. The databases remained on servers in house though. This move happened at the same time that I was working at the customer to migrate their applications from Uniface 9.2 to 10.3. So, they did change quite a lot.
Peter:
Ah, the situation I recall is slightly different.
Recently, I spoke to someone who complained about performance loss of their application after they moved into the cloud. One of the reasons they went off-prem was performance improvement because, they said, in the cloud everything is faster. It wasn’t..
Let me guess again: they blamed Uniface?
Henk:
And of course, Uniface was the usual suspect, the hosting provider was very reputable, network measurements did not show anything out of the ordinary, so it had to be Uniface. I remember intensive sessions, using all sorts of TCP monitoring tools like Wireshark, tcpdump, netstat, what have you. Someone even suggested it might be advantageous to rebuild the entire application in another technology rather than migrate to Uniface 10. That couldn’t take more than 2 months, would it?
Peter:
Really? I can’t believe that. If it was so simple, then they would have done that a long time ago instead of migrating.
Henk:
Sure, why not replace a core application that has costed several 100.000nds of development and testing hours in two months time. (Side note: a couple of Uniface competitors claim that migration to Uniface 10 takes the same effort as rewriting the application from scratch. Utter nonsense, but we’ll discuss our Uniface 10 migration experiences in an upcoming podcast)
Peter:
Haha, yes, I know those stories! I remember one case where such a competitor spent a couple of months with their advanced tooling and the only thing they accomplished was a duplication of the datamodel. I assume they could have taken that from the database schema in a couple of minutes… Hilarious!
Henk:
Yeah… 😊
So, where was I .. Ah yes, I then ran the scenario we had used for performance testing on an in house Windows server. Et voila, it worked like a breeze. So, if the performance of the separate components, i.e. the network, the database, the Uniface applications, was okay, what could it be? It had to be the latency caused by the distance between the application and the database. We were aware that it was a data intensive application, where lots of data were fetched from many tables, often behind the screens before something was shown to the user. Well, a long story short: we started experimenting with Uniface Anywhere and that solved our problems. It enabled us to start a Uniface Anywhere session in the hosted environment that actually started a Uniface session on the on-premise Windows server, close to the database. Performance had never been better for them 😊
Peter:
See, that’s great solution. Good old Uniface! Uniface Anywhere is truly a wonder product. I don’t understand why it is not used more often. It can solve so many problems.
Henk:
Exactly! Well, of course it brings an additional layer of infrastructure management, but despite that I think it’s really worth it. So, what is your contribution today?
Peter:
I was reminded again of a project from years ago, where we also experienced a performance drop. We found to cause of their issues and were able to fix it. Back then, it was not a cloud experience.
It was back in the days when cloud meant just clouds in the sky and the cloud was that single cloud blocking the sun.
In this particular case it was a database hosted on a dedicated on-premises server that was moved to a shared server in a datacenter abroad. So from on-prem to off-prem.
Maybe not really the cloud, but the problem is the same. Moving from on-premise to off-premise. Literally adding distance and a lot of network components between the users and the database.
And yeah, you might have guessed it, in this case the client also blamed Uniface. And I can understand, since the performance is experienced in the application. By the user!
So, it’s easy to point a finger at the application.
I have found and proven, in that particular case, that latency was causing the huge drop in performance.
Henk:
Tell us more! 😉
Peter:
Picture an application that processes thousands of record. Then every millisecond of latency starts to count.
And that is not rare. I mean, Uniface applications are often very data intensive. Processing a lot of data.
Henk:
That makes sense, because Uniface is sublime when working with large volumes of data. That shouldn’t be a problem.
Peter:
Yeah, that shouldn’t be a real problem.
But what if this occurs on a form that every user opens a couple of times a day.
A Uniface form that is processing thousands of records before showing anything to the user, than this number of records and the latency start to become a huge problem.
Henk:
Ah, I see where you are going!
Peter:
In the good old days, where the database and the user were literally a couple of meters apart, that number of records wasn’t such a problem. There was nearly no latency.
Now, there is literally so much more between a client, where the data is needed, and the database itself.
Things needed to make the physical connection. Things needed to make it secure.
So,
1. A increasing distance,
2. Meaning more hardware and
3. maybe even a lot of other software like firewall, logging- and scanningtools.
All is important. I do understand.
But, the result might lead to a higher latency, which is perceived as decreasing performance by the end user.
Let’s say, and these numbers are very realistic, the latency goes from 1 ms, when on-prem, to 9 ms in the cloud. Don’t be surprised, 9 ms sounds like very low, and for a Cloud solution it maybe is.
Now let’s return to that form that reads over a thousand records before showing anything.
You don’t need a calculator to calculate 1000 times 9ms.
Henk:
Users don’t want to wait for 9 seconds for a form to show. No wonder they complained about the performance.
So, were you able to reduce the latency?
Peter:
Of course, we questioned the gigantic increase in latency and why nobody asked questions about it. I mean, this calculation is no rocket science.
It turned out that no system administrator had looked at latency. Indeed, it was not in any requirement, let alone in a project plan.
They could reduce the latency to 7 ms. Still too high to be a solution.
Henk:
Uniface Anywhere?
Peter:
Haha, yeah, I didn’t think about that in those days.
You know. I believe in the philosophy of the Stoics. Those say don’t focus on things you have no control over. Instead, focus your energy on the things you can influence. They also say that you should accept the things you can’t control.
We had to accept the latency being too high. The client asked us to investigate the software they had build over the years.
Of course, the developer of these components does not go without blame either. This is, of course, another case of bad-coding. It turned out that much more data was being read than strictly necessary. But that is something we could fix!
In the end, we modified just a few forms so that the read only a fraction of the data. Instead of going to the database 1,000 times, we were able to reduce it to about 10. The form was now on the screen within half a second.
Henk:
How long did it take to find the cause and the fix?
Peter:
It took us a few hours to find the latency to be the cause of the issue. Than it took weeks to get the latency reduced by ‘just’ 2ms. Most of the time was lost to escalations and the like. Organisation stuff.
Fixing the bad coded forms took a few days.
It is not entirely fair to call it ‘bad coding’. You have to look at everything in its time. Something that works well now may not work well in the future. Therefore, if circumstances change, you might have to adjust the code.
Henk:
So, there are several strategies to follow here:
1. Accept the change in distance and if you don’t want to change your application, Uniface anywhere might be a solution.
2. Look at the latency! Try to reduce it as much as you can.
3. Look for the quick wins in the application.
Peter:
Yes, that’s the lesson we learned today 😉
No seriously, isn’t it a bit naïve to expect an older application to perform well under changing conditions? In most cases we are talking about Uniface applications that were written in previous versions of Uniface.
Henk:
Organizations should keep their software up to date. Just like they do with their security, hardware and architecture. I mean modernizing the Uniface code. Think of things like code review when delivering changes and even periodic refactoring.
Peter:
Especially if circumstances change.
And not only due to changes in the environment. What about an upgrade to Uniface 10? There are quite a lot organizations that upgraded already. But still there are a few that may need help with their upgrade.
Henk:
Yeah, I can talk hours about that subject.
Peter en Henk:
Hierover een beetje kletsen….
(Start heel zacht de eindtune ….)
Henk:
Did you think about the guests for the podcast?
Peter:
Yes, I have a list with a few names. Do we mention them here in the podcast or do we ask them first. I mean, it might not be very polite to mention a name here.
Henk:
I agree. It also makes me think. We can’t use names of our clients. Can we use the real life examples from our work with our clients? Or is that not allowed because of NDA’s?
Peter:
We have to be careful and try to avoid that content on our podcast can be linked to a customer. Unless we have explicit permission from them.
Henk:
Therefore, let’s also try to involve our customers in the podcast. Let’s add a few of them to our list of potential guests!
Peter:
I totally agree. After the recording, let’s go through the list again and approach the first guest. I am a very bad interviewer though. So we have to come up with some clever questions.
Henk:
And asking our listeners to share their Uniface experiences and issues with us.
Peter:
That sounds like a plan, Henk.
Let’s talk in de next episode about upgrading to Uniface 10. That will give us some time to work on arrange things with guests…
Peter:
Thanks for listening to this episode of the Unicast podcast.
If you have any questions about the podcast or an interesting topic about Uniface that we can cover in one of the next episodes, please let us know. You can find our contact details on our website: unividuals.com.
Henk:
What was that thing you wanted to share with me?
Peter:
Oh that, no, it’s nothing. You don’t want to know…
Henk:
Oh, come on…
Peter:
Okay, so one said we are like those old men from The Muppet show. Statler and Waldorf.
Henk:
O…
Peter:
Told you, you didn’t want to know…
Henk:
Statler and Waldorf…
Who told you that…
Peter:
Jan. Jan Hengeveld
Henk:
We should invite him.
I think we need a Kermit.. Or better even: a Miss Piggy – she will handle him …
