The term "serverless" really caught on around November 2014. That was when AWS introduced it's Lambda service. The lambda service is a "function as a service" offering meaning that a function (small unit of code) will be ran in response to some event. A user can input code into the browser window and that code will be executed when the event happens. The event could be a log message, an API call, or whatever else a developer imagines.
Haters of the term may say: "It's just buzzword belching" there is something deeper here that is worth understanding. Serverless has far reaching implications as to how applications is crafted now and in the future.
Yes, servers are still needed. These function-as-a-service plays like AWS lambda, Google Cloud Functions, Azure Functions, IBM's OpenWisk, and others run on containers that require an operating system and necessary libraries like any modern application. But they are "serverless" in that the end user doesn't have a server view of the infrastructure. To the end user, serverless is just an execution environment, where the operating system is not relevant and lives behind the service itself.
To be clear, function-as-a-service is only one component of a serverless architecture. Serverless could be viewed also as a model that comprises 3 other important aspects:
- The end user doesn't fuss about infrastructure (should we call it infrastructureless?
) - The pricing model is charged per transaction instead of by the hour (hourless billing!
) - Ability to call other APIs to run the application (api-full system!
)
SaaS for Developers
The world of software is in a continuous march towards greater abstraction under the holy banner of efficiency. This is evident in the salient features of popular programming languages that have emerged over time. Java has garbage collection freeing us from "malloc" and other necessary low level operations. Python gives us dynamic typing where a variable can be an integer or a string or whatever we assign to it on the fly. And Go has made it easier for us to run concurrent operations with simple go routines.
This march towards abstraction rolls on in the infrastructure world as well. Operating systems were designed to abstract the bare metal and enable multi-tasking. Virtual machines solved the issues of driving more efficiency from the hardware and simplifying maintenance. Containers now give us the ability to strip down our operating systems to the barest of requirements and port to whatever environment we fancy.
But this grand pleasure dome of abstraction that infrastructure has given us over these years has never been the end goal. It's always been a means to deliver applications. If I, as an application developer, could abstract the operating system away entirely and just drop code in some ready to run environment I would! And that's what serverless gives us.
As you read this article right now, you might be aware that it is running on some blogging software. You don't really care what operating system the software runs on since you never interface with it. Windows? Linux? OS/2? Doesn't matter to you. You also don't care if this blog software is running on a container, a virtual machine, bare metal, or even a dead porcupine.
As much as Software as a service (SaaS) applications like Facebook, Cisco Spark, and Google Docs offer great convenience and bliss for users running apps in a web browser, Serverless is SaaS for developers and provides many of the same benefits: Nothing to install, just a usable environment.
1. The developer doesn't have to install any virtual machines.
2. The developer does no maintenance.
3. The developer doesn't worry about autoscaling and load.
These services are worth paying for. They make it so developers can concentrate on adding features to the applications that end users can see. They make it so we don't have to fuss about creating infrastructure. Yes, rock solid infrastructure is important but the end user of our application will not notice it at all and doesn't care, unless it sucks.
Pricing per Transaction
The economic benefits of serverless are positive for both the supplier and the consumer of the service. For the end user, serverless technology is priced based on transactions or how many times it is used. This means we're not paying for idle VMs that are up just in case somebody hits our website at 3AM in the morning.
A coworker at Cisco showed us how he ran his application for ~$5 a month simply using serverless technologies. Since his website didn't generate a ton of traffic, it didn't hit the super high thresholds so he paid very little per month for an always on service. If he had instead used an IaaS then his bill would have been ~$100/month minimum.
For suppliers of cloud services, serverless technology is an opportunity to free up hardware resources. Renting out all those idle VMs per hour starts to cost money and makes it so the IaaS provider has to invest in more servers that will also sit at < 40% utilization.
The economics of serverless give the trend even more momentum and show another reason why the future of cloud services and development will continue down this path.
API Economy
Application developers have long used 3rd party open source libraries and frameworks to write code faster. For iOS developers using something like AlamoFire is almost a given. A Python developer may use Flask, and a Java developer may use jUnit to do unit testing. With the trend towards microservices, we're also seeing that many undifferentiated functions of an application are being provided by others who specialize in that microservice. It's now not just 3rd party libraries we put in our applications: It's 3rd party services.
For example, instead of wanting to create your own user authentication service and database for your new photo sharing app you're creating, you could instead use a service like Auth0 as part of an application. Auth0 provides all the user management, provides roles, and make the whole headache of learning a library go away. Since applications are now developed as a mesh of microservices, what difference does it make if some of those microservices are provided by one of our internal development organization or a third party?
What could go wrong?
So now it has been shown that the world of serverless is upon us and all our current architectures are dead or will soon meet an ill fate. Right? Well, not exactly. There are still some issues in the serverless world that give people pause for concern. Some of these include:
Visibility
It's hard to understand how to see what the performance is with your application. When there are many different functions running around how do you get a handle on the entire system? The vendors of these systems have created several tools but the concept of getting a handle around the entire application isn't so easy anymore.
Version Control
How do you know which version of the code you're running on? Do you have to re-version your lambda functions? How do you test for backwards compatibility? Solutions are starting to evolve, but still not very main stream.
CI/CD Integration
How do you integrate it into your pipeline? We've seen some interesting projects like lambda CI that tries to take this on, but like many solutions are early and may be inadequate for enterprise environments.
Vendor Lockin
Most of the vendors advocate serverless strategies that bind a consumer to one cloud. There are some projects like ones sponsored by iron.io that try to make it cloud agnostic.
Hybrid Cloud
When you have multiple data centers and try to stitch services through them the architectures for this may be left wanting.
Onward with Serverless!
As more organizations have adopted serverless thinking, open source frameworks such as "serverless" (previously called JAWS) have started popping up and supporting more than just one serverless provider. This year we have also seen the first Serverless Conferences.
The truth is, most organizations want the benefits of a private cloud or their own stack for running container stacks but lack the expertise to do so. Serverless is about making the headache of managing operating systems (whether they be in VMs or containers) go away.
Serverless can also be seen as an evolution of many of the backend services that started popping up around 2011. Back then when iPhone and mobile development was really taking off, people needed a backend cloud place for their applications. Learning to manage a database or spin up a virtual machine were just extra headaches to do when you could use a service like Parse.com (purchased by facebook, then decommissioned at the beginning of this year), Firebase (purchased by Google), Backand and others.
Your Cloud Strategy and the future
A successful cloud strategy must include if not be driven by trends in software development. Several trends have been talked about in this article such as greater abstraction, microservices, and the use of 3rd party APIs for accelerating application development. Any company that wishes to offer cloud services should have a well thought out vision of where software development is, where it can go, and what can be made possible by the offerings. When organization has separate visions for development teams and infrastructure teams harmony flees.
There are two other emerging trends in computer programming that are worth noting. As both of these become more focused serverless will become even more mainstream. They are:
1. Functional Programming
2. Machine Learning
Functional programming is more popular now due to the nature of distributed systems, cloud computing, and faster performance of modern servers. Having many "pure functions" or functions that take in and output data without changing state and without side effects are required more as many concurrent calls happen within an application. As more distributed application patterns arise, this will be especially important. And Guess what? That's what lambda functions are: Stateless functions that can be scaled and called and produce the same results for a given input. Functional programming is also called Data Derived programming because the data drives the direction of the code. You may have heard more about more functional languages lately. They go by names like: Clojure, Erlang, Haskell, etc.
One of the first functional programming language that emerged in the 1958 was LISP. LISP found a lot of enthusiasm with Artificial Intelligence programmers due to its simplicity and symbol handling. It is quite interesting that the other big trend in machine learning (a type of AI) is making its way into software development. Some predict our machines will be coding themselves in the not too distant future. They already are!
Imagine a future serverless, infrastructureless world with hourless billing and APIs everywhere with machines writing in functional code.
Where do we go now?
So now you may be asking yourself as Axl Rose did when speaking of his sweet child: "Where do we go now?" There are pros, cons, tradeoffs, delusions, and victories to be had along the road. The serverless market may still be young but it's disadvantages are not enough to detour the huge benefits an organization can reap from them: little-ops (not quite no-ops and not significant enough to be dev-ops), huge cost savings, and little infrastructure overhead.
The evidence for a future serverless, infrastructureless world with hourless billing, APIs everywhere with machines writing in functional code is not imaginary science fiction. It is instead is a scenic marker along the pathway we're already headed down: A natural evolution of cloud services and software development practices.
1 Comment