Not What You Think It Is – InApps 2022

If you’re anything like me, you’ve seen the word “serverless” around for a while and just sort of let pass by, undefined and enigmatic. Maybe after a while, you opened some blog post about serverless full of marketing jargon, before finally deciding to dig in and find out what “serverless” was really all about. Spoiler alert, there are indeed still servers involved, you just don’t need to provision and manage them, and they’re not always active.

It’s weird that we use words like this, isn’t it?

Serverless. Hacking. Coding.

Before we return to the idea of serverless and an interesting take on where it’s lacking and how it can move forward, let’s dive just a little deeper on this niche idea of the nomenclature and language of programming — or as one blogger puts it, “Software’s Code Problem.”

“When we discuss the technologies that permeate our lives, we talk about software applications — apps — and the devices we use to run them. Apps are present, familiar, and relatable,” writes RJ Zaworski. “But a strange asymmetry emerges when we talk about how apps are created. Suddenly, the step-by-step instructions within a software application become code. In a clever linguistic flourish we detach a familiar end product (‘our apps’) from an arcane production process (‘their code’), showering unnecessary mystery on what ought to be a rather mundane project.”

With language, he points out, we set expectations and boundaries. Suddenly “programming” — those “step-by-step” instructions — becomes “code,” something more fuzzy and elusive than its intrinsically logical nature would dictate. Meanwhile, we have “serverless,” which is sort of anything but, and has a bit of an identity crisis with its debatedly alternative nomenclature, “function-as-a-service.” To this end, I think we just got tired of more “as-a-service” titles, and decided “serverless” sounded sexier.

Adrian Coyler takes up the topic of serverless this week, examining an academic paper (as he does daily) put out last month, entitled “Serverless computing: one step forward, two steps back,” noting right off the bat that “Serverless as a term has been broadly co-opted of late (‘the notion is vague enough to allow optimists to project any number of possible broad interpretations on what it might mean’)” and that in this particular paper, it is defined as “FaaS (Functions-as-a-Service), in the spirit of the offerings that the major cloud vendors are currently promoting.”

I thought the topic of language-related enough to bring up, as Coyler also comments briefly and in a pun-ish fashion again on the terminology, titling the next subsection of his article “Limitations: putting the ‘less’ in serverless.” Here, in fact, it could almost be argued that “serverless” is more direct and appropriate a terminology for the current state of the technology, as it points explicitly to the lack of a static server and the common programmatic benefits that we may forget come with it, such as hardware acceleration (through GPUs for example), network accessibility, and unlimited lifetimes. While serverless boasts that it only charges you for the time your functions are running, their limited lifecycles and need to communicate through intermediary services can end up costing you more in the end for certain use cases, essentially nullifying the whole point.

Suddenly that agility and buoyancy suggested by the terminology seems to weigh “serverless” down, doesn’t it? Perhaps “function-as-a-service” might better suit the technology at hand, pointing not to company’s abstracting a technology to make it easier to use, but rather acknowledging the beneficial use cases, of which Croyler points to several. There are use cases of good and bad, and the true point of the paper is to highlight both to find a better way forward.

Words aside, Croyler lays out several use cases that “fall into the ‘we tried to fix some screws with a hammer and it didn’t work out too well’ bucket,” and looks at the characteristics that a “truly programmable environment for the cloud” (skipping the FaaS vs. serverless debate entirely) would need. These include fluid code and data placement, heterogeneous hardware support, long-running, addressable virtual agents, and disorderly (non-procedural) programming, among others. Croyler concludes his article, as will we, with an apropos quote from the paper:

“Taken together, these challenges seem both interesting and surmountable… We are optimistic that research can open the cloud’s full potential to programmers. Whether we call the new results ‘serverless computing’ or something else, the future is fluid.”

This Week in Programming

• Android Studio 3.3 Arrives: First up this week, some far less ethereal news from Google about Android Studio 3.3, the latest stable release that is “focused on refinement and quality.” Google writes that they “have taken a step back from large features to focus on our quality fundamentals […] to ensure Android Studio continues to help you stay productive in making great apps for Android,” by fixing more than 200 user-reported bugs and adding some other core features. All of it is part of an effort dubbed “Project Marble” and ProgrammableWeb offers a succinct synopsis of the latest release, writing that “Google tackled four main pillars: develop, build, test, optimize.” Of note, Google offered updates to the IntelliJ 2018.2.2 Platform, Kotlin 1.3.11, and New Project Wizard, and introduced the “navigation editor” that was originally previewed in Android Studio 3.2.

• TensorFlow 2.0 is Nearly Ready to Go: The team behind your favorite open source machine learning framework TensorFlow laid out what’s coming in TensorFlow 2.0 in a blog post this week, saying the next big release will “focus on simplicity and ease of use.” The release can be boiled down to four basic points, which include easy model building with Keras, robust model deployment in production on any platform, powerful experimentation for research, and simplifying the API by cleaning up deprecated APIs and reducing duplication. Keras is set to become “the central high-level API used to build and train models” and TensorFlow 2.0 looks to improve “compatibility and parity across platforms and components by standardizing exchange formats and aligning APIs.” The release will also increase language support for additional languages, including C, Java, Go, C#, Rust, Julia, R, and others. The post also details the framework’s efforts “to clean up and modularize the platform based on semantic versioning.” Beyond all of this, “there will be a conversion tool which updates TensorFlow 1.x Python code to use TensorFlow 2.0 compatible APIs, or flags cases where code cannot be converted automatically.”
• Ready, Set, Code…err, Program! For you competitive programmers out there, it’s a new year and several hackathons and such have just been announced. So, if you want to get in on the game, deadlines loom. First, GitLab announced its Q1’2019 GitLab Hackathon, which will take place on February 12-13 as a “virtual event where community members get together to work on merge requests (MRs) and also to welcome and help new contributors.” Pay attention to the Hackathon landing page for announcements and details. Next, Google has announced two upcoming competitions. First, the deadline to apply for the Google AI Impact Challenge, “a call for organizations to use AI to help address social, humanitarian and environmental problems”, is approaching quickly — Jan. 22 at 11:59:59 PST, to be exact. So apply quickly if you want to take part and see if you can get a piece of the $25 million in funds Google is handing out to winners. Finally, Google also announced Hash Code, the company’s “team programming competition.” Registration is open and due by Feb. 25. The competition “kicks off with the Online Qualification Round on Thursday, Feb. 28. Top teams from this round will be invited to Google Ireland in April to compete for cash prizes and the title of Hash Code 2019 Champion.”
• Google Schedules 64-Bit App Transition: Android app developers, pay attention, because Google has laid out its schedule for the transition to 64-Bit apps. ProgrammableWeb combs through all the details, but suffice to say that if you want to keep distributing your app via the Play Store, you’ll need to keep a few dates and details in mind. “Beginning Aug. 1, 2019, Google says all new apps and app updates that contain native Android code are required to include both 64-bit and 32-bit versions in order to reach the Play Store. An exception is being made for 32-bit upgrades to existing games that are based on version 5.6 of the Unity Engine. This exception will remain in place until August 2021,” they write, noting that Aug. 1, 2021 will be the final cut-off date for apps only published in 32-bit. Read on for device exceptions and the like.
• Google Cloud “Gets Go-ing with Cloud Functions”: One final bit of developer news for the week, Google has announced that developers can get Go-ing with Cloud Functions: Go 1.11 is now a supported language.” The company released Node.js and Python as supported languages for Google Cloud Functions last summer and have been working on adding Go ever since. The time has come, with support being announced in beta for “the latest version, Go 1.11, which includes new language features like modules for integrating third-party dependencies into your code.”

• One More Time, With Gusto — Recursion: “How to solve a problem by pretending you already have” — that’s one of the most interesting ways I’ve heard recursion discussed and I find this blog post on the topic, which has been discussed unendingly, interesting and useful. I especially enjoy the animated gifs that illustrate the topic, so if recursion still lends itself to confusion for you, give the post a gander.

Feature image by Wouter Meijering on Unsplash.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Bit.