Why go Serverless

The question is not why you would want to go serverless, the question is why would you not go serverless.

Let us think about this for just a second. In a typical environment, you would not only have to think about the flow of the application and how its pieces fit together, but also to the underlying architecture. Now that DevOps is becoming more common, it is the developers that sometimes find themselves having to worry about these issues. Or in a more traditional shop, there is the team that the application is “thrown over the fence” to that has to deal with the underpinnings. In other companies, it is the DevOps group that works with the Dev team on designing and handling the infrastructure. But, no matter how you slice it, the infrastructure is a huge headache that has to be managed.

In a serverless world, you have to ensure that the application runtime that you are programming for, matches your development environment. But for almost all intents and purposes, that is where it ends. When dealing with servers, there are a number of factors that you have to take into account. For a moment, consider all the items that have to considered when dealing with a classic server architecture:

• Physical or Virtual Hardware
• Operating Systems
  • Patches
  • Package installation
• Montioring
  • server uptime
  • server performance
• Scheduling such as cron.

The list goes on and on. This is just a precursory list to get you thinking about it. But when dealing with servers, there is no magic button to push that takes care of all of your issues. You have to deploy the system, patch it, configure it for the application, install the application, add it to inventory, and add monitoring. All this is time that takes away from the application that you are trying to develop. Oh, and I failed to mention all the security considerations that must also be taken into account. (And yes, you still have to think about security when dealing with serverless).

The normal response to this is that my application can never be serverless. There are some rare occasions where this is true, but in many situations this is just not simply true anymore. With various services from Amazon and Azure, you can make serverless work for a wide variety of applications. My area of specialty is in AWS, and as such, most of my examples will come from there. If you wanted to make a serverless application in AWS you would probably use the following services:

• Lambda — the serverless code execution platform
• Cloudwatch — Monitoring is good
• API Gateway
• S3 — for hosting the front end static content or powered by a javascript framework
• DynamoDB
• CloudFront
• Cognito

Using theses tools in various ways can allow you to create applications of all sorts. In fact, I believe that tying in other parts of the AWS family of tools would provide you with the ability to create serverless applications in a way that I have never thought of.

But, how do you start using serverless? For this, it is best to look at your current environment, find a task that is short lived and runs on a machine, and then move it. Or, an even better use case would be to find a repetitive task that needs to be automated, and try doing it with Lambda. This will allow you to get your feet wet with something that is already being accomplished while not breaking existing support models. Finding something that is simple is the best way to get a win under your belt, and give you the confidence to move on to continue to expand your use of it.

The big thing to remember is that all this serverless stuff can be used in all areas of the stack. It can be used for application development to application and server support. For example, automating the backups of long lived servers could be done via lambda. This is an infrastructure helper. Converting images into thumbnails and providing them for use to the application, that would be an application specific task. And, that could be one that supports a classic application running on servers.

Do not let the idea of serverless scare you off. Take a moment, see where you could make it fit, and give it a try. Worse case, you don’t like it, and have lost a few cycles. Best case, you have found a new tool that you can add to your quiver.