Akka Serverless - The Future of Software, Part 2

You Were Saying?

When last we met, Dear Reader, I was leading into why I think Akka Serverless is the future of software, at least any software built to run in the cloud, by giving you a little of my back story. Today I'm going to talk about the foundations upon which Akka Serverless is built. To do that, I have to present a few...

Definitions

reactive adjective

re·​ac·​tive | \ rē-ˈak-tiv  \

Definition of reactive

1 : of, relating to, or marked by reaction or reactance

2  a : readily responsive to a stimulus

    b : occurring as a result of stress or emotional upset

reactive depression

manifesto noun

man·​i·​fes·​to | \ ˌma-nə-ˈfe-(ˌ)stō  \

plural manifestos or manifestoes

Essential Meaning of manifesto

: a written statement that describes the policies, goals, and opinions of a person or group

The group's manifesto focused on helping the poor and stopping violence.

a political party's manifesto

The Reactive Manifesto document

Value Proposition of The Reactive Manifesto

: In today's distributed compute environment, where services rely on other services, we are building systems which rely on unreliable partners. Even in the best conditions where everything is built correctly, outages happen. Steps must be taken to deal with outages with the greatest of integrity and availability, Certain patterns have emerged that enables this in a fashion that is also easy to reason over as it models the interactions we have on a human level with each other.

Ok, Class. Your Reading Assignment Is...

I really highly recommend you scooch on over to The Reactive Manifesto, and the more thorough treatise, The Reactive Principles, and then come back here. Go on. I'll wait.

Hmm.... I'm betting you didn't go or, like me, you now have 2 more browser tabs open in your endless array. I'll see if I can do a TL;DR version here.

First off, the ideas around the Reactive Principles aren't new. The Reactive Manifesto was something I tripped over in my design pattern studies back in the 20-teens. Jonas Bonér, Dave Farley, Roland Kuhn, and Martin Thompson had collaborated to bring together the ideas around 2014 but the concepts preceded them by decades. They just hadn't come to be something we business application developers really needed to know (despite how much I wanted my peers and managers to think it was necessary). Then came The Cloud.

Suddenly, in my circles anyway, everyone wanted to put their .NET applications up in Azure. Yet, no one was building applications to run effectively in Azure -- even inside Microsoft. I don't mean any slight to the engineers I was working with. It's simply that most folks weren't so forward looking, or were not as exposed to distributed computing, as Jonas, et al, were.

K.I.S.S.S.

First, I have to say that I'm standing on the shoulders of giants, here. Further, if I can't describe something simply, I probably don't understand what I'm talking about. So, when I suggest that I'm going to Keep It Simple, it's so that my Silly Self can actually explain it. And, honestly, this software design pattern is extremely simple, conceptually speaking. 

In a distributed system, which aptly describes all aspects of The Cloud, things you have absolutely no control over break. However, that's no excuse to let the end-user suffer, either catastrophically or silently. With a minimum of 3 core concepts, you reach the 4th needed to be a Reactive System, which is always responsive software. 

Responsiveness is simply defined as always responding in a timely manner if at all possible. As noted above, that means you need your system to be resilient to failure. 

You also need to have your system responsive under varying loads.  You could over-prepare, something many corporations did in their own data-centers regularly, by running a system, understanding what it takes to run it, combine that with trends from the past, and then building out infrastructure to match the highest load, plus a little for growth. Unfortunately, that often means inactive servers just so you don't hit a critical tipping point that crashes your application. When building for The Cloud, though, you can think more elastically, right-sizing your resources so that they're not too big, not too small, scaled up or down just in time to be just right.

Parenting as a Software Analogue

None of that is possible, though, without the fundamental underpinning of being message-driven. If you work from a task list, an email inbox, a ticketing system, etc., you, Dear Reader, are message-driven. However, most developers are used to thinking about method calls. Whether because they're writing object-oriented code making internal calls or making web API calls, these have an inherent flaw any parent with a young child knows. You have to wait and monitor for the expected result, handling exceptions as they arise. It ties up the code, like that parent, until that operation is complete before another can occur. Even the exceptionally brilliant parent, skilled at multitasking, will run out of threads if they are often checking on, responding to, or redirecting the efforts of their child. 

The answer to all this is to introduce asynchrony. That brings me back to your task list. As a kid, you may have had a chores list. That allowed you to do your chores, unsupervised, and let your parent check on the status of your efforts when they had the bandwidth. They still may have had to take corrective action but they have achieved a higher level of productivity. 

Missed It By *That* Much

With both software and kids, this takes some maturity but by the time I was maturing from a naïve coder to a software engineer, the .NET Framework had matured to introduce the Task Parallel Library giving us Async/Await in v4.5, released in 2012. While Java's Futures preceded that by quite some time, CompletableFutures in Java 8 showed up in 2014. Until then, there were a lot of shortcomings that made truly asynchronous programming difficult. There are also some distinct differences, notably around thread use, between how .NET and Java got the job done but they both have the same flaw. They both still, inevitably, await the result of the call. 

Because it is possible to have a call never return, it is possible to have an unresponsive application even when built using asynchronous patterns. Ever been that parent (or the child here) who, all else done, just can't get their kid to pick up their toys? Yeah, that. You either have some timeout and error-handling (pick up the toys yourself, perhaps) or you both pass out before the battle of wills resolves.

There is another step in maturity needed, which brings me back to being message-driven. I took a lot of time to get to that because it is a simple, but profound paradigm shift. However, it is one that should be very familiar to you.

Stay Tuned

Did I say TL;DR version? If you're new here, you've now learned what those who know me already knew. "Long" is my middle name. This has gotten long, though still a lot shorter than either of the two sites on defining Reactive systems. So, I will pick up on my next post with what being message-driven means and how an old pattern became new again.

Akka Serverless - The Future of Software, Part 1

Some History (Mine)

For those just joining the game, you might peruse my posts and see that I have dabbled as a software developer/engineer in multiple languages. I got my start with BASIC back when Saint Jobs was working closely with The Woz to bring us the Apple II. I moved onto Fortran, failed to understand pointers with Pascal, helped build some stuff with VisualBasic, built production code with C#, came to understand pointers and data structures with C++, learned a bit of Java, enjoyed data munging with Python, and finally matured to the Software Engineer (SWE) title building enterprise services with C#. Then, wanting to see what life as a SWE was like outside of Microsoft, I returned to Java and, well, hated it. 

The tooling I had to use, IntelliJ IDEA, wasn't as familiar, thus not as good to me, as Visual Studio. It wasn't bad, and better than Eclipse, just really unfamiliar. The ways to handle asynchronous communication in Java were much harder to reason about, for me, than with C#. There was more need with Java to concern myself about threads than there had been for C#. The libraries were all foreign to me so I felt like a burden on my team although I'd already gained the Senior title. I understood architecture and patterns but I just didn't know the tools I was given.

My first professional foray into Java had two big things going for it, though. I had a great team who never made me feel like a burden and actually showed that they valued my expertise. It was great to work with a truly inclusive team. The other thing going for it was that they'd selected a toolbox that alleviated my difficulties with reasoning about asynchrony and dealing with threads. That toolbox was from a small, open source company named Lightbend and the primary tool was Akka Platform.

Calamity Strikes

Unfortunately, roughly 3 months after joining that team, the company decided they would shutter the offices here in the PNW. It was calamitous in that I was really enjoying working with these folks, the project we were collaborating on, and I was getting the hang of the tools, language, and loving Akka.

Fortunately, I was welcomed back to Microsoft and got to work on a notable team building services underpinning all of Microsoft Store. My responsibilities were notable and the work was impactful. The team was not inclusive, though, and I really missed that. While there were some senior members of the team who were always approachable and helpful, others made a habit of being the opposite. Further, some of the younger folks, around the same age as my last teammates (I'm a young grandpa, for what it's worth), were expressly dismissive and exclusive in their interactions.

Good Things Come

Thing is, I'm really not hard to get along with and that role prior to my return to Microsoft, the one that went sideways 3 months in, resulted in some friendships, too. A few of the folks I had worked with landed roles at another company in the area and, while I was working back at Microsoft, they were building trust in their management. That trust resulted in the opening of a role for me to join them a year after I'd rejoined Microsoft. And to add to my luck, they were building services for their SAAS product using Akka!

I was building a multi-tenant, streaming service leveraging Kafka using Akka Streams Alpakka. It was comprised of 3 microservices, each able to scale independently to handle the processing load as we moved customers from the overburdened, individual software instances onto this leaner, scalable solution. The scaling and resiliency were enabled via Akka Clustering as the docker images were running in Kubernetes in AWS using Akka Discovery's K8s API. It was a great opportunity to both dive deep into multiple technologies while mentoring a team of folks, most of whom this would be their first experience with most of it.

Hello, Is It (Really) Me You're Looking For?

Have you heard this one? "Knock, knock." "Who's there?" "Lightbend." "Lightbend? No way!"

I was shocked to hear it myself. Here I'd found myself being really productive and actually enjoying Java despite my misgivings about it being less approachable than C#, all thanks to their flagship product Akka Platform. Lightbend is calling me to consider joining them as a Senior Solution Architect? It was true and that is what I did. 

As long-time readers of this blog will know, I had long ago discovered that I love learning and sharing what I learn. I had a real talent at communicating complex ideas at various levels and had started turning my journey from software development to mentoring and developer advocacy (DA), back before I got tapped to focus more on my craft and pivot to a Software Engineer role. (The differences between developer and SWE are hotly debated in the industry and a topic for a completely different post.) This blog was started to make the DA pivot only to languish as I focused on being a SWE.

However, as a Solution Architect/Technical Account Manager (my current title) at Lightbend, I get to turn my attention back to developer advocacy. Yay! As such, you should expect more of that kind of content to return (and less of the personal grousing about bad service).

Stay Tuned

With that in mind, I'm starting this new series on a service from Lightbend, currently in public beta, that I'm proud to be sharing with you. As the title of the article notes, that is Akka Serverless and I do believe it is the future of building software, at least the backends for highly connected, distributed, scalable, and resilient software. As always, I'm making this up on the fly so my plan is a little loose right now. However, for sure the next post will be a quick overview of the foundations that Akka Serverless is built upon, why they're important, and why Akka Serverless lets you stop worrying about them. You've heard of Platform as a Service, PAAS? I'll show you why I think of Akka Serverless as PAAS+, where the plus is that you don't have to worry about the complexities of actually leveraging the power of PAAS when building your truly cloud-first software, just your business domain and logic.

Oh! I almost forgot to mention that I also picked up a new language, thanks to Lightbend. I'm now building with Scala. I'll be using Scala in some of my demos as it reads almost like pseudocode. However, Akka Serverless supports a wide variety of programming languages, including full tutorials for Java and JavaScript. So, you never know what language I'll demo next.

As the heading says, stay tuned!