The leading global conference devoted to the serverless trend, Serverlessconf is a community conference that aims to share experiences about developing applications for so-called serverless architectures. Serverlessconf will take place in Paris on 14 and 15 February. Today we choose to present you one of the inspiring speakers that will join ServerlessConf, Randall Hunt from AWS.
Randall Hunt is a Senior Technical Evangelist and Software Engineer at Amazon Web Services in Los Angeles. Python is his favorite language but he can sometimes be found in the dark realm of C++. Randall is the author of gitshots, apodtwitter, isthe7running, as well as a contributor to MongoDB, Homebrew, boto and several other open source tools and libraries. He used to launch rockets at NASA and SpaceX but found his programming passion at MongoDB. He is a total space nerd.
Is there a serverless revolution ? How does that changes the way we develop applications?
I’m not sure I would use the word “revolution”, but it’s a paradigm that is going to stick around. You saw the beginning of this serverless paradigm many years ago with event based computing where companies let you run code in response to events, without you having to manage any infrastructure – this was true even before AWS Lambda came around. With AWS Lambda becoming available in 2014, you have this whole new set of options for invoking functions as a service (FaaS). You can have them triggered on an upload to S3, on webhooks, on anything really… a whole set of things that you previously could not do without having some fleet of servers constantly polling for some event. Now, we’re seeing the evolution of serverless. I wouldn’t call it a revolution so much as an evolution. We’re developing maturity in the toolchains, we’re developing the ability to build out more complex architectures and applications. Take Aurora Serverless for example: my infrastructure can scale down to zero, meaning I don’t pay for idle time, I don’t need to have a database that’s always on in order to get business value from it, and I think that’s where serverless is going to go… more and more products where you’re not paying for idle time, not paying for compute unless it’s running and that’s one of the really cool promises of serverless.
Operations is totally different with serverless too. A lot of people say that DevOps goes away with serverless, but I just think you have a different set of operational concerns with serverless. You have a different set of ideas and problems to deal with, but I still think it’s vastly easier to deal with than managing servers, but that’s my personal view on Serverless.
How does serverless responds to today IT’s needs?
You can look at all the different examples of Serverless across our industry… companies like acloud.guru that built their entire platform on Lambda, S3, and DynamoDB… What are the current IT needs? People are looking for agility, maintainability, and the ability to just get things done. As coders we are often really excited with the idea of tinkering these new products… tinkering is fun, it’s useful, inspiring, but the IT industry needs products, real functional tools solving real business problems. Companies like the Washington Post are using Serverless to accomplish complex business goals and it’s working for them. You can see all the case studies about the changing costs, but it’s not just about cost, it’s about agility and maintainability. It’s also not just about webapps. People manage compliance for their entire industry using simple Lambda functions.
How does serverless work together with regular cloud managed services, how are they complementary?
I think most AWS services being built today are thinking about serverless paradigms and how they can use them. At re:invent in 2017 we announced Aurora serverless, an example of taking a stateful and persistent database service and bringing portions of that serverless paradigm into the architecture. Databases don’t exactly lend themselves very easily to these fully managed aspects. DynamoDB is popular because you don’t have to manage any servers… if you can bring that same kind of power to other AWS services, you’ll enable a lot of new and exciting workloads. Lambda in particular works very well with just about any service. With the ecosystem continuing to improve, we will have more and more events sources. Event invocations from SQS is something people ask for a lot, or a particular type of event in a DynamoDB stream straight to Lambda instead of just getting the whole stream in Kinesis… there are a lot of opportunities to develop how theses events start to invoke Lambdas. Lambda is at the core… this is true for all cloud providers, not just AWS, we’ll see more and more functions as a service, maybe people will want to have event sources across multiple clouds, event sources that don’t require me to vastly change my code if i want to move from Lambda to something else. That’s just my idea for the future, I don’t know how much of that is going to happen, but people are going to be interested in figuring out how to get the most of serverless and they’re going to want it *everywhere*.
AWS announced a lot of new serverless products at re:Invent, what are the most exciting to you?
A lot of the AWS Lambda updates are very exciting, the fact that you can get concurrency control and throttling per-function is really useful for me – or that you can have 3GB memory functions now. Even right before re:Invent we launched a ton of updates to Lambda@Edge that let you dynamically choose an origin or even run a whole application at the edge. Or, Sagemaker, it is not entirely serverless, but the idea you can go and have a Docker container (and having a container is going back towards servers) and have it run for you and be able to invoke requests on it and serve an AI model is very powerful. You still have to think of directories and workspaces and stuff like that, calling it serverless might be a stretch. Aurora serverless updates are quite exciting, and Cloud9 IDE, and a lot of new services…. it’s an exciting year for Serverless but also for the cloud in general. I remember in 2014 I was sitting in the audience waiting to hear the Lambda announcement and I remember looking at the audience to gauge their reaction: one half of the audience that got it, and the one half that totally didn’t get it. Now, in 2017? That second half didn’t exist, everybody was asking how to move their applications and architectures to serverless, how to rewrite most of their business logic for lambda, and it’s a really impressive change for the industry to have undertaken in just a few years… and it’s still early days!
How do you see the evolution of the serverless ecosystem?
I could make a lot of predictions, I have no idea how much would be true, but one of the things im really excited is the development of serverless technologies, with things like AWS Cloud9 IDE, you are able to work with Lambda functions and API gateway much faster. With the Serverless application model (SAM) it becomes easier to deploy not just a Lambda or API gateway but also a DynamoDB table, an S3 bucket, and to connect all these invocations sources and keep it maintained in a couple of files that are easily testable. You can build a CI/CD pipeline or go to AWS Codestar and launch a Flask based serverless app in just a few minutes. Those sort of things will continue to get better and better. I’m also excited of all the community interest, developers working hard to build frameworks like Zappa, Chalice, Serverless, Apex, Sparta and a ton of others… You can expect support for .NET 2.0 and for Go to arrive really soon as well. And as long as customers are asking for it they’ll get more and more event sources.
Another important thing to mention is X-Ray…. you debug your serverless apps in a different way than you would debug traditional apps. These are massive series of connected microservices… and Ashley Sole from SkyScanner outlined this at a presentation in London in 2016, he mentioned that you can visualize your dependencies with X-Ray, and you realize you have 14 dependencies invoking this function, and however many outputs? It’s always more than you originally suspected. It gives you visibility… that tracing technology is going to be in the default behavior of writing serverless applications in 2018. We need a better monitoring, it’s not just about collecting metrics but about understanding remote procedure calls and invocations.
When you have have all theses different small little functions, and each person working on their service in a development team, you have to add some test, and contracts with the people who are invoking you, the data you are modifying, etc. Previously, everything was just one monolithic application and you could make changes to it and deploy the whole application and break all of production, now the unit of deployment is much smaller than it was during monolithic development. With smaller units of development work, you get more agility, more granularity, but also more complexity in the service graph. X-Ray, or other tracing tools, let you visualize that service graph and manage it.