I have to level with you. Dealing with network programming in my applications has always freaked me out a little bit.

You know what I’m talking about, don’t you?

Let’s be real about it: low-level network programming is some scary shit. When you have to step beyond the nice client libraries that wrap the networking protocols, there are sharp edges that can gleefully poke you in the eye whenever you make the tiniest misstep in your code.

To put it lightly, low-level network programming has not been a very pleasant experience.

There’s Power Beyond The Pain

And yet… it’s CRAZY powerful. It’s the key to the kind of applications you want to be building in your future.

Want to create a serverless, peer-to-peer, multiplayer video game? Get ready to dive into the networking stack.

Want to build a realtime analytics system for a network of remote devices in the Internet of Things? Yeah, request/response ain’t gonna cut it.

What about creating a live trading or marketing automation system with single-digit-millisecond response times? Ciao, HTTP. It’s been fun while it lasted.

Most developers I know are THRILLED by the idea of working on applications like this. And yet for most, building applications like this seems out of reach. Somehow off the table.

WTF? What’s up with that?

An HTTP Too Far?

It’s actually very simple. The reason that bold ideas like this seem out of reach is because most of us have been conditioned to use HTTP for…wait for it…everything.

For the most part, we’re building our applications with a nicer version of the same approach to the problem that we relied on IN 1998. HTTP was designed to serve up static content, and we have pushed it far, far beyond it’s comfort zone.

So, here’s a question: what could happen to your apps (and your arc as a developer) if you weren’t bound to the HTTP request/response model anymore?

What if you went… beyond HTTP?

What’s likely to happen is that your apps become more responsive, more resilient, and you’re able to tackle new kinds of problems that you couldn’t take on before.

Trajectories

Your trajectory as a developer goes to a whole new level. You can create applications that used to be out of your reach.

Once you’re not bound to HTTP, all sorts of programming scenarios that weren’t possible are now on the table. Imagine building a realtime trading system, multiplayer video game, an streaming analytics system, or a marketing automation system? All of these require higher throughput than a request/response model AND statefulness, which HTTP flat out doesn’t give you as a stateless protocol.

That all sounds good. But what about all those sharp edges I was talking about earlier with low-level network programming? Won’t they (let’s be honest with each other) drive you back to an HTTP-based world?

Maybe. Or maybe not.

Scale Without Code Changes?

What if you got all the benefits of moving beyond HTTP, without having to write the low-level networking layer yourself? Even better, what if you could write your app locally and deploy it across a network of machines…without any code changes?

What? You mean it’s possible to use the power of low-level networking, but not have to deal with the grim realities of the network layer myself? And be able to seamlessly scale out my app?

That’d be pretty sweet, right?

Your New Best Friend

Yes, it would. And it’s already here. Meet your new best friend: Akka.Remote.

Akka.Remote is the most powerful module in the entire Akka.NET framework, and it’s the key to unlocking the distributed applications that are waiting for you to build. No BS. Once you’ve got Akka.Remote down, you can do anything.

Akka.Remote is what enables those two amazing benefits I mentioned earlier:

  1. Write your app locally and scale it across many machines, with virtually no code changes.
  2. Solve problems that HTTP can’t. Especially anything with streaming or realtime data, or any system you want to make truly reactive. No doubt, there is a learning curve to all this. Getting access to value that has been out of reach does take a stretch and some effort.

But you know what? There is something amazing in overcoming your barriers, in consciously stepping beyond what you already in order to discover new possibilities for yourself and your career.

Sounds pretty good, right?

If you like the sound of that, I invite you to take our course on mastering Akka.Remote.

Going Beyond HTTP

We’ll be writing about this topic—going beyond HTTP—a lot going forward. After all, it’s what we called this blog. So stay tuned—we’ll be making a lot of amazing information available for you.

What have you used Akka.Remote for already? Let us know how you’re using it and what questions you’d like us to cover by leaving a comment below.

If you liked this post, you can share it with your followers or follow us on Twitter!
Written by Andrew Skotzko on May 22, 2015

 

 

Observe and Monitor Your Akka.NET Applications with Phobos

Did you know that Phobos can automatically instrument your Akka.NET applications with OpenTelemetry?

Click here to learn more.