You can also watch the video version of this here: https://youtu.be/92ybtOjJSHM and https://youtu.be/bLskVhbBxDY
The first challenge is the one that tends to be raised the most: Vendor dependency and lock-in.
Suppose you want to create a pure Serverless application that is as optimised and cost-effective as possible. In that case, you will have to use many of the cloud provider’s proprietary services which are not necessarily compatible with or even available from other cloud providers. This design will make the application dependent and locked-in to your cloud provider of choice - this is generally unavoidable. Now, whether or not this is a real problem is another matter which really depends on organisational or regulatory policies. If there is a policy that requires all applications to run on two cloud providers, then Serverless will not be a suitable technology choice. These type of situations are best addressed with containers - a technology that is far more transferable between different providers. But containers are not Serverless, and the underlying servers need to be managed and paid for regardless of utilisation. What is more common is having the main application on one cloud provider, but using some of the services from another cloud provider. This adds latency, but it is certainly possible to get the best out of multiple providers this way.
In my opinion, the real challenge of Serverless is latency. Latency is part of the delay between sending a request and getting a response. Part of the wait is your application doing some processing; this is adding value to the request. Latency is the waiting time that is not adding any value such as the time it takes for the request to reach your backend or the time it takes to talk to managed services before you can do something of value with them. For a responsive web application, you want to minimise the wait and certainly minimise latency. When it gets too high, it becomes a bad user experience, and users might lose interest. Applications that run entirely on a single server will usually have very low latency because the activity is all within the same server. With a Serverless microservice architecture, you have many different components, each one talking to another over the network. Each step in itself does not add much latency, but it adds up. We mitigate this by really thinking about how we design these types of interactions. In some cases, we want to minimise the number of steps that the user needs to wait for. For example, we can accept a request from a user and let them know it was received while processing the task in the background - this is called an asynchronous request.
Another challenge is around talent. Serverless has not been around that long - only six years. Any individual or development agency with Serverless experience has worked with it for a maximum of six years (at the time of writing). Related skills such as good programming techniques and microservices have, of course, been around much longer. But that true modern Serverless experience is going to be maximum of six years, and they know that they are rare so they can charge a premium for organisations that want to pursue Serverless leveraging their experience. So besides it being a challenge to find good talent in the first place, these talents tend to be high in demand and cost a premium. One way to mitigate this is to hire capable developers and others with related skill sets, then train them in Serverless. Possibly by bringing in one or two that do have the experience to get things started with best practices and knowledge transfer.
The next challenges about responsibility. With Serverless, a lot of responsibility has been moved to the cloud provider. They are responsible for far more of the technology stack compared to servers. Giving away this responsibility also means giving away much of the controls and the flexibility that you have over those underlying services. You don't have access to the operating system and software anymore, and with it, you are limited to what the cloud provider lets you configure via the service. If there are organisational or regulatory requirements for specific security configurations, then you might not be able to do that in the services which can be a challenge.
Similar to the topic of responsibilities are service level agreements or SLA’s. Suppose you promise a certain level of performance or your customers expect certain guarantees to be made. In that case, you need to be aware of what guarantees the cloud provider will give you for the services you are using. If the cloud provider is guaranteeing 99% uptime for a particular service, then you would not be able to offer more than that to your customer because again, you don't have the ability to control these things. Some of the cutting edge services might not have any SLA in place, so it's definitely something to look at before developing anything.
Scaling might seem like only a benefit, but it can be a challenge if not managed. Most Serverless services will scale automatically to massive numbers with not many built-in limits. For example, a user of your application could theoretically upload 50 terabytes of data. You would not need to do anything for this, and the user is only limited by their internet connection. This sounds great until you get the bill for storing 50TB at the end of the month. To mitigate excessive scaling, it is crucial that you pro-actively configure limits in the services you use or add limits to your application.
Operational cost estimates can be challenging with Serverless. With servers, you know the price of a server per month. You may know how many servers that you need to meet the user requirements so can relatively quickly have an idea of the total cost per month. With Serverless you are not billed a fixed amount over time, you are billed based on requests, request time, storage and other smaller much harder to estimate parameters. On top of that, a Serverless solution might be using 10-20-30 different services, each with their own detailed pricing parameters. Because the pricing parameters are detailed, your user numbers and user activity estimates also need to be more detailed to get accurate estimates. Serverless cost estimates tend to be large spreadsheets that are quite time-consuming to research and produce.
The last challenge I want to cover here is service limits. There are two types of limits imposed on cloud services by the provider. Soft limits, which are generally there to stop the abuse of new accounts. You can request the cloud provided to raise soft limits if you provide a justification. There are also hard limits, which are limitations of the technology itself. It is really crucial to look at the documentation of any service before you use it to understand what those limits are and how they may impact your current or future requirements. Hard limits are often also a way for the cloud provider to indicate what they intend this service to be used for. So if you run into hard limits, it could be you are not using the right service for that particular problem, and you might want to check if there is another service that might be more suitable.
To go deeper on this topic and to read many more related topics about Serverless Architecture please buy the book Serverless - Beyond the buzzword here: serverlessbook.co
