From DevOps to NoOps with AWS and the Serverless Framework
Note: I drafted this post about 3 years ago. I really don’t know why I ever published it. Today I stumbled upon it as I checked what is in my draft folder :). So Without further editing I decided to just publish it. Just keep it mind that stuff may be out of date. Have fun!
In the last few months I got the opportunity to engineer a cloud native application using the Serverless Framework and cloud native AWS services like Lambda, Step Functions and API Gateway.
In this article I want to share my experiences and lessons learned with you guys.
Things changed quite a lot
Development and operation of software changed a lot in the last years. Back in time there were long release cycles of heavyweight applications, while operators needed to set up and maintain bare metal machines.
Today we have short release cycles and can run software without even need to care about the infrastructure. Crazy, huh?
DevOps
So. I don’t know what DevOps is for you, but I can tell you what it is for me. For me DevOps describes a way to engineer software, a mindset, a culture. A team doing DevOps practices will most likely release often, use Continuous Integration/Deployment/Delivery and develop software in agile way that is composed of microservices.
The gap between development and operation of software is closed as much as possible. You build it, you run it. No matter if you have operators that provision virtual machines for the developers to run their apps on or if the development team uses a PaaS like Cloud Foundry.
NoOps
Now NoOps takes the DevOps philosophy to the next level by (almost) completely removing the need for dedicated operation tasks. In the first place this might may sound a little bit disturbing to loose the control, but you will learn to like it the more you get used to it.
I mean, if you follow the path of DevOps consequently and think a little bit further, NoOps is a natural follow up.
Note that people often think that you don’t need for servers or operational tasks at all if they hear things like NoOps or Serverless. You will still need, but the amount is much smaller.
Amazon Web Services
So we learned that in a DevOps/NoOps world we develop cloud native applications and somehow close the gap between development and operations process.
Now, you have many different possibilities in order to achieve this. In a classical DevOps world you most likely will automate the provisioning process of infrastructure, still you would need a pretty strong operational (sysadmin) knowledge in your team in order to maintain the infrastructure.
Or perhaps you are lucky and have PaaS in place that abstracts the infrastructure completely, which is really nice if you don’t have strong operational knowledge in your team. In this situation maybe another team operates the PaaS. This is by the way, the situation we have in our company.
In both situations you would have somehow maintain the infrastructure which simply said costs money. The infrastructure itself and the maintainance.
Well, with AWS you can delegate the whole responsibility to someone else and can completely focus on the development of applications. You kind of loose the control, but you don’t have to care about operations at all.
In the end DevOps and NoOps as well as the Serverless movement try to reduce the amount of dedicated operational tasks to a certain degree in the software engineering process.
AWS Lambda
Have you ever heard of the nanoservice anti pattern? No? … If you design your applications as a composition of microservices you also increase the operational effort which is needed in order to run them, right?. Instead of having to operate one (monolithic) application you now have to operate lots of small ones.
The more microservices you have, the higher the operational effort will be and the smaller you design your services, the more of them you will need. And that’s called the nanoservice pattern. A nanoservice is basically a microservice that is too small to justify it’s operational effort.
Now if you use AWS Lambda, designing nanoservices is not an anti pattern anymore because you completely delegate the operational effort. Nice, huh? Basically what you end up doing is to write Functions which are then deployed as AWS Lambda. And from that moment on AWS will take care about literally anything.
First of all your AWS Lambda will be only spined up on demand, the rest of time it idles and thus produced no costs.
Also AWS lambda provide auto scaling capabilities which is kind of nice, because you don’t have provide such a mechanism by yourself.
AWS Step Function
With AWS Step Functions you can compose those little nanoservices aka AWS Lambdas if you want to have them being executed in order like in a state machine for example. It allows you to create complex execution paths and extensive error handling.
In our case we had a big task which was composed of several little tasks consisting mainly of one or more http requests and had to be executed in a specific order. For each of the little tasks which created a dedicated Lambda Function. Now we had the requirement that if one of those little tasks failed, all the tasks before had to be rolled back again. And that is a perfect use case for Step Functions.
If you define a Step Function you can explicitly define in what order the different Lambda Functions should be executed. Furthermore you can define the sequence Lambda Functions that should be executed if one of the Lambda Functions(of the ‘main’ sequence) fail, and such things as how often the execution of a specific Lambda Function should be retried as well the delay time, etc. After specifying the Lambda and Step Functions as well as deploying it AWS takes care of executing the software composed of nanoservices.
Serverless Framework
I have no clue how good you know AWS but at the time we started the project I didn’t know really much about how to work with AWS. Basically you can create all the AWS services you need either through the web UI, the aws cli or CloudFormation. Maybe there are even more possibilities I don’t even know about.
Anyway you want to get your code running on AWS as Lambda and Step Functions and luckily there is really cool framework out there that therefore abstracts the creation of AWS resources for you. You basically just provide your code and some configuration and the Serverless Framework takes care of the rest. It provides the possibility of deploying, updating or removing your code on AWS while it creates all the necessary resources, roles, permissions, etc. By the way it creates complex AWS Cloud Formation templates to accomplish that.
Conclusion
So, what’s the state of the onion? We reduced the need for operational knowledge to a minimum and engineered a composition of nanoservices using AWS Lambda and Step Functions with the Serverless Framework. For me being used to engineer Microservices having a DevOps mindset always felt very natural. Now, it’s no surprise that going one step further by engineering nanoservices and reducing the need for operational tasks even more, felt even more natural. But now let’s answer a very important question you guys probably have.
Enterprise Ready?
People tend to stay in their comfort zone, I can totally understand that. And every few months a new hype gets born. People who like to stay in their comfort zone will get sick of all the new hypes, being it a new technology or methodology or whatever new cool JavaScript Framework.
Appart from the fact that I am not such a person and I personally believe that having such a mindset as a software engineer is not productive, there is at least one valid question that such a person would ask regarding a new technology.
Is it enterprise ready?
That reminds of the time about 2015, the nodejs hype started maybe one year ago and the engineering team of the company I worked back then wanted to give it a try by breaking the existing monolith into microservices using nodejs instead of Java. And some people, amongst them also the CTO, questioned nodejs being enterprise ready.
Now guess what, you will never find it our if you don’t try it. And you will never improve on anything if you do not try new things and step our of your comfort zone. And if you fail, fail fast. That is not a problem, the opposite is the case. It is a valid procedure in agile software development IMHO.
To get back to the question if going the NoOps way with AWS Lambda and Step Functions as well as the Serverless Framework and nodejs is actually enterprise ready. Meanwhile Nodejs is considered as enterprise ready, but how about AWS Lambda and Step Functions or the Serverless Framework. Well, if you use AWS services in general, you make Amazon responsible for running your services which IMHO can be considered as being enterprise ready. I mean if AWS goes down, half of the whole internet also goes down if not even more. The Serverless Framework on the other hand is pretty young so you don’t have much help out there in the internet comparing to a well established Framework.
My personal final answer to the original question is: Yes it is enterprise ready. Why? Because we managed to run our software in production for a big manufacturing company. And even if we come to the point where the this young technology (the Serverless Framework) does not meet our needs anymore, we can simply contribute to it as it Open Source Software. By the way in my opinion having that mindset is more likely the way to go for software engineering, in contrast to have to wait for someone else to extend proprietary software.
