I’ve been into serverless technologies for a few years now. The thought of not having to care about what platform my code is executing on, or having to manage and operate it, resonated with my developer side that just wants to code. I also saw it as a possible catalyst for change in how we are developing applications using cloud provider services, one that allows services from multiple clouds to be pieced together to form a whole application…but more on that further down this blog!
Misleading Name…Awesome Developer Tech!
For the uninitiated, serverless technologies allow you to write code and then deploy it to a ’serverless service’. At which point, you can execute it whenever you like and get the result returned to you. You don’t care or need to know about any of the underlying infrastructure or platform that executes your code, it just happens. On top of that, you don’t have to worry about operational issues like scalability or redundancy either, as the ’serverless service’ deals with that, too! Now, of course, there areservers involved somewhere along the line, it’s just to you, the consumer of the service, it’s ‘serverless’ – you simply don’t have to care about them.
From a cost perspective, public serverless services can also be beneficial, as with public serverless services you tend only to pay tiny amounts for the length of time your code takes to execute or number of calls made. This definitely beats paying for an idle VM that might just be sitting there for hours in between executing your code. But, if you build some dodgy code with an infinite loop in it or that calls itself untold times, you can see cost add up quickly (a lesson I learnt when a bot I was writing decided to have an endless conversation with itself 😔).
You can see a few examples of public serverless services on a number of the big public cloud providers – for example, Google’s are here.
Going Private with Serverless
But, there are also serverless services that you can deploy in your private cloud / data center too, like OpenWhisk and OpenFaaS. From an IT Ops perspective, you have to deal with the underlying container platform and operate it with this model, but then they are free to use as much as you want and your consuming application developer fan club will love you for it…and of course you can use the service yourself!
It’s worth noting, you can’t really write the whole of your application in pieces of code that just return a result through one of these serverless services (also known as Function-as-a-Service – FaaS), you’ll be needing API Gateways, storage, identity services etc etc…but more on that in a future blog.
Serverless Applications – More than just the Function-as-a-Service (FaaS) calls!
Catalyst for easier cloud provider agnostic development?
What has been fantastic to see is all the open tooling and frameworks that are being built to support the community in development of serverless applications. It’s these frameworks that made me believe that cloud application development would span more than a single cloud provider eventually.
A fantastic example of such a framework is the somewhat confusingly named serverless. Using such frameworks means that it’s far easier to become cloud provider agnostic, deploying code to any of the supported cloud provider serverless offerings and using the other services on that cloud (DB, API Gateway, Storage etc.) as well as from others.
Application spanning private / public cloud provider services
Now, I hadn’t come across any real-world application that had been developed across clouds like this….until a recent trip to Mi-Idea at the Manchester Science Park in the UK. They have some fantastic start-ups developing some very exciting solutions. Falling into a conversation with one of the tech leads there, I discovered they were using a DB service from one provider, while other aspects were leveraged through another provider. Reasoning all came down to trade-offs of cost, performance and usability.
I got pretty excited. Sadly. I’m now actively looking for other applications built this way to understand if this is becoming much more common – applications being developed across multiple clouds and their individual services, using serverless patterns. If you’re reading this and think ‘yup – totally am’, then reach out – using serverless architectures or not! I’d love to hear from you. Drop me a comment on this blog.
Starting Your Serverless Journey – Free!
If you’d like to get started in the world of serverless, head over to DevNet and hit the Sandbox, where you’ll find an OpenFaaS Sandbox that will provide you a private serverless service, totally free for you to reserve and spin up. This sandbox is built on UCS, gives you a kubernetes cluster (check out the open source KuBaM if you want to deploy kubernetes on UCS in minutes, yourself) and it deploys OpenFaaS ready to go. We’ve also included some Hello World examples to get you started and give you your first taste.
As a sidenote:
You might also here the phrase ‘Function-as-a-Service’ (FaaS) if you decide the delve into the world of serverless. When in the community I find that talking ‘serverless’ relates to the design pattern you employ to build your application (‘I’m building a serverless web site’), while FaaS is the serverless service you might leverage to do that – for example Google’s Cloud Functions (‘I’m using Cloud Functions as the FaaS element of my serverless application’). In case you were wondering!
Published with permission from blogs.cisco.com