We launched Functions in late 2016, driven by our customers’ needs for easily developing and scaling large-scale, real-time software. Our low-latency messaging got messages quickly from sender to receivers, but often, people needed to route, filter, aggregate, transform or augment the messages in-flight. Functions provided an easy way to do that, and it got quick adoption in a myriad of use cases, from IoT to gaming, financial services to social.
When we launched this new offering, we struggled with how to name it. Software architecture across the board is changing, and as usual, there’s a barrel of buzzwords surrounding these trends, including serverless, microservices, FaaS, Lambda, containers, Docker, event-driven development, to name a few. To the folks leading these trends, it all makes sense. For most developers, it’s a mess of misunderstanding and confusion that’s actually slowing down the adoption of these new design patterns.
I gave a talk about this September of last year at API World Conference in a talk called Everything you Wanted to Know about Serverless but Were Afraid to Ask. The PDF is downloadable here: PubNub — API World Serverless. The discussion about Microservices, Functions, Serverless, etc. starts on slide 26.
Dan Rossanova from Microsoft (product manager for the new Azure Event Grid service) joined me on stage; luckily we see eye-to-eye on how to think about categorizing things, so we were able to build a presentation that helped muddle through the confusion.
Docker drove a huge movement toward containerization, and the idea of microservice-based software design. Martin Fowler and other guest posters on his blog do a good job of describing the benefits, pitfalls, and trends towards loosely-coupled design patterns for software.
Over 90% of the Fortune 500 IT departments are now using Docker and containers, and/or actively moving towards them. However, for all the promise of moving away from monolithic software (i.e. 3-tiered LAMP/MEAN stack & similar designs), most containers today are being used to simply wrap existing software and use it as a handoff point between Dev and Ops.
While that’s valuable (including here at PubNub, that’s how our Admin Dashboard is now deployed), it’s not (yet) driving a revolution in new design patterns for software development.
I think that’s because wrapping existing software is easy…learning completely new ways to build software is really hard. When the web exploded, it took 10 years for developers to unlearn client/server design patterns and invent/adopt 3-tiered LAMP patterns.
Most Microservices/Container discussions revolve around software you operate yourself. “Serverless”, however, refers to software modules that someone else operates. There’s only one problem with that term: Developers hate the term “Serverless”.
Previously, the terms mBaaS (mobile Backend-as-a-Service), BaaS, and more recently, FaaS (Functions-as-a-Service), are being used too. Serverless/BaaS/FaaS refer to services (like AWS, Azure, PubNub, etc.) that will run your code on their servers, handling the deployment and scalability for you.
Developers much prefer FaaS, while analysts and the press seem to stick with Serverless as a term. And, in case you track these things, Google Trends shows “Serverless” beating FaaS over the past 12 months (see below). That said, I hate “Serverless” as a term too. FaaS is tangible. Serverless is at best inaccurate, and definitely not self-descriptive.
Each of the FaaS sub-categories above have different value propositions:
Microsoft’s Event Grid is a great example of making existing infrastructure “programmable.” Event Grid overlays all the Microsoft Azure services, so when various “events” happen (like someone uploading a file to their storage system, writing to their DB, etc.) an arbitrary bit of business logic can run in an Azure Function.
The demo Microsoft built with Event Grid and PubNub was pretty cool. When someone uploaded an image to their storage system, it would trigger a call to a Function that alerted every end-user that a new image was available, along with a tag describing the image (cat, dog, pool, etc). Users could subscribe only to the tags they cared about, and get real-time streams of images appearing on their phone. So in a few lines of code, Microsoft created a simple real-time Instagram.
There’s a reason so many buzzwords are thrown around. Innovative, new technologies are being built to solve challenging issues in the world of software and hardware development, and we need more detailed ways to describe them. I hope this post helped clear up the differences between the many new terms being introduced and gives you guidance on what technologies to use to solve your challenges.
There are common underlying technologies for a dating app, and in this post, we’ll talk about the major technologies and designs...