Serverless architecture is a newer design paradigm for application development as well as platform hosting. It is the natural evolution of SaaS, PaaS, and IaaS to fit the development space. The obvious question is how exactly does serverless architecture handle being “serverless”?
Serverless architecture isn’t actually serverless, but the the creation, maintenance, and culling of servers is completely transparent to the “user”. The server is abstracted to where the load-balancing, data migration, etc. or even the lowest level OS interaction is no longer a concern for the development and operations side of things. Someone else manages the infrastructure in its entirety and provides a nice way to interact with it.
How Does Serverless Architecture Work?
Serverless architecture is a form of XaaS. Instead of having one platform or environment like a standard SaaS or PaaS offering, we abstract everything to a functional level. Serverless architecture is also known as Function as a Service (FaaS). FaaS addresses individual functional units of computing rather than thinking in terms of software, platforms, infrastructure, or any other common unit. But, like SaaS, PaaS, or IaaS, there can be a bit of fuzziness between the delineations of where one of these definitions ends and the other begins.
Platform as a Service offerings are close, but a serverless architecture allows for the features of PaaS without as many limitations. We effectively further abstract out our architecture and our platform to allow for a different way of approaching units of code and development. PaaS will usually be closely tied to a specific development framework, while FaaS will offer a selection of languages and a way to make things work in their environment.
How Does Serverless Architecture Compare to Other Cloud Offerings?
You build the functions, and the vendor does the rest. IaaS requires maintenance of the actual bits on the infrastructure, and PaaS limits you to a specific platform like Ruby on Rails. Serverless tries to strike a balance of running code via something like a microservice or similar functional unit in some kind of container and making it efficient and scalable. It is a very object-oriented approach to development at the implementation level.
Developers focus on developing the product itself and not trying to balance building the core product with scalability. Devops doesn’t need to do as much (if anything) to make things start working and continue to work with the (right) platform. It’s easier to plan for use cases as most serverless solutions are consumption based rather than allocation based. This does leave the obvious concern of a spike in usage or similar though. You can mitigate this by planning some flux into the budget.
IaaS emulates a traditional network infrastructure, but in the cloud. Serverless architecture abstracts this further to create an offering which doesn’t need as much setup at the expense of flexibility. For many webapps and web solutions, this is more than adequate.
The Pros of Serverless Architecture
Serverless architecture has some pros over other approaches to cloud services. These pros aren’t absolute though and depend on exactly what you’re doing. We’ll compare the pros and cons, as well split them up into technical as well as operational pros and cons.
Technical Pros
Serverless architecture shines from a technical side. It reduces the technical hurdles to getting a product deployed and making it scalable. You are responsible for the code and configuration, the platform handles the rest.
By offloading the server, you don’t have to deal with managing patches, updates, etc. Uptime and load balancing becomes a money problem rather than a technical problem barring exceptional circumstances. Abstracting the server means abstracting the associated technical problems.
FaaS providers make the concept of devices an abstract. You don’t need to assign x services per server or unit, but just create units as necessary and allow them to scale as necessary or with a fixed unit. A device becomes a named item in a chart rather than an actual server with space constraints or operational constraints which need to be attended to.
Operational Pros
By abstracting away the concept of servers in general, the total cost of ownership (TCO) is standardized and made more predictable. You don’t need to deal with physical devices, equipment, cooling, maintenance, upgrades, etc. A couple bad drives isn’t going to take you down for days. Catastrophic hardware failure is a service degradation and not necessarily downtime. Some use cases will even have their TCO reduced overall (mainly smaller applications which previously required licensing). You typically pay a higher price per equivalent computing unit over other solutions, but the price is predictable (usually).
Traditional server farms or even some IaaS offerings require you to overprovision in some way. You pay for what you use with a serverless architecture. If the workload is predictable, this means the cost is predictable. If the workload is unpredictable, the cost per unit is predictable, but you don’t need to provision for the spikes 100% of the time. It scales on demand.
You can expect a higher amount of reliability from a cloud provider than a private data center setup for most configurations. This may not be true for large enterprises with the resources to do everything right, but it requires a lot less in terms of staff and equipment for maintenance. Serverless architecture ends up with a more predictable TCO (or even lower TCO for some use-cases) and a higher reliability for most use cases.
The Cons of Serverless Architecture
Like any other cloud based service, there are cons to approaching the cloud and using a serverless architecture. The cons can be deal-breakers for certain workflows, or can complicate operations or development. Many of the cons for a serverless use-case are the same as those for pretty much any cloud environment, though some stick out more than others.
Technical Cons
One of the biggest issues with serverless architecture, or cloud offerings in general, is the loss of control. From a technical side, you have virtually no say in how much of anything on the backend works. The whole point of a serverless architecture is to reduce the number of moving parts from a technical side. In exchange for this, you lose control.
You cannot control the backend or even see it in general with most platforms. This may not matter for many use cases, but can be a huge deal for certain industries and for certain development stacks. If you require integration with certain products, you may not be able to work them into certain serverless platforms. Some services plain don’t have a usable API or an API at all and rely on low-level connectors.
The overall configurability is going to be limited to what is available on the platform. You lose control or insight into the underlying technology. A feature may be available with a minor tweak, but you’re left at the mercy of the vendor. Is your business worth enough for them to add a new feature?
Operational Cons
Even though the TCO tends to be more normalized, it also tends to be higher over the lifespan of the product. Most cloud offerings operate on this same principle. Let’s look at the average use cases with nice round, easy made up numbers. If a server stack and the technology to make it work costs you $1,000, and it averages $50 a month (5% of the original cost) to maintain, it costs $1,600 for the first year, then $2,200 for two years (if nothing goes awry). If the same in a serverless environment costs $100 a month (this tends to work out to roughly double the ideal maintenance cost in my experience), it runs you $1,200 the first year, but $2,400 the second year. If we assume hardware is safe to rely on for 3 years and we get lucky (plenty of clients get lucky and keep running the same, exact stacks for 8 years or more), we end up with $2,800 for our in house servers and $3,600 for our cloud solution. By year 4, we have already reached the point we can buy new hardware and come out ahead.
Despite our numbers not being real numbers, the point still stands. Cloud environments tend to be cheaper up front, but begin to cost more the longer they’re in use. You don’t have to deal with equipment swaps or physical maintenance, but you do have to budget for it. In a tech shop, running your own “cloud” can make more sense if you have qualified staff already and are familiar with the technology.
Another operational hurdle is that you lose control over the actual process on the vendor side. When you run your own stack, you control everything (within reason). Once you outsource this, you’re at the whims of the vendor. If they don’t give you insight to what they’re doing, you don’t know what they’re doing for the most part. What exploits do they have? Unless you’re testing, you don’t know unless someone else finds them first and reports them.
Is a Serverless Architecture Right for You?
Like any other cloud solution, there are good use cases and bad use cases for the technology. If you need to control the underlying technology, serverless architecture is going to be out of the question. How much control do you need and how much do you want? What languages and platforms do you need? You should be able to answer these before even starting development.
What integrations do you need? While many serverless architectures can be made to integrate with obscure products, some just plain aren’t secure or sane to integrate. I worked with a client who wanted to move their development stack to Azure, but the vendor for a key piece had no way to make it work except opening a database to the outside world with no encryption or authentication (there were some specific factors preventing other solutions from being effective).
How do the pros and the cons stack up for your usage? The pros I listed can just as easily be cons as the cons can just as easily be pros depending on the use case. The fixed cost and maintenance of equipment can be a non-point to a shop which provides cloud solutions already. The lack of oversight can be a deal-breaker to some, and a relief to others.
Featured image by Johannes Plenio from Pixabay