Serverless Architecture – Key Features, Benefits and Challenges

Now let's talk a little more on the pros and cons of serverless computing. First, as we discussed, there are no servers or operating systems, or hardware or software to maintain. And that makes your life as a developer or DevOps so much easier. So kind of more me-time for you and you can be more productive and be able to laser focus on creating stunning applications. So serverless is all about faster innovation, high productivity, and faster time to market. And in most cases serverless applications require little to no administration. Alright, the next benefit is easy and efficient scaling. Serverless applications can be scaled automatically or at the most with a few clicks to choose your desired capacity. There is no need to create any specialized scalable architecture or designs. You can get a large number of serverless functions running within seconds, and each function runs for a few hundred milliseconds to a few minutes. You can allocate resources for each of this functions individually. This is going to allows you to scale your application easily and at the same time efficiently. Thirdly, serverless approach provides built-in high availability and fault tolerance. You don't need to have any specialized infrastructure to make your applications highly available or fault tolerant. All your applications get this benefit of availability and fault tolerance by default, irrespective of whether you’re just building a hello world app for your testing, or you are building the next Facebook or YouTube. Service Integration is another benefit. AWS provides a host of services that readily integrate with each other, this is something that is going to allow you to perform a lot of stuff very very easily – for example you could be sending text notifications, emails, running analytics, hosting APIs, storing files, running automated workflows, deploying machine learning models and so on. And all this can integrate seamlessly with your serverless application. Then the real benefit of serverless is that there is No idle capacity. You pay only for what you use and no more. For example, with traditional architecture, say you created a server with 100 Gigs of memory and you're only using about 10 Gigs of it. You'll still have to pay for the 90 Gigs you never used. But with serverless architecture, you only pay for what you use. So, If you use 10 Gigs, you only pay for those 10 Gigs. Also, with AWS Lambda which is the core component of Amazon's serverless platform, you pay only for the time your code runs. So, there is no charge if your code is not running. If your code runs for say 100 milliseconds you are charged only for that 100 milliseconds and no more. That's really a very fine-grained control and certainly this result in a substantial cost savings for your business! Even with all these benefits, serverless may not be the solution for all your problems. Its not a silver bullet and does come with some challenges, not many though. First one is Vendor lock-ins. So, there are a handful of cloud providers like Amazon AWS, Microsoft Azure, Google Cloud Platform, IBM Cloud and there are some more. And they really want to you use more and more of their services, offcourse for obvious reasons. And, they want to build an ecosystem of related services that work together. This may not be really a deal breaker though and we’ll discuss what is called as multi-provider serverless later in the course as a way to alleviate this challenge. Another concern with Serverless is the public cloud. The serverless architectures run on the public cloud. Some use cases or industry-specific regulatory requirements may be a deterrent to using this public cloud. These cases might be very few, but then again if your use case lies in this category, then serverless may not be a good fit. Having said that, Serverless can be run on private clouds as well, so you could still leverage serverless in such cases. However, we’re not going to get into that discussion here. Let’s just focus on the AWS serverless platform for our purpose here. Another point to keep in mind is the level of control. So essentially, you are giving up some degree of control by letting someone else manage the infrastructure for you. And in some situations, wherein you need more control of the hardware resources or of the OS level resources, this might prove be a limitation.