Today was heavy on research… We want to make sure we choose the right technology for our back end. Our client wants to use Amazon Lambda, which is the most popular of the new “serverless” architecture services, and we at first wanted to just make an application and push it to a cloud service. The solution is probably going to be a compromise in between.
We wanted to just create an application because that’s what we’re comfortable with. We’re students. We tinker with new technologies and quickly make prototypes and host them. We don’t necessarily care about supporting them. In order to be effective developers in the real world, we need to be willing to see things from the client’s perspective. They want to use “serverless” architectures. This is a bleeding edge new type of cloud service where you don’t have to think of the server you’re going to run your code on because they provision the servers for you. That’s what they mean by “serverless”. The server is there, it’s just abstract now. (I think of it like encapsulation with object oriented programming, the low level code actually doing things is there, it’s just abstracted by my methods). With the serverless architecture, you don’t even have to think of the application you’re going to create, just the code inside it, because it will actually take raw code and just run it on applications that it creates, on servers that it provisions. On paper, it sounds wonderful. But we are definitely running into some pain points as we try to adapt to this new style.
Most of the problems with using serverless architecture that we’ve encountered seem to come with a general unfamiliarity with the Amazon Web Services online interface. But a lot of the issues probably also stem from the relative immaturity of the serverless architecture compared to more traditional methods of doing web development. This sentiment was echoed by a blogger I encountered who described Amazon Lambda as being “not ready” just seven months ago. From when we tested it out, we encountered tons of digital red tape so to speak. We couldn’t just pass parameters to code to do stuff with them. We had to write middleware and config files just to get the parameters into our code.
An alternative we’re considering is using Docker. It has the advantages of an actual application (we get our parameters! yay!) but it also has that abstract slightly serverless style that the client is going for. It’s supposedly independent of the server you’re going to run your Docker “images” on. The client should be able to take a Docker image we produced and easily get it running on any Docker-supporting cloud provider they wish. And that includes Amazon Web Services, where they currently have everything running. Docker itself has a learning curve that my team mate and I will need to get through to go this route, but I’m confident we can get comfortable with it. Today, we were indeed able to get something running locally and pushed to Amazon, so this so far looks much more feasible to work with than Lambda.
One thing’s for sure, in the past few weeks I’ve learned that there’s a lot more to web dev in the real world than I imagined!