Is your company thinking about adopting serverless and running with it? Is there a profitable opportunity hidden in it? Ready to go on that journey?
Today, we’re talking to Rowan Udell, who works for Versent, an Amazon Web Services (AWS) consulting partner in Australia. Versent focuses on specific practices, including helping customers with rapid migrations to the Clouds and going serverless.
Some of the highlights of the show include:
Australia is experiencing an increase in developers using serverless tool services and serverless being used for operational purposes
Serverless seems to be either a brilliant fit or not quite ready for prime time
Misconceptions include keeping functions warm, setting up scheduled indications
Simon Wardley talked about how the flow of capital can be traced through an organization that has converted to serverless
Concept of paying thousands of dollars up front for a server is going away
Spend whatever you want, but be able to explain where the money is going (dev vs. prod); companies will re-evaluate how things get done
Serverless is either known as an evolution or revolution; transformative to a point
Winding up with a large number of shops where when something breaks, they don’t have the experience to fix it; gain practical experience through sharing
Seek developer feedback and perform testing, but know where and when to stop
With serverless, you have little control of the environment; focus on automated parts you do control
Serverless Movement: People have opinions and want you to know them
Understand continuum of options for running your application in the Cloud; learn pros and cons; and pick the right tool
Reconciliation between serverless and containers will need to play out; changes will come at some point
Blockchain + serverless + machine learning + Kubernetes + service mesh = raise entire seed round
Full Episode Transcript:
Corey: This week’s episode of Screaming In The Cloud is generously sponsored by DigitalOcean. I’m going to argue that every cloud platform out there biases for different things. Some bias for having every feature you could possibly want offered as an added service at varying degrees of maturity. Others bias for, “Hey, we heard there’s some money to be made in the cloud space. Can you give us some of it?”
DigitalOcean biases for neither. To me, they optimize for simplicity. I polled some friends of mine who are avid DigitalOcean supporters about why they’re using it for various things, and they all said more or less the same thing. Other offerings have a bunch of shenanigans, root access, and IP addresses. DigitalOcean makes it all simple, “In 60 seconds, you have root access to a Linux box with an IP,” that’s a direct quote albeit with profanity about other providers taken out.
DigitalOcean also offers fixed-price offerings. You always know what you’re going to wind up paying this month, so you don’t wind up having a minor heart issue when the bill comes in. Their services are also understandable, without spending three months going to cloud school. You don’t have to worry about going very deep to understand what you’re doing. Its click a button or making API call, and you receive a cloud resource. They also include very understandable monitoring and alerting.
Lastly, they’re not exactly what I would call small-time. Over 150,000 businesses are using them today. Go ahead and give them a try. Visit do.co/screaming and they’ll give you a free $100 credit to try that. That’s do.co/screaming. Thanks again to DigitalOcean for their support to Screaming In The Cloud.
Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I’m joined this week by Rowan Udell. Welcome to the show.
Rowan: Thanks Corey. Long time listener, first time caller. Really excited to be on the podcast, given the quite impressive list of attendees you’ve had so far.
Corey: That’s a trick, is some people say that when you wind up bringing in guests, you should wind up making sure that there are people who are much better than you are at this stuff. For some of us, that’s not so much as strategy as it is our only option.
Rowan: Nice words of wisdom.
Corey: What are you up to these days?
Rowan: I work for AWS Consulting Partner here in Australia, Sydney specifically. Versent is an serverless only premier partner. So we don’t do any other clouds. Our angle on this is when you have a heart problem, you want to go to a heart surgeon. You don’t just go to a general practitioner. We want to be the heart surgeons for the AWS Cloud.
Corey: There’s about 15 ways we could take that in unfortunate metaphor direction and I’m going to resist temptation. But I see what you’re saying. There’s something to be said for specialization. To that end, do you wind up focusing of particular aspects of the AWS environments your customers are running? Is it just anything involving Amazon on the tin, you go ahead and dive into it? Where’s one?
Rowan: Yes. We have a number of specific practices that we focus on. We do help our customers with some rapid migrations. Just wholesale moving and datacenters into the cloud. My personal area of focus is in the serverless space. We do a lot of stuff in between that. The cloud market in Australia is probably a little bit different to the cloud market in the United States. We work with what our customers want to.
Corey: To be fair, I’ve never been to Australia. It’s on my shortlist of places that I want to visit but haven’t quite made it too. Mostly because I tend to think in terms of cartoons, therefore, anything in Australia is kangaroos, incredibly venomous, and I will probably die as soon as I arrive. How accurate is that naive ridiculous stereotype catalog description.
Rowan: It’s a tough one because there aren’t kangaroos hopping through the streets of Sydney. Unfortunately, I hate to disabuse you of the notion. But there are indeed a lot a lot of poisonous creatures here, and we just get along with them. I don’t want to set the expectations too high, you do have to watch out for some small animals. But it’s a pretty nice place.
Corey: Perfect. In the grand scheme of things, it’s probably less hazardous than say, hanging out in US-East-1.
Rowan: Yeah. I think you’d be right there.
Corey: When you say you’re focusing on serverless, what does that tend to look like these days? As far as companies adopting it and running with it. I’ve had a number of conversations with people on this podcast and elsewhere, where they’re talking about what they’re working of and how they’re starting to think about this. But I haven’t heard too many stories yet, at least to my consultant brain, sound like, “Hey, there’s a very profitable opportunity hidden in here somewhere.” It feels like that might be a little bit ahead of the curve but this is for the markets that I tend to spend my time in. What are you seeing?
Rowan: I think you’re on the right track for where we’re on now. I’m definitely optimistic about the opportunities. We work a lot in the enterprise space here in Australia. We’re definitely not yet seeing widespread serverless adoption for their flagship application as much as I would to see it sooner rather later. But what we are seeing is a real pick up of the serverless toolset services by the developers themselves. It’s a real kind of grassroots movement.
We're also seeing a lot in the operational space, beside gear of having to run a server just to run a scheduled job every so often is starting to go away. As Amazon comes out with more and more features in the space, we’re seeing it being picked up more and more for the things around the core business applications.
Corey: In my experience so far, the enterprises are mostly adopting this initially as you mentioned here. It is going to replace the cron job. It’s going to wind up turning into something you can dip your toe into and see what winds up happening, and “Oh, okay, the learning curve is a little steep and what else were there? Wow, there’s a lot less for us to worry about.” And that starts to turn to, “This is an amazing hammer. What else can we hit with it? What else looks like a nail in our environment?”
Some aspects of that where it becomes a brilliant fit. Others where it’s not quite ready for primetime. We’re going to replace our mainframe batch scheduled jobs with a bunch of lambda functions. That’s 30 years of code, you’re staring kind of thing. Maybe that’s not the first project I would tackle.
Rowan: For sure, there’s definitely a lot to piece the maturity story there that needs to still be explored and organizations need to “go on that journey”. The things that I’m seeing a lot is there’s still a lot of misconceptions. One of the ones that I frequently see and like to call at is this idea of keeping functions warm, setting up a scheduled invocation to ping the function so that you don’t hit that cold start time. That for me is a real code smell.
I really want to ask a question, “Do you really want to use serverless?” In many cases, the answer is still yes. It’s still probably appropriate. But you need to change the way you approach it. People still approaching it with an old world way of thinking. Then you take a move towards a more event based and potent approach to how they handle their events and their inputs.
Corey: I think that right now we’re seeing a sort of evolution as far as how people interact with this. Oh, cold starts are problem so we’re going to have a second lambda function that just hits that on the schedule. I think you’re right, I think that’s a code smell but I also would argue it’s probably a temporary phenomenon. I believe I’ve seen multiple AWS employees talking publicly about how reducing cold start time is a priority for them.
Given that it’s one of the first things people start complaining about, I can’t imagine that it wouldn’t be. We decided to go into a room and ignore everything, every customer has ever said to us isn’t really the Amazon ethos.
Rowan: No, they’re pretty good at doing what their customers ask. I think about it, even in the last couple years that serverless has become a thing and even in that timeframe, I’ve seen the whole cold start discussion really dropped down in terms of the amount of air time it’s getting. It used to be a lot worse than it is right now, and with the increased competition in the space, I can’t imagine it’s going to slow down the right of the improvement.
Corey: What I found interesting about Serverlessconf somewhat recently was that Simon Wardley got up on stage and talked about how you can now trace the flow of capital through an organization that’s converted to serverless and that’s a really neat idea. The counterpoint is that even talking to startups that were born cloud native that never had any servers to speak of, and you take a look what their AWS bills look like, which is my bread and butter and everytime I see thousands of dollars in Lambda or API Gateway charges, I see hundreds of thousands of dollars or more in EC2 instances.
It isn’t anywhere on the radar right now for any shop I ever looked at as far as a major cost driver for what they’re doing. Even in shops that are pure Lambda and API Gateway, they’re seeing orders of magnitude, more spend just from things like their CDN, or data transfer, or data storage.
Rowan: Yeah, totally. The way I explained this – I was giving a talk about the local meetups here,. The days of the business handing over brown paper bags full of cash to the IT department to “solve their problems” if not gone, going the way of the dinosaurs, the idea that you would pay tens of thousands of dollars for server upfront, if you think about where these technologies are heading, it’s just going the same ludicrous in another couple of years compared to how it was just five or 10 years ago when you had to buy all the team yourself...
Corey: I think you’re also seeing scenarios where increasingly, IT groups has they tend to mature are no longer being given – I guess carte blanche for whatever it is they choose to spend money on. It’s not a go ahead and stop spending money.
I think you’re right, increasingly, there’s a sense in IT corporate culture where you’re no longer just throwing money over the world of IT and letting them do whatever they want to do. This is sometimes being misinterpreted as, “Oh, now finance is cracking down because we're spending too much money,” and I think that’s the case. I see that manifesting as instead is – spend whatever you want but you have to be able to explain what that money is going to. How much of is dev versus prod. Though they call it R&D and COGS. How much of that is tied to each project and how do we wind up doing a show back model to understand what impacts are current business.
I think that as that continues to grow, as a cultural phenomenon, that we’re going to start seeing significant advances in serverless shining a light on this. That said, today, I think we’re very far from a point where the spending of serverless is material in many shops.
Rowan: Yeah, for sure. I think this is where it comes back to the fact this are becoming more and more go-to tool for the developers out there. As developers play with these technologies on their own and get more familiar with it. I like to think about what’s going to happen to the next generation of developers. Those that have started their development careers with serverless is an option. For them, I think it’s going to be obviously just much lesser the big deal as those of us who remember the time before serverless is.
I think we’ll see that shift to paying on how you measure developer lifetimes and that’s obviously another conscientious topic. It’s going to accelerate as those hit the job market and become the decision makers.
Corey: I think this is one of those transformative moments where companies start to reevaluate how things get done. There have been evolutionary moments and there had been revolutionary moments and I think in some ways, serverless tends to wind up having a foot niche to those worlds.
Rowan: Yeah. You should talk to my marketing department. I think our latest tagline is “Evolutional Revolution.” I would have to agree to you 100% in this case.
Corey: It’s transformative to a point. I think that there is going to wind up being a lot of false starts in this space or people wind up looking at things like – okay, now we have developers writing code and throwing it over the wall. There’s no need for anyone in an operational capacity. All we need is people who know how to write code, there’s no value to historical sysadmins or similar. That winds up being dangerous past a certain point. There’s always going to be a role for having things interrelate, for understanding what’s going of under the hood, and when you’re this many layers of abstraction above what’s going on at the hardware level, diagnosing complex failure modes is going to require a tremendous degree of experience, expertise, exposure to this type of problems based.
What I wonder about is whether we’re at a position relatively soon where we’re suddenly going to wind up with large numbers of shops where when things break, people don’t really have that same level of hands on experience or exposure to it. Just because the path that most of us walked to become senior engineers or their equivalent today, isn’t really there in the same way. I talked about this in some of the early episodes of the show, when I had a lot of your listeners. I’ll hit it again, why not? There’s a question of where the pipeline’s coming from.
There aren’t too many jobs like they were when I was coming up. Where you go work in a help desk at an ISP or you go ahead and start working in a data center, and very quickly realize that humans don’t work well in giant neon lit rooms that are incredibly loud and cold and you could never tell what day it is or what time it is and everything feels the same. That’s how to create working environment. But you learn a lot in those moments. Where do you go to learn those things now?
Rowan: I think it’s a really good point. I’ve got to seem like I had a background as yourself spending some time in operations and then moving into more of a dev-based role. It’s going to be tough in general because the work that the operations staff are doing is going to change as well as that on differentiated heavy lifting gets moved towards the cloud providers. I think there’s a changing story there no matter which way you look at it. There’s a whole idea of managing fleets of service by hand is well on its way out at the scale and the enterprise end of town.
As to how people will get that practical experience, I feel like we’re saying a lot more sharing in the community around that. You’ve obviously had this topic in your podcast before and there’s so much good material out there today in terms of observability and things in the monitoring space. I’d like to think and I’m being a little bit optimistic, that the community itself will help drive this out. When you see problems of this nature, you’ll be able to go search and see other people that have had problems of this nature.
One of the first things that comes to mind is the open guide for AWS Slack Channel and also the address Slack Channel, these are really good resources for bouncing ideas of people and finding out, hey, what do I do? Where do I look? You don’t have to do it of your own.
Corey: I think that that’s always been something of the case, where you learn from the mistakes and experiences, triumphs, trials and tribulations of others. The challenge has always been where are those people hanging out. You’re right, I’ll throw them links to both of those Slack Team into the show notes. I’ll throw out link to the Open Guides Slack Team into the show notes for the Amazon Official Slack Team. Apparently, it’s invite only but if you talk to people of Twitter, they can usually wind up cracking open an invitation. It’s a somewhat strange model.
Rowan: Not the usual scalable approach...
Corey: Absolutely. Amazon does that for a living. Every time they wind up releasing a new service, they’re in a position where they’re going to go ahead and release something new and shiny that’s kind of okay, and over time, the features improve to the point where it goes from something that’s relatively shaky to something you might actually trust your bank to run and how long it takes depends greatly upon which particular service we’re talking about. I would argue that some that had been around for a decade now are still borderline on fit to purpose. But no need to pick fights I don’t need to.
Rowan: Another I wanted to talk a bit potentially about is the whole serverless development story. You’ve been very forthright and open with your serverless development experience both in your newsletter and on Twitter – the highs and lows. I think it’s been a really good thing for a lot of people to see, especially those with less of the development background. Those stories coming out through the community in all its forms, I think that gives people a real corpus of work to lean upon and do it for themselves. At the end of the day, there’s no substitute of doing it yourself.
Corey: I think it’s one of those problems where it’s very easy to wind up at an unfortunate place where you are suddenly talking about something that you’ve never touched yourself and that becomes a very inauthentic story. One of the things that I found most exciting about my own experience with working with serverless is I’ll mention how I built something and then people who are active in the space, people who work of serverless technologies at AWS look at me like I’m nuts when I would say something like, “Here’s a code pass so I can go ahead and run my Lambda function locally of my laptop for testing.” And they would say, “Why in the world would you do it that way? Just go ahead and run it in the Lambda environment and that’s all you need to do.”
That’s because I don’t necessarily want to dive in face first when I don’t know how deep the water is. I want to be able to run this thing in a traditional environment. If it turned out not being in a serverless environment was a constraint I had to deal with. In time I’ve gotten away from that pattern but early on, it felt like a very clear thing to do and I was very surprised by the push back I got from that model.
Rowan: Yeah. I’m really glad you mentioned it. Because one of the things I feel particularly conflicted about in the space, part of that is because if my geographical location. I definitely think that trying to mock the cloud...
Corey: I believe I’d mock in the cloud in my newsletter.
Rowan: ...Code smell doesn’t even do it – that I’m okay with. But we’ve seen a number of different projects out there, even AWs’s own same CLI that let you run at least parts of the cloud locally and for me, I’m always looking for ways to get developer feedback as soon as possible. It just makes sense of so many levels. By the same token I think it’s a bit of a slippery slope. If you start mocking out your Lambda runtime and your API Gateway environment, then the next step would be done DynamoDB and that opens up a whole can of worms that I wouldn’t recommend to any developer.
It’s one of those things where obviously some level of testing and maybe mocking is appropriate but it’s really hard to know where you should stop and then just move into the actual environment that you’re going to run in. It’s probably one of those cases where the first time you do it, you don’t know where that line is. It’s only after you’ve been burnt and after you got experience that you learn where that line is or that diminishing returns of investment is for the amount of setup and maintenance that you do in your dev and test environment.
For me, I think a lot of people for them that slippery slope of trying to get everything running locally and quickly tie themselves in knots. If you think about the testing pyramid where you have your base of unit tests, a smaller layer of integration tests and finally a very small segment of intwine tests, that really hasn’t changed in the serverless model. Some people think that maybe you should have more integration testing of you can since most of what’s running is not actually your code, it’s all the services. But I would argue that testing those other services is something that’s probably not going to be worth the maintenance required in the long run, you should still really focus of that unit testing layer. That’s where the most return of investment, is trying to develop as many...
Corey: I think part of the challenges generally going to be understanding the model when you first start. My first Lambda function was, okay, I hid a remote API, I grab a bunch of data out of it and then I shove that into DynamoDB. Since it’s an external input and it’s an external output, it doesn’t really matter where I run that thing. My initial inclination was to run that in the cron job of an instance I park somewhere. I already have a few of those sitting around, not that big of a deal but let’s go ahead and try this. To that end, the code that I wrote was still very much aimed at the possibility of being able to run it in that original environment.
As you wind up going down the road to other alternative models where okay, now, you wind up having this operate of a request that comes in at the edge. At this point you are well past the point where you’re going to be able to mock that locally to any reasonable fashion. Increasingly I’m starting to arrive at a model where running it outside the AWS environment makes less and less sense, given the nature of what I’m doing and now that I understand where the garb rails are as well as the limitations and constraints imposed by that environment.
It seems to make sense now to just completely avoid local development provided of course you have reasonable deployment methodologies where I changed a line of code, I pressed a button, how long until I see the output of that test run? That’s where it starts to get hazy.
Rowan: Yeah. I think the piece of advice that I generally have for developers getting started in that is definitely to focus on that automation. In the serverless model, you control so little of the actual environment that you’re running in. If you look at the number of configurations option of the Lambda function, there’s only really about half that doesn’t make an impact on it. There’s an extra config options that aren’t actually of the function itself. Things like concurrency limitations and that. They push the boundary a little bit. But really focusing of automating the parts that you do control, that deployment model like you mentioned are definitely worth the effort that it takes to do.
When you’re starting to really integrate with the AWS services, like you’re talking about particularly Lambda@Edge. For me, I think the piece of advice for developers getting started there is to really change the structure of your code and isolate those touch points. A lot of people think that I can write just the same kind of code that they run locally and then throw it up in the cloud. The more that will run definitely, you’re going to have a harder time testing it and trouble shooting it.
Really, letting the serverless model impact how you write code is a good thing and it’s something that I don’t see enough of in a lot of the material around it. I actually did see an AWS presentation that mentioned that specifically just the other day. I think these ideas are getting a bit more traction and what we realize is that we can still use all of the good things that we’ve learned about software development over the last 10, 20 years...
Corey: Right now I think the challenge is if you talk to any different group of people, they’re going to have their own opinions of what a best practice looks like. The consensus is that everyone else is wrong. I think that this is something that still needs to emerge as far as global somewhat half baked understanding of what you should be doing versus what you shouldn’t be doing. Otherwise you’re very rapidly falling to a model work well, every other shop except this one’s doing something wrong probably because they’re terrible. And it winds up tearing into schisms and arguments about stuff but frankly, doesn’t advance the state of the art any further than it already is. I don’t find those arguments to be compelling, I don’t find them to be interesting, I’d rather focus about work flows than spend time having pointless arguments about what framework you should be using to deploy your functions.
Rowan: Yeah. I couldn’t agree more. The Sydney committee said what you described sounds like software development in a nutshell, not even specific to serverless or any particular area. People have opinions...
Corey: Absolutely. And you see it now, with people who are focusing on containers and Kubernetes who are snering down their nose at the serverless movement. As if it’s some completely foreign idea that there’s absolutely no commonality between. There’s a lot of points of commonality. I think the different points on a spectrum and increasingly I think we’re going to see more and more integration points between them. But right now, there just seems to be this giant argument pile that isn’t getting people anywhere.
Rowan: Yeah. I see that a lot with some of that customers, feels to me like they have what I’ve affectionately coined the term kub hammer. They’ve heard about Kubernetes, they think it’s going to solve all their problems. The reality is that probably it will solve many of the problems I have but like most pieces of technology, it brings within its own set of challenges and when you get caught up in the hype, you can sometimes forget that. I think it’s just about understanding that continuum of options that people have when it comes to how they run their applications in the cloud, learning the pros and cons...
Corey: Do you find that right now there’s anything approaching a reconciliation between the container folks and the serverless folks? Or is that still going to wind up taking entirely too long to evolve?
Rowan: Unfortunately, I think it’s going to take a while. I think we’re still in the early days of both these technologies and we really have to play it out to see where it’s going to go. It does feel kind of strange when people are having these big arguments because these things are more similar than they are different. It’s just a slight difference in where the levels the expectations are and also how you orchestrate. But these things are muchness in the grand scheme of things.
I think we’ll see hopefully a better agreement on what jobs belong in what particular approach and that will make things easier in the short to medium term once people really get a handle of which kind of work loads perform better or...
Corey: I still think we’re in the early days of serverless. There is going to be a lot of changes that wind up hitting in the relatively near future not just in how people think about this but to the capabilities of the platform themselves. I have not heard anything from the Lambda team that implies that they are considering it a finished service, it’s now going to sit there as it is forever. Of course there going to be new enhancement made. Of course old constraints are going to move. It’s interesting watching that evolve and it’s interesting seeing what it turns into as that continues to grow. But from the other side of it, you often wonder how much of what we’re doing today with serverless is going to look like a constrained child’s toy in a few years.
Rowan: Definitely. I think we are very much in the early days still even though it’s been a couple of years. Some of the examples coming out in the last few weeks, things like Serverless Aurora, a really interesting change, and are going to give people a bit more to think about when they make that decision between service, containers, or serverless. I also think, as you’ve had some of your guest on the podcast already talk about this whole story about observability and monitoring in the serverless space. When you don’t control so much of the stack that you’re running on, it’s really early days in that space and it’s something of we’re looking forward to see what comes out, there’s a few startups in the space.
The other stories oversees security. Security is always incredibly important and there’s so much room for improvement there that, yeah, again I think when we see the next generation of developers come along who always have this as their starting point rather than wrecking and stacking servers as their default approach...
Corey: What astounds me more than anything else that I’ve seen in the entire serverless base was Tim Allen Wagner, the GM of Lambda, leaving Amazon at the height of the serverless craze to go work at Coinbase to sell bitcoins to people. I’m sure he has his reasons, I’m sure that there are a wide variety of things that make perfect sense once you see it, I’ve never known people at AWS to make foolish decisions intentionally. But I’ve got to say as something of a cryptocurrency skeptic, I am not seeing it.
It really feels like you can tie the words of blockchain, serverless, machine learning, Kubernetes, and service mesh altogether into one sentence and raise and entire seed round with nothing more than that sentence on a slide. I’m exaggerating but I’m not sure I’m doing it by much.
Rowan: I think they made a few enterprise architects out there form at the mouth here, hearing those words in one go. I’m tempted to do it...
Corey: Exactly. Wouldn’t even need to see your pitch, here’s your check and that’s just a disturbing reality I’m not sure I want to play in yet. But we’ll see. Where can people find more about what you’re working on? How can they find you on the internet? We’ll throw a link to that in the show notes.
Rowan: I blog occasionally at rowanudell.com. I’m of Twitter as well.
Corey: Perfect. We will throw a link to Twitter and to blog both into the show notes and see what winds up coming out of it. Anything else you want to share? Anything else you’re working on that makes for a good story that people should look into or be aware of?
Rowan: Just trying to get the whole development story out there for the serverless spectrum. I think there’s so many new bit and pieces coming out in the space and it’s really hard to keep up.
Corey: Sounds like the plan. Rowan Udell, I’m Corey Quinn and this is Screaming in the Cloud.