As a fairly new technology, serverless is ripe for both intrigue and confusion. We spoke with our co-founder and CTO, Eric Dynowski, and our director of development, Andrea Cadeddu, to understand the hype and determine when going serverless is a good choice.
Here are some excerpts from that conversation.
So what is serverless?
Eric: I think probably the classic technical definition is that there is no underlying infrastructure that you have to manage. There’s no operating system, there are no virtual machines, there are no instances, there are no visible processes, and there’s no anything that has to be taken care of on a regular basis.
Are people approaching serverless for purely technical reasons, or is it purely for the business benefits?
Eric: It’s not like our customers are coming to us and saying, ‘we want you to build a serverless application.’ They’re telling us they need certain things, like:
- we want to build an application
- we want it to be in the cloud
- we want it to be low cost
- we don’t want to have to pay a lot of money to run it when we don’t have a lot of users
- we want it to scale automatically
- we don’t want to have to manage a whole bunch of infrastructure
And serverless is often the answer.
What core benefit are clients looking for from serverless?
Eric: I think it’s unique not necessarily to each client, but per application. So depending on whether we’re building something to support devices in an IoT vs. building a serverless-based web application vs. real-time data distribution, whatever that solution is, the needs and drivers for that are going to be slightly different.
How rapidly are your clients expecting to see the benefits of serverless?
Eric: Their expectation is immediate. I think that the marketing around serverless, the marketing around cloud, seems to by default indicate that you get all the benefits of those resources out the door.
But in a classic model, you might be deploying something and you don’t get low cost and automatic scalability out of the box, so you have to build all that stuff yourself. What serverless does is allow us to achieve some of that much more quickly rather than having to design it into the application from the ground up. Especially with the AWS Serverless Application Repository, where each application is packaged with a Serverless Application Model (SAM) template.
What was it like for developers before the AWS Serverless App Repository?
Eric: A five-gallon bucket of Lego bricks with no instructions on how to build the Millennium Falcon.
I think there was probably a challenge in adoption with serverless because it can be complicated. When the serverless model and concept first came out, there were no clear guidelines on how to do it. There were no clearly defined patterns for how to develop a serverless application, what’s the best way to structure it, and how many pieces should there be, and should there be a Lambda function for every service and maybe every API endpoint, and how do you host static content in S3 but make sure it’s being authenticated properly.
Now, with the AWS Serverless Application Repository, Amazon is pushing the envelope by providing a reference architecture as, like, the serverless application model, and that’s helping a lot. Without guides, there was just too much possibility.
Andrea: Yeah, now it’s as simple as inputting another library from a third-party developer. I don’t think it gets more awesome than that.
JavaScript started as a really solid idea that gained a tremendous amount of momentum when everybody took the scripts that were reusable and just sort of put them out into the public domain. And it wasn’t really done for any reason other than it was developers helping developers. Do you see that happening more to the serverless side as well?
Eric: Yeah, absolutely. Amazon’s release of the Serverless App Repository is a perfect example of that.
What’s the motto? Developers never let developers start coding from scratch?
Initially, people probably wrote their first Lambda scripts to take care of a common task from scratch. Later, maybe they Googled it and found someone had already posted something similar on GitHub, so they took that script and customized it instead.
Now, with the Serverless App Repository, you can not only take the code for the Lambda function, but also all the infrastructure pieces that it requires as well. So if it needs DynamoDB tables, or if it needs an RDS database, or an API gateway — you don’t have to set up all that infrastructure ahead of time and then deploy the scripts. The App Repository lets you share an entire application with all the resources and infrastructure that it needs so that another developer can just download it and customize the little bits that they need for their particular use case.
It’s definitely turning into a community and a shared ecosystem.
Is building applications really faster with serverless?
Eric: Absolutely. For one of our clients that we’re building some serverless applications for, there is a whole authentication component to it where we have to authenticate users, reset passwords, pass tokens around, all these things. If we had to develop all that from scratch, it could be a week’s worth of work. Now with the scripts that are out there and the infrastructure that’s provided in AWS, it takes an hour.
Andrea: I did that yesterday as a training exercise with my team. We spun up a completely new service and had to serve downloads, and it took one hour to go from the beginning to the end. From zero to fully authenticated with multi-factor authentication, password recovery, and all that stuff from scratch. And that is definitely amazing.
Is there a steep learning curve with serverless?
Eric: Yeah. To develop complex serverless applications, there is a huge learning curve. It takes time for a developer to become familiar with the patterns, the tools, the models, and the implications. Once you’ve sort of been primed to a point where you can develop that application in 30 minutes or an hour, it’s doable, right? But you have to do all that upfront work and retrain the way you do things. And that takes time.
Andrea: What is still rough is the tooling. There is a lot of confusion. It’s not always very clear how you build something in serverless. There is definitely a lot of discovery to be done. The best practices are still in development.
Eric: Right. And in the traditional world when we were doing server-based apps, you had an infrastructure team and a network team, and they handled and absorbed a lot of this stuff. Now you have to think about deploying a database and understanding what a port is, what an IP address is, and what a policy is, and so all of a sudden developers have to learn and know about all these other things. The cool part about it is it empowers them and we don’t need an infrastructure team to support the developers. But it adds just a whole new level of complexity now that they have to deal with.
So are organizations that you’re talking to looking at leveling up their own development teams? Or is that something they’re looking to Deft to be able to provide for them?
Eric: We actually get the full spectrum of that. We have clients on one end that don’t have development teams, they have no technical staff whatsoever, and they just say, ‘This is what we want, you guys make it.’ And Turing Group will take on the full brunt, all the way from development and project management to the software lifecycle process and requirements gathering.
Those clients want to focus on what they’re good at, and building technology solutions is often not that. They have a product or service that they offer and that’s where they want to be experts, not necessarily in building serverless apps. So they’re perfectly content with outsourcing.
On the other end of the spectrum, we have clients that want as much involvement as possible and we work very closely with their development teams. They may have 30 developers sitting and working on a project and three of us providing advice and direction. And we’re sort of the subject matter experts in the room in those cases.
And then we have cases, probably more than the others, where we’re in the middle. Maybe we’re leading the project and they’re adding in an extra two developers that are getting up to speed. The hope is that by the end of that project, they can take the whole thing over themselves.
What are some roadblocks with going serverless?
Eric: There are going to be folks that are going to be holdouts — they want to do things the old way and haven’t bought into the serverless thing. And then there’s going to be people on those teams that are all about it. And so we have to navigate all of that.
Each of those situations creates this feeling within certain developers and technical teams where if they’ve never done serverless and they’re giving it a try, they’re going in skeptical. Or they have misguided views on the benefits because they haven’t actually tried it and don’t know what the implications are just yet. They just read something in an article somewhere and think, ‘OK we can just do this.’ And then it could fail terribly or succeed wonderfully.
Sometimes they’ve already tried and failed and say, ‘See it doesn’t work. We tried and it doesn’t work.’ And we have to go in there and carefully say, ‘Well you did it wrong.’
Serverless seems like a huge cultural issue. Do you just put everybody around the table and say, ‘This is the way it’s going to be now’?
Eric: I wish we could do that, ha. No, it requires meeting with developers and team leaders and project managers on an individual basis. In many cases, it’s listening to them and providing meaningful responses back.
Not being dogmatic about serverless architecture helps. We also come up with cases where a monolithic, server-based approach still makes sense, and so we have to acknowledge when those cases are there. So it’s earning trust and credibility with people on both sides of that fence.
I also think the good part is that we were developing applications before serverless was a thing or reliable or standard. So the developers that we have at Deft came from jobs where they were building applications in the traditional way.
We had to go through the same process of educating and converting our own developers. So we get it.
Andrea: Definitely. And what doesn’t work is imposing it. I think that’s the worst thing we can do with the people that want to learn serverless.
On the other side, what worked very well for my team has been to be as pragmatic as possible. You have to build something either way, the key is to keep it simple.
At the end of the day, serverless is simpler than having operations teams build up your instance that keeps your application running. So if you bring the team to see this, or you bring your trainee to see this aspect, it actually works very well and you bring them on board. If you try to tell them that their application sucks because it cannot run a number, you’re fighting a very different fight.
What sort of mistakes do you see people making with serverless?
Andrea: Usually at least 90 percent of the mistakes that I see in serverless architecture are just when people overthink it and make it much more complex than it should be. You can tell they are trying to recreate what they’ve done in the past and apply it as a new model.
Another issue is creating services that are not needed because there is already something that does it.
Eric: Also the whole development model is different, like how you run and debug your application.
Andrea: Yes. And that’s where the development for serverless is a little bit of a pain. The tools for developing and the backend aren’t perfect yet by any means. Debugging can be painful. You can have errors that come from many different interfaces that are involved with serverless, and every one of those interfaces can fail. And sometimes your error messages can be pretty complex to interpret.
Eric: The other interesting conversation that we end up having with clients is where serverless is a little bit of a buzzword, and clients come to us and say ‘we need something to be serverless.’ They don’t necessarily know why or may be inventing a problem just so that they can use serverless.
Given some of the shortcomings, what would you like to see in terms of tooling and debugging for developers that would make it a lot easier?
Andrea: If we speak in an AWS setting, the infrastructure needs to be much more precise. I think that the speed to compile a template needs to be improved.
It also needs to fail faster when it does fail. Sometimes if you have a continuous integration pipeline set up, it could take 10, 15 minutes to have a failed deployment. It’s an eternity, and that’s not pleasant to work against. And sometimes the error messages are fairly complex. So those things happen, and they’re a pain in the neck to figure out. So I would love to see that template validation highly improved, some sort of pre-compile step, and some sort of error checking done at the template level.
When should an application be server-based instead of serverless?
Andrea: Very big MapReduce jobs that take a lot of computer time and resources, those are still better on a traditional infrastructure.
How do you handle the technical and business implications of serverless?
Eric: We run across situations all the time where something from a specifications perspective is fantastic, like as developers we would love that, we can do awesome things for you with that, but from a business perspective, it just makes no sense. And vice versa. We may have business leaders come to us with the most awesome business idea and they can make a ton of money, but implementing it from a technical perspective is just simply not feasible. They’re intertwined.
We just have to consider both perspectives and make recommendations based on both the business and the technology sides.
What do you think brings clients to Deft?
Eric: Sometimes there’s just a business need: ‘We want lower costs, more agility, better flexibility.’ Or they’re trying to solve a problem: ‘We have a problem with our current system and we need to rewrite it or refactor it.’ It’s coming from a business perspective or a business need. And in those cases, those companies are probably more on the side of the spectrum of ‘you guys just handle it.’
On the other end of it, we get companies that are coming to us where the technical teams or development teams are the ones driving the relationship. They’re the ones that want to start moving towards serverless for its technical benefits. And in those cases, unlike the business cases, they want to try to retain as much as they possibly can. And so they want to leverage us more as subject matter experts to provide training, provide guidance, provide the patterns, can we bootstrap them with templates and things like that.
And sometimes — usually where we get engaged — is when they tried serverless and failed.
