You can find Nick on Twitter as @TheNickVanHoof.
Here are the links to things we discussed in the episode:
For more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.
To learn how to build production-ready serverless applications, check out my upcoming workshops.
Opening theme song:
Cheery Monday by Kevin MacLeod
Link: https://incompetech.filmmusic.io/song/3495-cheery-monday
License: http://creativecommons.org/licenses/by/4.0
You can find Nick on Twitter as @TheNickVanHoof.
Here are the links to things we discussed in the episode:
For more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.
To learn how to build production-ready serverless applications, check out my upcoming workshops.
Opening theme song:
Cheery Monday by Kevin MacLeod
Link: https://incompetech.filmmusic.io/song/3495-cheery-monday
License: http://creativecommons.org/licenses/by/4.0
Yan Cui: 00:12
Hi, welcome back to another episode of Real World Serverless, a podcast where I speak with real world practitioners and get their stories from the trenches. Today, I'm joined by a friend of mine, Nick Van Hoof. Hey, man, welcome to the show.
Nick Van Hoof: 00:26
Hey, Yan. I'm glad to be here, man. Thanks for having me.
Yan Cui: 00:29
Yeah, so we've known each other for a little while now. I think from when we met for ServerlessDays Belgium a little while back, as well as the fact that you and I actually working together now on a client project. Small world.
Nick Van Hoof: 00:44
Yeah, true. Indeed, I think I even know you from further back, because when I got into serverless, you were already the big man in serverless world. So I joined ServerlessDays Amsterdam once, a couple of years ago to see you at work.
Yan Cui: 01:00
Oh, I see. Good, good, good. So I guess in that case, maybe we can start by talking a little bit about you and how you got into serverless?
Nick Van Hoof: 01:09
Sure. For me, I've been a software developer for four years now. And I think three of those have been in the cloud and in the serverless space. I actually didn't study as a software developer at school. It took me a very heavy fall on my head, literally a fall in my head to start doing software development. But because of that fall, I had to train my memory. And I took my books about Java and Python again, and I found it so interesting that I said, Wow, this is what I want to do with my life. And then I then I joined a consultancy company that was looking for developers. There, I found that I could not grow fast enough. So I joined another company. And they were working together with a lot of clients that did did a lot of work in the cloud space. And that's how I joined Nike, and at Nike, I really got submerged in serverless technology. And that's where I really found my passion and really build further on that with other clients, but also started out ServerlessDays Belgium, with a couple of friends here, and now really trying to build that serverless community in Belgium.
Yan Cui: 02:24
Okay, sounds good. So that's quite an interesting story. I guess, I haven't heard anyone telling me that they hurt themselves. And while they were recovering, and that's how they got into coding and but good for you.
Nick Van Hoof: 02:41
I think the passion was probably there already, a longer time, from from longer time ago, when I was a little kid around the year 2000. I was already building my own website about skateboarding and and then, in high school, I did some powershell scripting. But back then I had this friend, and he was so good at his stuff. He knew everything about computers, that I thought, Whoa, this is so hard. He knows everything. And I seem to know nothing. It's too hard for me. And then then I just followed my passion for engineering, where I of course, started a bit of software development. But it wasn't the main focus until that moment where I had life changing fall and I had to train my brain again. And from that moment on, it has been nothing but software development, actually.
Yan Cui: 03:29
Okay, that's good to know. And I guess you got start in the right place, you go straight into the clouds. So you didn't have to go through some of the, I guess, the painful learning process of working with machines and configuring machines and all of that, you know, you start with the good stuff.
Nick Van Hoof: 03:49
Yeah, indeed, of course, I saw also some legacy stuff that declined. But it is true that I have definitely gone into the cloud immediately from start of my career.
Yan Cui: 04:00
So I guess, coming straight into the cloud and learning coding at the same time. What were some of the biggest challenges that you had? We've had quite a few people, I guess, on this podcast talking about similar experience whereby they went through coding school, and then they go straight into, like a working environment, working with a cloud and how quickly they were able to, I guess, get up to speed. But what were some of the sort of challenges that you faced along the way?
Nick Van Hoof: 04:28
Yeah, indeed. That's a good question, actually. Because I think that sometimes people don't mentioned the challenges that are that are actually there for people that are new to it. Because you always have this learning curve, of course, and certainly for me, when I got into programming about five years ago, when I when I was still like, let's say, a little programming noob I had to learn everything, right? So the first year was quite hard because I had to learn all different languages and took me a lot of time to get it all done. And then came the clouds, where you have all this infrastructure and all those services and all those things that you can spin up, and that you can leverage from the platform. But you don't know how they work. So that is something that I think all people that get into cloud technology should know that there is still a learning curve, about getting to know the best practices for using those services. And that's also with serverless it's the same thing. Serverless actually, I think, allows you to really leverage the platform and really glue together all of the services from a cloud. But to use them in the right way, you of course, have to know the best practices and you need someone with experience for them.
Yan Cui: 05:48
Yeah, I mean, even for experienced engineers coming into the cloud and AWS is overwhelming. I mean, nowadays, there are just so many different services, many of them are doing something similar. So just be able to choose the right service, let alone unknowing, and how the service works and understanding all the best practices around it is challenging even for experienced engineers, let alone someone who is learning everything all at the same time, I do understand that can be overwhelming. I guess, one of the things that I think definitely is definitely helpful, is if you focus on just one or two things at a time, rather than trying to learn everything, of course, everybody learns differently. But I find that if you start by saying I want to build a simple ecommerce app, and then just finding out gradually, one piece at a time, what are the different pieces you need, you know, I need to have an API and therefore, look at API Gateway and Lambda. I need to have something in the database to store all this data is about the catalogue of products and all that look at DynamoDB. And then learn gradually, that way, I think it limits your exposure to how many different moving parts there are in AWS to small pieces at a time, so that you get to learn one or two things, get some experience, get some mastery first and then open, open yourself up to gradually more and more things. But otherwise, it can be really overwhelming if you look at all these hundreds of hundreds of services in the in AWS and trying to make sense of them more.
Nick Van Hoof: 07:21
Right Indeed, I think the way that you said it's a bit more structured way of learning of climbing the learning curve. And it's not what I did back then I really had this thing, they call it shiny object syndrome, where you see something, and you immediately go deep into it. And then you see another thing, another shiny thing that you go towards, and that you want to know everything about. And then of course, there is a lot of stuff to learn at a very short time. And when I look back to that, it was a heavy period big then to get it all done. But of course, it also gave me a lot of knowledge about all the different things that were available. And that is also something that I benefited from later in my career, because I already was oriented in a lot of different services, that I was able to learn them deeply, quickly afterwards.
Yan Cui: 08:18
Yeah, I do think, you know, if you personally, at least my learning is, I guess it's not equally distributed over time, they tend to come in the very intensive bursts of maybe 6 to 12 months when I'm working on a new project and have to try something new and have a have to learn a lot of things all at the same time. And I do enjoy those. But I don't think that's that's quite sustainable for a long period of time if you're constantly being overwhelmed by how many things you have to learn all at the same time, you can be quite stressful.
Nick Van Hoof: 08:52
It always will stay that way. Even when you it's like you say when you're experienced when you have all this expertise, then you get a new project. And you again have to solve new problems. Because that's that's what we are actually, we're just problem solvers. And there, there will always be problems. So even now that I have a lot of expertise. And when I'm facing a new challenge instead of a problem, but when I'm facing a new challenge. I takes me, it takes me some time to understand the challenge and to see what is the best fit and what is the best technology to use. And it's difficult for for programmers, I guess. But at least for me, it's also what keeps me awake at night. So just being so passionate about the job and about solving those challenges that that that you can hardly sleep because you know that you're facing something and you want to find that solution so badly.
Yan Cui: 09:50
Okay, so I guess that's a good, good point for us to maybe switch gears a little bit and then talk about some of the work you have been doing using serverless components and running on AWS. You were with Cloudway until recently, maybe tell us a little bit about the work that you've done there, and maybe what you're doing nowadays?
Nick Van Hoof: 10:09
Yep, true. So if I look at the first serverless project that I've done, and of course, not specified all the details, but it it was an event distributing platform. So let's say that you make an order, and check that the order has to be dealt with within the company. So stuff has to be gathered from from from the stock, some things are not in stock, we have to send updates to the client, you have to send updates to the people that will deliver the order. And all those events have to be distributed within within the company and towards external companies. And that is a that is a platform that I've worked on, and that we fully built upon serverless components and cloud components. And then I'm talking about API Gateway with Lambda functions, dropping things on Kinesis streams, and then distributing those events further within within the landscape. So that is the that is the first project that comes to mind. I’ve done things that came later on. For example, I worked on a data foundation where we had this GraphQL API that was linked with not only we have a lot of resolvers to get the data, not only Lambda functions, but also just other APIs that were then picked by by container services. But that also ran on AWS, though it wasn't fully serverless. Like I said, we also did not use AppSync at the time. But we ran our own GraphQL server. So that are two examples. And another interesting project that I did actually was analysing the traffic in Belgium, with serverless components, so the Belgium traffic agency, they have this API that publishes data about the traffic in Belgium every minute. And that's, that's an eight megabytes blob of data that we then split into smaller events, and we threw them on Kinesis Firehose. And then we go on to post, do analytics in real time with Kinesis analytics, and then send out alerts, if there are traffic jams with Lambda functions. But also, we lent the data on S3 and then use that as a data lake to do batch processing on with Athena and long term reporting.
Yan Cui: 12:53
So there's quite a few different services you've just mentioned there. So you talked about GraphQL, you talked about Kinesis, and S3, and Athena. Was the Athena that you were using to do the real time analytics.
Nick Van Hoof: 13:10
No, the real time analytics, we were actually doing with the Kinesis analytics application where you can can write, we chose to, to write SQL. And then you can do those in application streams that can analyse the data that is flowing over your Firehose in real time, and then make aggregations upon those streams. And then from that information, we trigger the Lambda function and update the state in DynamoDB. To specify there is a traffic jam here or there is no, the traffic jam has been resolved.
Yan Cui: 13:48
Right, I see. You are using Firehose Kinesis analytics for that. Okay. So usually, I think I've seen people use Kinesis analytics with data stream instead of Firehose, but I guess that also works. So in that case, does Firehose trigger Kinesis analytics once the batch size has been met? Because I guess that may have an impact on how real time which we're talking about, because data Kinesis data streams, so you're going to get data right away. But with Firehose I think they only fire when either the buffer size be met or the time window has been met.
Nick Van Hoof: 14:25
That's right. And I think the smallest time window that you can set this, like one minute, so that is true. It is near real time, but there was there was about one minute and a half delay on those alerts. But of course, those alerts were about having a traffic jam emerging in a certain place. And a traffic jam is typically there for longer time. So that is that is a delay that we that we could live with.
Yan Cui: 14:57
Okay, sure. That's fair enough. And I guess you also, let's talk about the GraphQL side of things. So that was using I guess running a GraphQL server on EC2. But have you since then been using AppSync instead? Because I find AppSync with Lambda and DynamoDB to be a really, really powerful and very productive stack, as probably my default my favourite nowadays.
Nick Van Hoof: 15:23
Yeah, I think Yeah, people need people should definitely learn learn about that. It is true that that back then we ran our own server. Now we use AppSync in the projects that I do now. It's the project that we are working on together, but also the project, which I haven't mentioned actually. And what I'm doing right now, my most of my time is spent in my own startup, where we make a DMS system. So that's a transport management system for everybody who does container transport. And that's all backed by Amplify. And with Amplify actually provisions the AppSync server for us. Amplify is like a bunch of things together. Amplify is a CLI tool to provision infrastructure as code. It also has libraries that are front end components. But if you go into that CLI and Amplify you provision, for example, a GraphQL API with Amplify, then that will be an AppSync, that will be AppSync behind it. And then out of the box, it will it will give you a lot of... it will always try to give you VTL resolvers, so to resolve your data, but of course, then not everything can be easily written in VTL. For me, it is a challenge also to test those VTL resolvers. And then, of course, you have to provision Lambda functions to do the harder stuff to resolve the data in your API.
Yan Cui: 17:05
Yeah, so I think with AppSync, it makes going direct to DynamoDB so much easier. And if the... I guess they've been talking about use, supporting Node.js, or some limited version of Node.js, as a scripting language as opposed to VTL.
Nick Van Hoof: 17:26
Yes, I heard the talk about that. But that's already a long time that I heard that talk and it's not there yet. Or do you know more?
Yan Cui: 17:35
Even if I do, I can't tell you. But they've been talking about it publicly for a while now. So hopefully, it will happen sometime soon. So there is another extra week of re:Invent in January. So we never know. Maybe it will get announced that during that week. But but yeah, that will make life even easier for anyone who's thinking about doing more interesting stuff without having to go through Lambda, which like you said, right now, if I'm doing anything beyond some basic CRUD, I tend to use a Lambda function for that. But if I can write more, I guess, more complex code in the in the request and response template itself, then I'll be tempted to do that. Because that was sidestep having to have a Lambda function and the extra cost invocation time and the cold starts, which will help make your application more responsive. But yes, hopefully, that gets announced this soon. And that will make life a lot more interesting, I guess, for a lot of people, because VTL is not something that most people like to use.
Nick Van Hoof: 18:41
When we're speaking about GraphQL, I think also an important point to mention is that a lot of people in my environment, they're actually kind of afraid of GraphQL, because they don't know what it is, and what the advantages are that it can give you. And I think that also maybe hinders the importance, the the the adoption of something like AppSync. Is it something that you also face, or is it only in my environment?
Yan Cui: 19:12
So for my experience, it hasn't that really the problem. There are a lot of people with GraphQL experience out there, maybe the two communities haven't quite intersected quite as much as you as you would like. Now you've got your JavaScript community who's really been big on GraphQL for a number of years now. If you look at the Google Trends over the last couple of years, GraphQL is really up there in terms of interest. In terms of people that actually use GraphQL and on the running stuff on AWS, maybe there's much smaller intersection there, whereby you got a lot of people doing stuff on AWS, but still building RESTful APIs with API Gateway and Lambda. So there are still some a lot of I guess a lot education needs to be had. But based on the demand interest and uptake in my new AppSync masterclass video course, I would say there's a lot of interest there for people to learn more about both GraphQL, but also AppSync.
Nick Van Hoof: 20:13
I think that people definitely need to check out that course. That's true. And yes, what you're saying might be true, because I actually have come more from a Java background and the Java community, and maybe there is a little less fuss about GraphQL, than in the JavaScript community.
Yan Cui: 20:30
Yeah, I think the adoption has been much, much stronger in the JavaScript community than the Java community. Not sure why there is maybe because the reference implementations for GraphQL servers, all of that was initially in JavaScript, and I guess, I also, I think GraphQL is great for those client facing applications. Like if I'm using something something like internal APIs, I probably wouldn't use GraphQL for that, REST works just fine. But when it's something that's consumed by front end, then the GraphQL makes a lot more sense. Because the the advantage that the GraphQL gives you in terms of how you solve the n+1 requests problem, and also being able to minimise the amount of payload that have to be returned to the front end, where the front end can decide what data points they actually want from the back end. So all of those things probably means that teams are focused more on the front end, or a full stack team will be more likely to be using GraphQL. And also more likely to take advantage of it. And those teams are probably going to be using JavaScript because the front end is already in JavaScript. So maybe that's why you see more adoption in the JavaScript community compared to the Java community.
Nick Van Hoof: 21:49
True. And let's also let's also not forget the the fact that GraphQL allows you to do it in full introspection of the the API, which I find very useful, because the API actually documents itself because you can just introspect what what can I ask for here, what data can I expect? That's something that is that comes with GraphQL.
Yan Cui: 22:13
Yeah, absolutely, absolutely. That whole self documenting aspect of it is great. And also, it's not just documentation, like you have with, I guess a lot of Java frameworks or other frameworks have the ability to generate API Docs. But the documentation itself is also binding in that this type check and everything so that you don't have to do additional validation in your application code, which makes life a lot easier. And one thing I really like as well about AppSync and GraphQL, is that, and I don't have to worry about the doing response validation. You see things like API Gateway, you know, you can specify a request model. And that, that delegates to API Gateway to do some requests validation to make sure that the users can’t send you invalid requests. But you can't do response validation, you can't tell API Gateway to do response validation. You can attach a response model, but that's only used when API Gateway generates the documentation for your API, it doesn't do any validation. So a lot of time when we see people are able to extract data from your APIs, doing some kind of injection attack, maybe SQL injection attack, they could have been prevented if the server was doing response validation and making sure that it's not returning data that an endpoint shouldn't be able to return. So that is quite useful and quite important security aspect to it. But it's something that you have to yourself, because API Gateway just won't do anything. Whereas with AppSync and with GraphQL, because you know, you are creating a type for the response, it’s much harder for someone to execute those kinds of injection attacks and get the data they want to form the application because your application literally cannot return data that is not on the response type. So that is that's an aspect that I think is really, really makes your life a lot easier when you're working with GraphQL in the AppSync.
Nick Van Hoof: 24:15
Yeah, true. I think in the past when when using REST APIs. We have solved that because we documented our APIs using Swagger. And then we also validated the responses coming from a Lambda function. We validated the format of that response against the Swagger specification before we actually sent back the response. But then you of course have to do the implementation yourself. It's not something that AppSync like AppSync gives you that.
Yan Cui: 24:50
Yeah, absolutely. So you know, you can do yourself and I did that before as well using Middy and Middy which is the middleware engine for JavaScript Lambda functions. And one of the middlewares is the response validate or rather just validator middleware, which lets you validate both the request and response. So you could do it but it means something that you have to do yourself, which means that a lot of time people just won’t because either they haven't thought about it, because you have to consciously think about this to even know to do it. And also, sometimes just actual work that you may not think is worth it, until eventually you got hit by an attack.
Nick Van Hoof: 25:29
Yeah, true. And I think that's also what the serverless mindset is about, it's about if a component or a service can do something for you, then use it because probably, they have implemented it even better than you can do it on your own. And that is, it is a mind shift that I saw that needs to happen in a lot of companies also, where people tend to do a lot of things themselves, and they want to take everything into their own hands. But if you design according to the way that the platform can be used, and you use the platform in such a way, that actually takes a lot of work out of your hands, that is where it really starts to pay off, showing that serverless mindset and using serverless technology.
Yan Cui: 26:21
Yeah, so that's I think, a lot, well, a lot of people call that service for mindset where you try to do you try to use as many managed services as you can. And also you try to delegate as many responsibility to those services as you can as well, so that you can focus on just the things that's important to your customers to your business. And I think that's that's the mindset that really drives a lot of productivity that we see people are getting nowadays, when they are using serverless components. Because you just have less to do, there are less for you to do yourself, and therefore less chance for you to mess something up. Because like you said, if something if AWS is doing something for you as part of the service, then there's a good chance that they're probably doing better. Because they have more dedication, more focus on doing those things, as opposed to you where you have to, you know, your focus is on serving the needs for your customers.
Nick Van Hoof: 27:19
Yes, yes, indeed. And, and I think that is also the same, that is the story that I'm also preaching everywhere. And that is also the story that we're trying to preach with ServerlessDays Belgium, for example. But you can only tell the story so many times, and then it just becomes the same story over and over again. I think people really need to see the advantages by showing them real world examples. And that isn't indeed by talking about those examples in this podcast, but also by having people on conferences from companies that have successfully used the serverless mindset or serverless technology, and that want to bring forward the story and that want to inspire other people to also follow along in use that same technology stack.
Yan Cui: 28:13
Yeah, absolutely. We like, we love stories, right? And we are probably convinced by stories more than anything else. And speaking of which, the project we're working on right now, this, I guess, social slash sports app where people can organise self organised-activities together and you can book classes from universities who attend, I guess, when once the lockdown is finished, you can attend the basketball classes, Zumba classes and whatnot. That was done by myself working part time for a couple of weeks for the client. And in that time I was able to set up the entire AWS organisation, set up an SCP, service control policies for security setup and log forwarding to a centralise the audit account and audit bucket and all of that, as well as the building the actual application itself with GraphQL, AppSync and Lambda and DynamoDB, all that in just a few weeks. And I think now that you've come aboard, you've seen the size of the application is not trivial, right? It's actually quite a quite a big piece of application with lots of different moving parts and lots of different features.
Nick Van Hoof: 29:30
That is true. And you're only able to do all of that work in such a small period of time. Because you can rely on the platform and you can build on those proven components. And that is what, what makes you go that fast, fast, and also high quality of course, because those things are often hard to combine. But when we use this when we use serverless technologies, and we leverage those services from the platform, then we can actually combine that speed and the proven quality of those services to really bring down that time to production for a product.
Yan Cui: 30:11
Yeah, absolutely. And of all the things that I've heard people talk about in terms of, you know , these are the biggest challenges for my, for my organisation, pretty much everybody talks about speed, talks about agility, talks about how long it takes to deliver a feature or some or some value to their customers. And I think this is where serverless has the biggest value to businesses is just in it enable your teams to do things faster. We often talk about the cost benefit, but for a lot of companies, you know, the cost is so heavily skewed towards engineering time and the market opportunities that saving, I don’t know, a couple of hundred dollars a month or a couple of thousand dollars a month just means nothing to them, because they're spending hundreds of thousands dollars on engineering time. So if they can get more done with fewer engineers, or just more quickly with the engineers they already have, that's that's where most of the savings are coming from.
Nick Van Hoof: 31:11
That's true, I think also the project that we are working on together, and also looking at my own startup, where where we are working with with people on that project, if you look at the costs, it's almost all, costs are all made because we have to pay people and we have to pay developers, but not actually the cost of the cloud services compared to that cost for people is negligible. And I guess that's what you're saying.
Yan Cui: 31:40
Yes, yes. And the bigger the bigger the company, the more like I guess the the more heavily skilled they find those costs are leaning towards engineering time. And I'm paying for people paying for a, I don’t know, bonuses, paying for heating and paying for office space, all these costs, these are all around having the people, engineers in your in your company, and being able to deliver, I guess. So those are, those are the most, those are your most valuable, and also most expensive resources and being able to get more out of those resources and getting them to focus on solving the most expensive and most valuable problems that your company have. That just makes, that's just a no-brainer, I think from a business point of view. And having seen this, I guess, this, some of these turnarounds, I've seen both small startups, like the ones we're working on, as well as the large companies like LEGO, like Capital One. I think I'm 100% convinced that this is gonna be the way. This is the way we should be doing things now. And maybe in the future as well, until maybe something even better comes along, who knows, maybe in 10 years time, we can just tell an AI, “Build me something with these requirements.” And then they will just go and do it.
Nick Van Hoof: 33:00
Yeah, I think you're totally right. The only sightmark that I have to make there are from my point there is that if company is totally new to the technology, I trust what I said before, then they really have to look for an experienced consultant that they can hire for a couple of months to introduce their people to the platform and to really get over that learning curve a lot quicker, because that is very typically lose time in the beginning. Because you implement things not in the right way just because you don't know how to do it, or what is the best practice.
Yan Cui: 33:39
Yep, yep. And that's why that's why business has been pretty good for me. There are a lot of companies are looking at this journey, and like you said, is investment. But I think the return on investment is definitely worth it because once the teams get going they can be really productive. And from my experience, a lot of teams that are able to self-learn a lot of things and as far as my involvement is concerned, is mostly just giving them the right, you know, nudge the point in the right direction sometimes, because they either haven't thought about some other approach because they only working with the services that they understand that they know, or maybe they just haven't are unaware of some of the newer features in the platform, or some best practices, like you said, but those things are often quite easy to to convey. And I've got a lot of blog posts I can point people to as well. And I've also been running training and workshops so that so that people can get up to speed quickly. And I do think that, you know, this has been picking up pace. The last couple of workshops have been running has been pretty much fully booked every single time and I do see a lot of people are constantly asking me questions about what are the best practices for this and that as well. And I think that is I think that's a good sign that adoption is speeding up. And it's not just me. And I'm also seeing more and more people starting projects using serverless components and getting help from other people like Jeremy Daly, like Ben Kehoe, and other people on social media as well. So I do think this, this adoption is picking up. And hopefully, we see more and more people do more for less by going cloud the right way.
Nick Van Hoof: 35:25
I'm very happy to hear you say that. And it's, yeah, it's actually, it's quite amazing the work that you do for the community and with the workshops and the blogs, and then the work for clients. I already told you that I'm often wondering if you're actually only one person. And now that we are talking about the serverless and serverless adoption here, I think this is also a good moment to debunk some of the serverless myths, because sometimes I hear a lot of first about, for example, cold starts, or first about architecture, difficulties with serverless applications, or difficulties with observability. And those things, they're actually not problems, but people... That's why I say that they're myths, because people just think that they have, for example, let's go into the cold starts, people often think that they will have a cold start problem. But then you can ask yourself, “How many cold starts do I actually have?” If I am using this technology to scale up and down and I probably have a lot of requests, let's say 100,000 requests per day, how many of those requests will be cold starts? Probably very little. And even the cold starts are there you can then tackle that with things like Provisioned Concurrency, or choosing the right runtime for your user facing APIs to bring down the cold start time. But even there I think that it is an overestimated challenge, and that it's actually more of a myth.
Yan Cui: 37:05
Yeah, that's right. I mean, I've used so many different applications using Lambda, and with API Gateway or AppSync. And the cold start is really a problem, because like you said, just, you only affect a very small percentage of the requests for an application that has got even just a very moderate amount of traffic. And also, if you use Node.js, my cold start even when they do happen, it takes about 300 to 500 milliseconds, which is well within the SLA for my application, which typically for web, for web applications, you're looking at one to three seconds on the 99 percentile, which is something that you can definitely do easily using the right runtime. And even when you can't, for example, maybe if you got an enterprise environment with lots of API to API calls, then well, maybe you can use the Provisioned Concurrency to prevent those cold starts from stacking up so that when a microservice calls other microservices, you don't pay the cold start penalty multiple times. Or maybe you have such a legacy code base that you want to port into serverless. And you don't want to rewrite millions of lines of Java Java code, then the Provisioned Concurrency is there now. So there are solutions out there. I think like you said, with observability, with, I guess, complex architectures, there are solutions to all of these already. We've been we've been doing this for five years. But it's just a case of education that if you're coming new to serverless, you’re coming new to Lambda, you may not be aware of the solutions, you've heard about the problems or potential problems, but you haven't yet educated yourself enough to know that the solutions are this and solution are that based on your situation.
Nick Van Hoof: 38:55
Yes, indeed, for for example, for observability, I have seen, while I worked in project where we tried to implement all the observability ourselves. And while you can do that, again, someone else has already done it probably. And it's very good to rely on trusted partners, like Lumigo like Thundra, who give you solutions to, really have observability over your serverless landscape. And you really get a lot of advantages when you use those, when you use Lumigo for example, and Thundra too, because you can see all the events that came into your Lambda function, you can see many details about what went wrong and it's very easy to get to the core of the problem. Whilst if you're doing that yourself and you're you're trying to implement that observability yourself, you will have to pass along trace IDs all over your landscape and it will be your responsibility to do that. Instead give it to a platform like Lumigo, or Thundra, or other companies that are out there that can do those things for you.
Yan Cui: 40:09
Yeah, compared to like a couple years ago when I first started working with Lambda, the tooling available nowadays is just so much better so easy. Like with Lumigo, you just, with the project we're working on, you just install the serverless framework plugin, and then configure your Lumigo token. And that's it. Everything gets auto-instrumented. Like you said, you see the traces in the Lumigo console, you see the input and output for every single HTTP request as well. If you make a request to RDS or Elasticsearch via WebSocket, sorry, via sockets, you see them as well. And you just don't have to do anything yourself. And it makes life so much easier when you don't have to do all this manual instrumentation. And in fact, for a lot of the applications I worked on, I would say the observability is probably even better than some of the other serverful applications I've worked on in the past, whereby now we rely a lot on the logs. And we're relying on the a lot of manually logging, “oh, we are doing this, and this is a request we received”. Now I can just see every invocation for Lambda function and see exactly what the payload was. I can just easily grab that and put it into a JSON file, and then invoke my function locally, and step through the code as well. So tooling is there now, again, it's just about discovery, is about education, is about making sure that people are aware of those choices.
Nick Van Hoof: 41:34
Yeah, true. And again, they're the time that you will spend, if you have to do, you go to, if you have to go through your logs yourself, that will take you a lot of time. And the time that you will lose there is probably already a lot worse, a lot more than just paying for a monitoring tool.
Yan Cui: 41:54
Yep, yep, no arguments there. The whole reason I'm able to support multiple client projects at the same time is because I don't have to spend too much time finding and debugging things, I can just go to the Lumigo console and just look for what I want pretty quickly. I guess another aspect of that is, I mean, some of these tooling may seem expensive. But at the same time, when you look at some of the prices for Datadog and other other services like that, they're also not cheap. Datadog is really expensive based on the price model they have, which is something like $5 per resource. So when you get a small application, as you scale up, as you get more and more things, it gets really expensive really quickly. And also you don't get as much out of it as you do with some of the more specialised solutions you have for serverless applications like Lumigo, like Thundra as well. So I definitely think there's a lot of value to be had with these tools. And if you use them, then you can get you can get again, more focused on the things that matter to your customers, and less time worrying about how am I going to debug this, what tools I am going to, how I am going to get observability into my application so that when something goes wrong I can debug them quickly.
Nick Van Hoof: 43:16
Yes, indeed. That's what it's all about. True.
Yan Cui: 43:20
Um, so are there anything else that you've been working on? I know, you left Cloudway. We're working together now. But you are starting a new venture as well, aren't you?
Nick Van Hoof: 43:30
Yeah, right. Yes. What I mentioned, like I mentioned before, I started the company, a startup company, actually, that is building a transport management system for everybody who does container transport. And so that is about, yeah, if a container arrives in the port, and you have to pick up that container with one of your drivers, or one of your subcontractors have to pick it up there, they have to deliver it somewhere. And you have to do the whole planning and planning around debt, invoicing around debt, or communication with your drivers via via net for example. That is something that we are trying to facilitate with our platform. And then even going a step further, of course, because what I just told you about that, of course already exists that we want to make the difference by having a lot of integrations with, for example, the ports, or your clients. And that way we can automate a lot of things and take work out of your hands, and which means that you can just do more work, which means you can do more business, and which hopefully means that you can, you can get more money out of it. So that's what we're trying to build. I'm spending actually, like, all of my waking time in, in that company next to the the, there's a bit of sports that I still do. But but as I said, I'm so passionate about the technology and about building a solution, like the one I just talked about, to, to give people the opportunity to do more business to just enable, enable people with IT services. And that is the passion that I found. And that has not left me since the last five years, I think. And it's, yeah, when you're doing what you love, what you love you, you're never working, they say, and that's actually what it feels like for me.
Yan Cui: 45:33
That's good to hear. And best of luck. And I guess I know your stack is so serverless. Anything you can tell us about what your application looks like from the from that point of view?
Nick Van Hoof: 45:45
Yeah, sure. Yeah, you're completely right, it is fully serverless. So we, at the moment, we provision the infrastructure using Amplify, which is the framework or the the set of services that I talked about earlier, where you have this Amplify CLI that you can use to, to build CloudFormation stacks with. And then within that infrastructure, there are, there is one big GraphQL API with with resolvers behind it. On the one hand, those are VTL resolvers. On the other hand, those are Lambda functions, then your whole planning, all the transports you have to do, everything that you have to manage as a business are stored in DynamoDB tables. And then we listen on the change streams from those tables to to trigger asynchronous jobs to send out notifications, to send out reminders, to update clients, to to notify drivers, but also the other way around. We're using subscriptions to to know when driver, for example, posts a new message to us. There's a new an update from that driver, and it can arise in real time in the app. Um, so I think that is, in a nutshell, that is the technology that we are using.
Yan Cui: 47:27
Okay, so Amplify, well, I've heard a lot mixed things about Amplify. Personally, I haven't been using it partly because it’s, some of the things that I've heard from clients and from friends worries me a bit. But from what I've heard, Amplify teams are working on addressing them. Some problems, such as there are some changes you may want to do because underlying it is still using CloudFormation. And sometimes you create changes that CloudFormation will not want will not be able to update, for example, when you got multiple Global Secondary Index updates, which I think they've just released a change so that they can actually do that by doing multiple CloudFormation deployments instead of just trying to do them in one. But also, sometimes I've heard people talk about how they struggle to customise things, because the resources are all kind of provisioned by Amplify and they, they don't really have easy way to then modify some of the configurations for those resources. Has that been your experience as well? Have you run into any problems with Amplify?
Nick Van Hoof: 48:37
Yeah, I heard those stories too. I must say, yeah, for the for the Global Secondary Index problem, I think that is also that is also something that's come from DynamoDB. You can only update oneGlobal Secondary Index at a time, I think I think it is, isn't it right? Is it an Amplify problem, or is it a DynamoDB problem?
Yan Cui: 48:58
It’s probably a DynamoDB problem. That's also reflected in the CloudFormation that CloudFormation can only update one index at a time. But because of the fact that those indexes are created by the Amplify, so when you're making a change, you're not explicitly or at least you're not maybe consciously making those changes so that it's harder for you to plan them so that when it comes to running Amplify, I forget the command, Push? Publish? Yeah, so that's the only time when you realise Oh, right, this is creating a Global Secondary Index, because the whole...
Nick Van Hoof: 49:32
That is true indeed. That is something that I had to be aware of, because I also ran in into that. But for other other examples, I think the team, the Amplify team, and the community is really dealing with those. I heard the stories too. I must say I've not run into a lot of those problems. Something that comes to mind is maybe having different environment variables, environment that wasn't that wasn't totally clear to me how I could do that. But then I found a solution that if I actually fetch the environment variables from the parameter store, and then I can configure them per environments, but yeah true, there, I had to do some some some research. And another things that comes to mind is the the fact that at the moment, it is possible to run an Amplify application on different accounts. And what I mean by that is, you have a dev account for your dev environment and your your, your feature branches, for example. And then you have a QA account for your QA environment, and you have production account, you can do that. But the documentation about that was not was not too good. So I had to figure that took some figuring out my own to get that done. Because what you will read in documentation is that they always spin up the dev environment, QA environment, the production environment, on the same account. While of course, that is not really the best practice for really go into production with a with a larger application.
Yan Cui: 51:09
Yeah, all the demos I've seen off Amplify’s always within the same account as well, which is not what most people do. And also not what AWS itself recommends as well. They recommend at least having one account per environment, sometimes per developer. So having, Amplify, I think the team should be maybe demoing how to do that in a multi-account setup. Because that is also a question I get a lot as well, you know, you know, I want to use a multiple accounts, how can I do that with Amplify? And I also had to figure out myself how to do that.
Nick Van Hoof: 51:42
Yeah, yeah, that's that is true. But but it is certainly it is possible, of course, because I have such a setup running. It’s working flawlessly now. So maybe I should write a blog about it. And then, because, you know, I spoke about challenges with Amplify. But I also feel that is the actually all the positive that I get out of it, is the fact that over the last three months, when I was building this new platform, it really felt like I was able to do the work of a whole team on my own. And that is not because I'm such a good developer. No, no, that's because because the platform and because of Amplify, that gave me so many things out of the box that allowed me to go this quick. And then I have to say, in relation or comparing with the few challenges that I faced, I am still very happy at the moment that I chose Amplify to start building out and to start proving my product.
Yan Cui: 52:44
Yeah, so let me know if, how the how that goes in the end. Because I'm quite interested to hear the I guess your story once you've got this product running, and maintaining over time. And what are the challenges you run into with a framework like Amplify which hides a lot of details for you, which is, I guess one of the aspects of the challenges that people have is just when you want to customise things that is not obvious, or you may not be able to do it because of whatever has been provisioned by...
Nick Van Hoof: 53:17
Yeah, yeah, that is true. What you're saying it does a lot of things for you. And it feels like magic. It's not magic, of course, because if you go look underneath, you can find all of the CloudFormation stacks and how how they are built. But I can understand that for someone who does not have the years of experience like me, with the cloud platform to build them. If you then go look under the hood. And you look at all those things that are provisioned for me. Now I have to find my way through them because I have to do something custom. Yeah, of course, then again, the learning curve can be high. But in my situation, that is something that I haven't, that I haven't specifically experienced. Because even when I had to look on the road, you just find CloudFormation that you are familiar with.
Yan Cui: 54:08
Yeah, actually I think someone in your position is much better suited to using a framework like Amplify, as opposed to someone who is completely new to AWS, to CloudFormation, and don't understand the work, how CloudFormation works, and how to configure different resources. Because then you're in a position where you're automating things you don't understand. And the moment you need to do something and to understand how things work under the hood, you are stuck in the same way that if that's what you after that automation, then you should be using something that's a completely managed service instead, rather than abstraction layer that hides a lot of complexity from you, but still exposed to all the limitations and constraints of the online platform. In the same way if I’m using a toaster, you know, I don't need to maintain it. I just want to use it and when it’s broken, or when I need to fix it, I just get a new one instead. I can't do that with my production application. So so I think that i think that i think there's some difference there. If you are automating things with the Amplify framework they really don't understand, then you will need to hedge their risk by trying to invest into learning about the underlying platform and how they work. Otherwise, you're just waiting for something bad to happen.
Nick Van Hoof: 55:28
Yes. And when it happens, you don't know what to do. Because you don't you have you're not familiar with the things underneath.
Yan Cui: 55:35
Yep. And at the time when those things happen, is often when you're in the most time, time sensitive, a stressful period as well, is when something has gone wrong how do you fix it?
Nick Van Hoof: 55:47
Yeah, you don't have time to get familiar with anything because you have to be able to fix it. That's true.
Yan Cui: 55:54
Yeah. So I've been in those positions before, which is why I'm kind of cautious about advocating the use of Amplify framework for customers who aren't familiar with CloudFormation, who are new to AWS, who are new to a lot of this ecosystem, and what's available to you. Once you familiarise yourself with all of these, then you just want to automate and do less yourself. Great. I mean, you know, tools like the serverless framework, tools like, you know, Amplify and all these other things that can automate things for you. Amazing. And I think me personally, I sometimes what I do is I use Amplify to provision something. And then I just copy the CloudFormation into my serverless, or YAML, or whatever project, because I don't want to be writing all of that CloudFormation by hand, and I can just base my template on what Amplify has generated for me. I think that's probably little quite, I guess, good to compromise in terms of getting some productivity without losing some of the, I guess, control you have for how you configure those resources.
Nick Van Hoof: 57:04
Yeah, well, for the for the moment, I'm still a huge fan. I'm speaking about my story with Amplify in April at a conference in Amsterdam, the Serverless Architecture Conferenc there. So if people want to hear the full story of my experience with Amplify, they can get it there. But I made sure to, indeed to also touch upon your concerns. And because, yeah, what you say is true that if people if you have to look underneath, and you don't, you're not familiar with those things, then it can, it can be quite hard at that time. But I also think it'd be neat to look at the other end of the spectrum. So people that are completely new, and that just want to build something simple to get experience with a platform like AWS. If you would then run into to a problem that you can fix, you're just sandboxing. So it's not it's not a problem. But then you can also use Amplify to, to really spin up a lot of services quickly and to, to just go digging around and like, hey, what is happening here? Let me look at this CloudFormation template? How is this generated? How does this work? I think you can also use it for that purpose.
Yan Cui: 58:22
Yeah, especially for something like Cognito, which is one of the more complicated resources you can configure with CloudFormation, especially if you're doing things like social sign-in which is not, which is pretty poorly documented, I have to say, I had to, I had to do a lot of digging and finding information from different places, some from the documentations, some from the AWS forum, support forum, and the some from just asking people who just happened to know the answer. So all of that is, you know, is much simpler if you are just using Amplify, to say, add auth and add support for social sign-in, and then it just spits out the CloudFormation for you. But yeah, but but I do think that's a good way to learn about how to provision certain resources in CloudFormation.
Nick Van Hoof: 59:17
Yeah, indeed.
Yan Cui: 59:19
So Nick, that’s the, I think, that's the end of the hour, and we are running slightly over time. And also that's the end of all the questions I've had as well. Is there anything that you want to sort of mention before we go, maybe where you've been, what are your plans for ServerlessDays Belgium this year?
Nick Van Hoof: 59:38
Yeah. ServerlessDays Belgium specifically, I hope that by the end of the year, we can organise a conference around serverless technology in Belgium. Of course, let's see how this COVID pandemic turns out and also how many other people want to organise a conference very badly. Because maybe there will be an overflow of conferences then. But short term, the plan is to regularly every month, every two months, hold meetup for the moment, it's virtual. But it will be in real life as from the moment that it is permitted. And that way, we really want to bring serverless use cases closer to the people and showing the value of this technology. So that’s for ServerlessDays Belgium. And then on a personal scale, yeah, I will just work my ass off as a consultant for Novasport and in my own startup, Trans-IT. And, in general, for serverless technology, I think that that is something that I haven't mentioned yet. But people often say, full stack is dead. And that might be true, because I have never known full stack 10 years ago. I wasn't a developer yet. But I also think that now you can, not for everything, but for building simpler applications, or when using Amplify, and when maintaining both the front end and the back end, people can actually do this again now, because the platform does so many things for you, that you can still keep an overview of everything and really do those full stack projects on yourself on your own. And that is, so that's the message that I that I want to give to people then just go out and explore what is possible, if you leverage all of this cloud technology to your advantage.
Yan Cui: 01:01:47
Okay, that's a new one to me, full stack full stack is dead. I didn't realise that that is a thing.
Nick Van Hoof: 01:01:53
I read, I read a post on medium. I think there is about 3000 clips. And the title was full stack is dead. And I thought, Oh, is this really true? That is how I started thinking like, I don't think it is true. I think you can still do full stack projects, if you just rely on all of those proven services to also help you with that.
Yan Cui: 01:02:17
I mean, I've worked with a lot of full stack teams. So you may have within the team of specialists for the back end versus the front end. But the team itself is full stack and looks after both the front and the back end of the application. It doesn't mean that you yourself have to be a master of both. It is difficult enough to master just one area of the app and let alone both the front end and back. But certainly I think, you know, this whole “full stack is dead” is probably just a clickbait in the same way that people would… You probably read quite a lot of TDD is dead kinda of blog posts. But people still practice TDD maybe not in the way that was intended. But certainly there is, yeah, I don't think anything quite dies in the industry. There's a lot of dragging on for sure. So yeah, Nick, well, one last thing before we go, how can people find you on the internet? Any social media, Twitter handles, maybe people can follow you there?
Nick Van Hoof: 01:03:18
Yep, I am quite active on Twitter. And my Twitter handle is at @TheNickVanHoof. So it's my name with The in front of it, because my name was already taken. But you can also put it in the show notes probably if it's hard to understand because it's it's a name in Dutch, of course. And on the internet, I have a website. That's theclouddeveloper.io where I tried to blog regularly about serverless technology and about things that I have done using that technology.
Yan Cui: 01:03:55
Okay, sounds good. I'll make sure those are included in the show notes. And thank you again for taking the time to talk to me today. And best of luck in your new venture. And I guess I will see you on our Slack.
Nick Van Hoof: 01:04:06
Yeah. True. Thanks for having me, Yan. Bye.
Yan Cui: 01:04:10
Take care. Bye, bye.
Nick Van Hoof: 01:04:11
Take care. Bye.
Yan Cui: 01:04:25
So that's it for another episode of Real World Serverless. To access the show notes, please go to realworldserverless.com. If you want to learn how to build production ready serverless applications, please check out my upcoming courses at productionreadyserverless.com. And I'll see you guys next time.