Serious question: can someone describe to me or point me to a blog post about what 'edge' computing can do? I am having a hard time understanding what the difference is between it and 'normal' cloud infra where end-clients call to a central cloud service. In other words, what is the architectural difference between Snapchat, where many end devices have a thick-client connection to a central service, and 'edge' computing?
There's really 2 things that you get. The first is that by having servers close to clients you can minimize latency, and you get scalability for free. The big architectural difference is that generally read/write databases become extremely challenging so you either have to get into some crazy CAP territory OR you architect around essentially event sourcing/logging. It works great for some applications, terrible for others.
You request static assets from a CDN and your request hits a "lambda" function on the edge. It inspects your user agent and decides to send you mobile-optimized assets.
It's largely about latencies. Doing certain request(and response!) processing closer to the client, along with potential data locality benefits, you can get responses back faster and more efficiently.
I was about to implement 'Edge Servers' for my MMO game system. However, in that context, those have commonly been other cloud instances running somewhere like AWS, which act as an intermediary to the client. My own 'Edge Servers' would maintain Websocket and WebRTC connections, and perhaps authoritatively implement a 'Player State' state machine. They would have a security function somewhat like a firewall ro reduce attack surface, though they wouldn't replace a firewall, but rather work in conjunction with one and behind one.
The OpenEdge seems to be more of a traditional 'Edge' server for static assets, but combined with a lambda. I wonder if this concept could be extended for something like my 'Edge Servers' which require more stateful operation? Can stateful cloud assets be given more advantageous network placement, like other 'Edge' servers?
Hopefully it drowns out google results for OpenEdge ABL, formerly known as Progress. Awful 4GL programming language/database (don't ask me how I know).
I too have labored in the hell that is 4gl Progress development. I did it long enough that I wrote a Progress-to-MariaDB replication daemon. That made it possible to actually get insightful reporting out of the mess that was the ERP system's database.
I've programmed in Progress for about 4 years (2006-2010). The language itself is far from awful. It's actually a well thought and easy to learn language. Everything not obvious in it is well documented.
What I didn't like about it was its very proprietary nature: closed source, its lack of libraries (no json parsing library back then IIRC), you'd have to pay even for its VM.
TBH, I found it more difficult to master Perl than Progress, but the effort was worth it.
It's largely about latencies. Doing certain request(and response!) processing closer to the client, along with potential data locality benefits, you can get responses back faster and more efficiently.
If your clients are really thin on resources you can use edge server for rendering, converting your client-side rendering back to server-side. More usecases on https://aws.amazon.com/blogs/networking-and-content-delivery...
The OpenEdge seems to be more of a traditional 'Edge' server for static assets, but combined with a lambda. I wonder if this concept could be extended for something like my 'Edge Servers' which require more stateful operation? Can stateful cloud assets be given more advantageous network placement, like other 'Edge' servers?
progress replication toolkit: https://github.com/hgrubbs/proreptk_community
What I didn't like about it was its very proprietary nature: closed source, its lack of libraries (no json parsing library back then IIRC), you'd have to pay even for its VM.
TBH, I found it more difficult to master Perl than Progress, but the effort was worth it.