Serverless Chats

About Susanne Kaiser:

Susanne Kaiser is an independent Tech Consultant from Hamburg, Germany, and was previously working as a startup CTO transforming their SaaS solution from monolith to microservices. She has a background in computer sciences and experience in software development & architecture for more than 15 years and regularly presents at international tech conferences.

• Twitter: @suksr
• Site: www.susannekaiser.net
• LinkedIn: https://www.linkedin.com/in/susannekaiser1/

WATCH THIS EPISODE ON YOUTUBE: https://www.youtube.com/watch?v=eGYlTfBJBJQ

Transcript:

Jeremy: Hi everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week, I'm chatting with Susanne Kaiser. Hi Susanne, thanks for joining me.

Susanne: Hi. Thanks for having me.

Jeremy: So, you are an independent tech consultant, so why don't you tell the listeners a little bit about your background and what you've been up to lately.

Susanne: Mm-hmm. So, as an Independent Consultant, I am helping organizations within the broad spectrum of software architecture and design including development to software delivery, or in other words or in shorter terms, helping organizations in building and shipping their digital products. I was also previously working as a startup CTO and I have a background in software development and software architecture of more than 17 years and I also regularly present at international tech conferences as a speaker.

Jeremy: Well, speaking of international tech conferences, I saw one of your talks at ServerlessDays Belfast before we shut down all conferences so no one can get together in person anymore. And, you did a talk about domain driven design and how that applies to serverless and serverless microservices. So, I'd love to talk to you about that today, because I think that is one of those things where software developers ... I don't want to say all software developers ... but a lot of software developers are just really bad at software design, and not just design of architecture and things like that which are in our wheelhouse, but more from the business side of things and understanding what the business needs are, understanding what the technical needs are, and then where that comes together in the middle, and what people should actually be building to solve those customer needs. So, I think that is domain driven design in a nutshell, but maybe you could tell the listeners a little bit about what domain driven design actually is.

Susanne: Yeah, so domain driven design is a software philosophy or methodology created by Eric Evans and it's about to capture the business domain as closely as possible into your software and it comes with a lot of strategic and technical design patterns and practices that I am happy to share with you in a moment. But, it's also, I would like to mention also, from the very beginning, it's not applicable everywhere. So, you should focus on your core domain ... I will explain it in a minute, hopefully, too ... where it makes sense that focusing on complex business logic and have to do with solving problems that have complex business logic behind.

Jeremy: Yeah, and so you had mentioned in your talk, the cost of poor software quality, and the number you gave here was, I want to say it's $2,840,000,000,000 a year in poor software quality, so what are some of these indicators of poor software quality?

Susanne: So, there are no simple measures for bad or good software quality, but there are several metrics that can be used as indicators. For example, an increasing curve of defect trend over the time is an indicator of poor quality software or low test coverage, assuming that as there is good test quality or cyclomatic complexity or large dev of inheritance and high degree of class coupling could also be indicators. Also the amount of effort it takes to understand a piece of code or badly engineered software resulting, for example, from immature or undisciplined practices and using less qualified software engineers or also and one thing is also really important to mention is the lack of domain knowledge and also poor communication and coordination issues and teams, specifically if one of the teams are growing.

Jeremy: Yeah, so that lack of domain knowledge, I would think that sort of gets to the crux of it, right? Because like I said in the beginning, we think we know how to solve a problem and we know how to solve it technically but what we're really trying to do is solve a problem that's very specific to a group of customers, whatever that group of customers might be and those different models could be your inventory system, right, and your inventory teams think of ... They think of inventory in a certain way and then you need software engineers to be able to build a system that makes sense for them -- that uses the same language, that uses the same sort of communication patterns or styles or things like that. What goes into building good software, then? Like what are the main components of building good software?

Susanne: So your domain driven design comes with a core statement that in order to build better software we have to align its software design with the business domain, with the business needs, and the business strategy. So domain driven design helps you with aligning your software design with the business domain needs and the strategy and it's very crucial for building your software solution, because otherwise, you are building something that, for example, are matching the requirements of your users. Instead you have to collaborate intensively with your domain experts to gain domain knowledge and to understand the problem first before you're solving it. We are tending to jump directly into solving a problem technically and, yeah, yeah, we can just let's deploy it on a cubinated cluster, but we have not understood the problem first. That's really crucial to the build better software.

Jeremy: Well, you mentioned the word strategy, which is one of those things where, I don't think a lot of people know what that exactly means. Like what is the strategy and you had talked a lot about Wardley Maps and sort of understanding this landscape and being able to use that to sort of plan your strategy and we can get into some of that more but can you explain Wardley Maps. We've talked about it before but just sort of in the context of domain driven design, how does that help you?

Susanne: Yeah, I really like to combine domain driven design with Wardley Maps, because at first, like when you start the journey to a domain driven design, it's really overwhelming. It was for me, very overwhelming, because there's a lot of new terms and it requires some time to grasp and understand it, and since it's not applicable everywhere, Wardley maps helps you to visualize the journey to domain driven design and so Wardley Maps has been created by Samuel Wardley, a researcher from the UK and a Wardley Map is a representation of the landscape the business is operating in and it's really simple. So it consists of an Y axis for the value chain and then X axis for the evolution stages. A Wardley Map visualizes the evolution of a value chain, so the first question is so what is a value chain? So behind every user need, there is a value chain and start off with the questions like who are your users, who are go...

About Paul Swail

Paul is an independent cloud architect who helps development teams make the transition to serverless. He has almost 20 years’ experience delivering software solutions to clients across a wide variety of industries. In addition to client consulting, Paul has been running his small SaaS business on AWS for the past 6 years and is slowly migrating it to a fully serverless stack. He writes in-depth articles on serverless in his email newsletter and on his blog at winterwindsoftware.com.

• Twitter: @paulswail
• LinkedIn: https://www.linkedin.com/in/paulswail/
• Blog/Newsletter: http://serverlessfirst.com/

WATCH THIS EPISODE ON YOUTUBE: https://www.youtube.com/watch?v=gf__z3K8LBI

Transcript:

Jeremy: Hi, everyone. I'm Jeremy Daly, and you're listening to Serverless Chats. This week I'm chatting with Paul Swail. Hey, Paul. Thanks for joining me.

Paul: Hey, Jeremy. It's great to be here. Thank you.

Jeremy: You are a cloud architect at Winter Wind Software. So, why don't you tell the listeners a little bit about yourself and what you do?

Paul: Yeah, sure. I'm an independent cloud architect. I work primarily with AWS and I specialize in helping development teams ship their first serverless application into production. I've been focused specifically on serverless for two years or so now, although I have been doing software development professionally for about 19 years in total.

Jeremy: Wow. Still not as old as me, but that's okay. One of the things that you've been focusing on lately... Or, I think you're making this transition into serverless first. So, why don't you tell us a little bit about that?

Paul: Yeah, yeah. My website is currently in the process of being moved to ServerlessFirst.com, so I think that... Basically, serverless first is a methodology, which I've been taking with my clients that I've been working with over the past couple of years. They're used to more traditional ways of building serverless apps, and they see the value of using serverless, but they can't use it for everything. By default, your architectural decisions start with serverless services unless you can justify using something else.

Jeremy: Awesome. Alright, I wanted to talk to you today because... I don't know what happened, but somehow you've become one of the most prolific writers in serverless over the last couple of months, releasing a few articles or a few blog posts every week. It's been awesome because every time we get more content, and you answer more questions, and you get deep onto one particular subject, I think it's super helpful. One of the things that you focused on quite a bit, I think, has been this idea of these communication patterns in serverless applications. You wrote two articles recently. One was called Seven Ways to Do Async Message Processing in AWS, and another one was Interservice Communication Channels for Serverless Microservices in AWS. Both great articles. Definitely go to WinterWindSoftware.com, check those out. Very, very interesting stuff. Why don't you tell us a little bit? Maybe you can get us started, in terms of what are the main communication patterns in serverless, and why is it so different, maybe, than a traditional application?

Paul: Yeah. I think a lot of my clients have come from the monolithic architectural background and asynchronous stuff. They may be aware of it but they haven't used it a lot. AWS has a lot of services which does... Around asynchronous messaging patterns and it can be hard to understand what to choose. So, a lot of it is just documenting questions that clients have had for me. A lot of the writing is around that area. We can go through the details of lots of individual services that I discussed in the article.

Jeremy: Yeah. Let's start, though, maybe just thinking about the difference between asynchronous and synchronous because I think most people are very familiar with that monolithic approach of... I should maybe take a step back. They're used to that request-response type mechanism, right? I make a request to a website or to an API and that data comes back to me. There's that one part of that immediate response. That's not going to change whenever you have a customer-facing or a web-facing side of things, but it's where the backend... The backend is what gets different. That is one of those things where, I think, when people are familiar with monolithic applications, they think, hey, I've got 15 different methods, or functions, or whatever, that are all in one big application and I can say, "hey, I need to process the order. I need to pull the inventory. I need to send the message." And that's all in one app, or one, I guess, big chunk of code, really. But when you start moving to this asynchronous thinking, we're starting to separate out these components separately. So what do people have to think about when they start building that type of application?

Paul: There are quite a lot of things to think about. I guess based on the workloads, firstly. If it's like a task or a job-based type workflow, you may want to do, or maybe that you need to notify a lot of other systems, so based around... That's a decision in itself, around what service you use, based on the nature of the workload. There are a lot of operational considerations just around throughput, and concurrency requirements, and latency requirements, and scalability of any downstream systems that you may need to talk to, and message durability, and your error handling, and retry mechanisms. These are all things... Oh, cost, of course, as well. These are all things that you need to consider around how you would structure any asynchronous messaging patterns that your workload requires.

Jeremy: Yeah. I think that makes a lot of sense. I think what you get people coming from the monolithic space or the traditional system space, and they move into distributed systems. Now, there's this whole different idea of passing messages around, right? We're no longer using a single system, so now we're trying to communicate with multiple systems, and as you said, things like durability of messages, that becomes a huge concern. Or, something like the error handling. What happens when you send a message off into the ether and you don't know what happens to it? Does it ever get to its destination? How do you know a message was even sent if that information isn't recorded correctly. I think maybe that's another thing that is interesting to me though, is that even people who maybe come from distributed systems and think about, oh, I've got to set up a Kafka cluster, or I've got to do something like that. Traditionally, there has been a ton of stuff that you would need to do just to create the messaging components between these distributed systems, but serverless changes that quite a bit.

Paul: Yeah, it does. I can echo those sentiments you said, I used to, back in my Microsoft.net developer days, setting up BizTalk servers, something actually I knew how to do, and we did it in a few projects, but just the provisioning and management overhead of doing it just... even though it was a nice distributed messaging patte...

About Eric Johnson

Eric Johnson is a Senior Developer Advocate for serverless at AWS. His passion is to help developers understand and employ best practices for planning and developing event driven, highly scalable applications using serverless technologies. Eric has been a software developer and architect for almost 25 years with a focus on serverless since 2014.

• Twitter: @edjgeek
• AWS Compute Blog: https://aws.amazon.com/blogs/compute/
• AWS HTTP APIs Blog Post: https://aws.amazon.com/blogs/compute/building-better-apis-http-apis-now-generally-available/

About Alan Tan

Alan is a Senior Product Manager at Amazon Web Services working on the API Gateway product team. He was previously a Senior Program Manager at Microsoft and software developer before that. He holds a B.S. in Computer Science and Microbiology & Immunology from The University of British Columbia..

• Twitter: @t_alan
• API Gateway Product Page: https://aws.amazon.com/api-gateway/

Transcript

Jeremy: Hi, everyone, I'm Jeremy Daly, and you're listening to Serverless Chats. This week I'm chatting with Eric Johnson and Alan Tan. Hi Eric and Alan, thanks for joining me.

Eric: Hey, thanks for having us.

Alan: Hey, Jeremy, thanks for having us.

Jeremy: So, Eric, let's start with you. You are a senior developer advocate for serverless at AWS, so why don't you tell listeners a little bit about your background, and what it is you do at AWS?

Eric: Yeah, absolutely, my background is I've been a developer since 1995. Yes, that's right. I am an old guy. I've been doing serverless since serverless came out, the day they announced serverless I looked at it and said, "Wow, why would you do anything different?"

I've been following that trail for a long time. I now work for AWS. I've been there for almost two years. I am a senior developer advocate for serverless at AWS. I love all things automated, all things serverless, so I'm having a great time.

As far as our role, what we do, is we're kind of a two-way conversation with developers, and users of serverless, we like to teach on how to serverless and get the message out and the best way to use serverless, how to make it useful for all workloads, but we also listen.

We try to bring back what the developers are saying to the product team, to someone like an Alan Tan, so they know, hey here's what people are saying, here's what they're wanting, here are the paper cuts, here's what they're loving, that kind of thing. I love my role and appreciate you having me here today.

Jeremy: Awesome, all right, so Alan, you are a senior product manager, so why don't you tell the listeners about your background and then what you do as a senior product manager?

Alan: Yes, I started in computer science, a developer just like Eric for a long time, and then I went into product management building products for big data analytics, data analysis, and most recently, been doing this for two years now in the API Gateway team, product manager for API Gateway.

So, what I do, I'm a senior product manager, so I talk to customers directly. I talk to people like Eric. I talk to people like Jeremy, yourself as well, to get the feedback of what customers are really looking for, and then translating that back into the product. So, our customers think we're building the right thing, and they really love coming back to us and using the same product over and over again.

Jeremy: Awesome, all right, well, so you work on the API Gateway team, and just the other day, AWS released HTTP APIs, which is really, really cool. So, can you explain to listeners what that is?

Alan: Yeah, of course, so just to start with some context of where that came from, so when I talked to customers, they usually come back to us for improvements and feature requests, but there are a few things that are really core to products, so more generally, when people think of products and the things they use, whether that's an appliance, a car, a computer, there are certain things they look for.

Which is how can we get this thing faster? How can we get it cheaper and better? API Gateway is no exception to that. Our customers come back asking us the same things, so last year we started looking into how we can continuously deliver on these improvements for them. The results was HTTP APIs.

So, it offers the core functionality of REST API at a 71% lower price, that's at a dollar per million in IAD, a dollar per million requests, sub ten millisecond latency overhead at the P99 level, that's a 60% improvement, and way easier to use features. So, you can think of HTTP APIs as the next generation platform for API Gateway's API types a kind of V2.

Jeremy: Awesome, now Eric, you have done a ton of stuff with API Gateway, with the REST APIs. You had your happy little APIs show on Twitch, kind of getting into all the details. I know you love service integrations and all that kind of stuff that you've been working on.

Eric: Yes, sir.

Jeremy: But you're pretty excited about HTTP APIs as well.

Eric: I am, yeah. For me, as a developer, HTTP API brings a lot. I'm going to start with the better part, the cheaper, faster, those are great, and I love those, and those are huge to our clients, but as a developer, the better part for me is the UI, is the interface.

There's been a lot of work done on how do I, as a developer, interact with API Gateway and how do I develop against API Gateway? It just starts with something like the UI. When you get a look at the UI, and if you've seen it, we did announce it last year at re:Invent.

I've gotten in. You've seen it. Hopefully, you've seen wow, this is a lot simpler. One of the examples that I'll use is CORS. And if you've ever heard me talk about API Gateway, I like to have everybody raise their hand and say, "Who loves CORS?" There's good a surprise, nobody raises their hand except for one person, and he's a liar, so you know that's...

Jeremy: That's probably me....

Eric: Yeah, probably you.

Jeremy: No, I hate CORS as well.

Eric: Nobody loves CORS, and CORS is not easy, but it is a necessary thing, so what a lot of folks end up doing is they just put stars in their CORS. Hey let anybody get to it. Let anything happen. Let anything get to it, because configuring CORS is too complex.

Well with HTTP API, we've taken that, we've simplified that. I say we, but really Alan's team has done a lot of great work on this, but I take credit for it when Alan's not around. So, what we've done is we've made the CORS integration a lot easier to set up, so you can add, here's the domains that should be allowed to get to it.

Here's the methods, and it's all in a simple UI. We've also taken and extended that where we're able to simplify the return coming out of your Lambda or your backend, and we use heuristics, which is a big word that I've just learned recently, but we use some logic to fill in the CORS data and return to the customer.

So, a lot of the heavy lifting of configuring CORS and other items have been simplified, so as ...

About Lynn Langit

Lynn Langit is a Cloud Architect who codes. She's a Cloud and Big Data Architect, AWS Community Hero, Google Cloud Developer Expert, and Microsoft Azure Insider. She has a wealth of cloud training courses on Lynda.com. Lynn is currently working on Cloud-based bioinformatics projects.

• Twitter: @LynnLangit
• Site: LynnLangit.com
• Courses: https://www.linkedin.com/learning/instructors/lynn-langit
• GCP for Bioinformatics: https://github.com/lynnlangit/gcp-for-bioinformatics

Mentioned Articles:

• Genome Engineering Applications: Early Adopters of the Cloud by Jeff Barr
• Scaling Custom Machine Learning on AWS
• Scaling Custom Machine Learning on AWS — Part 2 EMR
• Scaling Custom Machine Learning on AWS — Part 3 Kubernetes
• Shopping with DNA
• Learn | Build | Teach

Transcript

Jeremy: Hi everyone I'm Jeremy Daly and you're listening to Serverless Chats. This week, I'm chatting with Lynn Langit. Hi Lynn. Thanks for joining me.

Lynn: Hi. Thanks for inviting me.

Jeremy: So you refer to yourself as a coding cloud architect. You're also an author and an instructor. So why don't you tell the listeners a little bit about yourself and what you've been up to lately?

Lynn: Sure. I run my own consulting company. I've done so for eight years now and I work on various projects on the cloud. Most recently I've been doing most of my work on GCP because that's what my customers are interested in. But I've done production work on AWS and Azure. And I've actually done some POCs now on Alibaba Cloud. So one of the characteristics of me and my team is that we work on whichever clouds best serve our customers, which makes work really fun. In terms of the work that we do it really depends on what the customer needs because I have this ability to work in multi-cloud. Sometimes it's me working with C levels or senior technical people helping them to make technology choices, so based on their particular vertical. But at other times I'll hire a team of subcontractors for a particular project and we might build a POC. We might actually build all the way to MVP for a customer.

Lynn: And then occasionally I take projects where I build all the way out. The longest one I've had over the past few years is I did a project for 14 months where we went from design all the way out to product. And I worked every single day I was embedded with the developer team. So I do everything from design to coding to testing. It's a fun life.

Jeremy: It sounds like it. Well, so listen, I have been following you for a very long time and I'm a huge fan of the work that you've done. I've watched some of your videos on LinkedIn Learning and just been following along with some of this other stuff that you've done. And really like you said, a lot of what you have done has been around big data and recently you've been getting into, or you have gotten into, big data and serverless. And that's really what I'd love to talk to you about today because I just find big data to be absolutely fascinating and just the volume of data that we are collecting nowadays is absolutely insane. It's overwhelming.

And I don't know if traditional systems or if especially smaller teams working on some of these specialty products have the capability or the resources to keep up with the amount of data that's coming in based off of sort of some of these traditional methods to do that. So we can get into all of that. And I have a feeling this discussion will go all over the place, which is awesome. But maybe we could start just by sort of level setting the audience and just explaining what big data is or I think maybe what you mean by big data.

Lynn: I can have a really simple explanation. I'll say the explanation and I'll tell you why. So the explanation is data of a size that doesn't function effectively in your SQL Server or your Oracle Server or your data warehouse, so your traditional systems. And the reason I say this is because that is my professional background. I've been doing this for about 20 years now and for the first five or so maybe seven, I was working in those systems. I've actually written three books on SQL Server data warehousing. I worked for Microsoft as a developer evangelist back in 2007 to 2011. And the consulting practice that I built initially was around optimization of relational database systems.

So I was literally working on systems and figuring out, oh, this could be optimized. Let's optimize it. Oh, whoops, we have too much data now, what do we do? So when I left Microsoft in 2011 to launch my consultancy, I left because I was so fascinated by what was coming beyond these systems. One of the impetus was the launching of Hadoop as an open source project. And literally when I left Microsoft, I went to New Jersey and I took a class with Hadoop Developers, which was really throwing me in the deep end because I had come out of the Windows ecosystem. Of course the class was on Linux in Java, all coding. And I learned a lot that week.

Jeremy: I can imagine, yeah. So that's maybe my question there. So big data is this volume of data, this immense amount of data that's coming in that I think as you put it, that sort of these traditional systems like a SQL Server or even an Oracle can't handle or at least can't handle at a scale that would make the processing easy. So you mentioned Hadoop and there's other things like Redshift is now a popular choice for sort of data warehousing. And then you've got Snowflake and Tableau and some of these other things I think that are ... products out there that are trying to find a way to analyze this data. But what is the problem with these traditional systems when it comes to this massive amount of data?

Lynn: Well, it goes to the CAP theorem, which is consistency, availability and partitioning. This is sort of classic database ... what are the capabilities of a database? And it's really kind of common sense. A database can have two of the three but not all three. So you can have basically the ability for transactions which is relational databases or you can have the ability to add partitions is really kind of to simplify it easily. Because if you think about it, when you're adding partitions, you're adding redundancy. It's a trade off. And so are you adding partitions for scalability? And so when adding partitions makes a relational database too slow, then what do you do? So what you then do is you partition the data in the database to SQL and NoSQL.

And again, I did a whole bunch of work back in 2011, 2012, 2013. I worked with MongoDB, I worked with Redis. And one of the sort of key, I don't know, books I guess, would be Seven Databases in Seven Weeks. It's still very valid book even t...

About Ben Ellerby

Ben is VP of Engineering for Theodo and a dedicated member of the Serverless community. He is the editor of Serverless Transformation: a blog, newsletter, and podcast which share tools, techniques, and use cases for all things Serverless. He co-organizes the Serverless User Group in London, is part of the ServerlessDays London organizing team, and regularly speaks about Serverless around the world.

At Theodo, Ben works with both new startups and global organizations to deliver digital products, training, and digital transformation with Serverless across London, Paris, and New York.

• Twitter: @EllerbyBen
• Blog: Serverless Transformation blog
• Newsletter: Serverless Transformation Newsletter
• Podcast: Serverless Transformation Podcast
• Theodo: theodo.co.uk

Transcript

Jeremy: Hi everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week, I'm chatting with Ben Ellerby. Hi, Ben. Thanks for joining me.

Ben: Hi, Jeremy.

Jeremy: So you are the VP of engineering at Theodo, and you were just recently named an AWS Serverless Hero, so congratulations on that. So why don't you tell listeners a little bit about yourself and what Theodo does?

Ben: Ah yes. As you mentioned, I'm the VP of Engineering for Theodo. We help other companies launch digital products, be that startups, launching their initial MVPs, to large companies attempting a digital transformation. And more and more I'm helping our clients to use serverless. Be that through building their initial MVPs, but also training and upskilling their developers. So we're based in London, New York and Paris. And basically my role is to help coach our developers, and help us find the new technology areas we want to work on. And serverless has been highlighted as the main area we're trying to move towards. And many of our clients are starting to adopt serverless first architectures.

Jeremy: And what's your background?

Ben: My background, I've been at Theodo in London since we kicked off a team here about four years ago. Before that, a bit of time at IBM. And before that studying computer science.

Jeremy: Awesome. All right. So you mentioned digital transformation, and we've heard this term a lot, especially over the last couple of years. And I think some people think that means sort of moving from on-prem to the cloud, or sort of modernizing things. But you've been using this term, serverless transformation more recently. And essentially, this is this idea of going, I guess your second move to the cloud. Right? So could you explain what you mean by serverless transformation?

Ben: Yeah, sure. So what you touched on was digital transformation was that initial move to the cloud, which smaller and larger companies have managed some, with varying degrees of success. I actually helped a company called Junction launch their initial product about two years ago, which is an AI service that helps large companies plan their migration to the cloud. And that was very much a lift and shift approach. But more recently, if we take the example of Junction, they've had more and more targets going to things like SaaS, and FaaS and serverless first approaches. When I talk about serverless transformation, I'm talking about startups who are launching their initial MVPs and doing that in a serverless first approach, but also larger companies who are trying to consolidate their developer resource by building serverless first architectures, rather than managing infrastructure. And more than just managing infrastructure, common application things like authentication, moving to that as a service and really leveraging everything as a service to focus their development teams on the core business value that they're adding, the distinct business logic that makes their company who they are.

Jeremy: Right. So I mean, it's more about that lift and shift approach. And I think we've talked about this on the show a number of times, that trying to just sort of move everything as is from your on-prem into cloud is a bit of a fool's errand, right? I mean you're essentially copying this local environment, but you're not getting the benefits of the cloud environment.

Ben: Sure. And it has some benefits like virtualization was an initial move. Containerization was another move. And now we're seeing sort of function as a service, and other things as a service. As soon as a further level of abstraction. The higher that level of abstraction goes, the more business value I think he gets.

Jeremy: Awesome. Right. You wrote a post called In Defense of the Term Serverless, and nobody seems to want to have this conversation with me anymore. Because I have been very outspoken. I had a post a while back called Stop Calling Everything Serverless, where I tried to essentially define what I thought the term serverless was. And for me, I look at it as not a technology, not a managed service, not FaaS, not some sort of a spectrum or a ladder or these other things that I think are really, really interesting ways to try to classify what it is, because it's such a hard term to sort of grasp. But I look at it more as sort of this process of using these services that don't require you to really have an active involvement in the management of the infrastructure.

And to extend that even further in some cases where possible where you don't have to even worry about the scaling or provisioning a cluster of something like, I don't know, a cluster of Elasticsearch or something like that. So I think this is a perfect opportunity because in this community now we have a lot of forward thinkers and I think we want to move past this idea of what is serverless? The problem is that our community is for the most part an echo chamber. Right? And we keep having this conversation every once in a while when somebody from the edge sort of asks us this question. So, I'd like to get your definition of serverless and why you think that term actually is really important.

Ben: And I think it's a long answer. So I've recently been working on the sort of preview chapter of the book, Serverless Transformation at any scale. And the first chapter of that deals with what is serverless? It talks about that move from virtualization to containerization and then function as a service. But then it talks about how it's not just function as a service, it's using cloud native technologies as much as possible, which makes it a hard thing. It's not a binary classification between serverless, not serverless. It's a polymorphic space that keeps changing and keep adapting. I think we can place different services on a spectrum of serverlessness. So Elastic Beanstalk is obviously not serverless, but it's more serverless than manually provisioning EC2 to instances that goes all the way up to using something like Cognito, which is very little code. It's really the cloud provider providing that logic for you.

So I think you can put things on that spectrum, but I don't think that's where the value is. ...

About Dr. Peter Sbarski

Peter Sbarski is VP of Education & Research at A Cloud Guru and the organizer of Serverlessconf, the world’s first conference dedicated entirely to serverless architectures and technologies. His work at A Cloud Guru allows him to work with, talk and write about serverless architectures, cloud computing, and AWS. He has written a book called Serverless Architectures on AWS. Peter is always happy to talk about cloud computing and AWS, and can be found at conferences and meetups throughout the year. He helps to organize Serverless Meetups in Melbourne and Sydney in Australia, and is always keen to share his experience working on interesting and innovative cloud projects.

Peter’s passions include serverless technologies, event-driven programming, back end architecture, microservices, and orchestration of systems. Peter holds a PhD in Computer Science from Monash University, Australia.

• Twitter: @sbarski
• LinkedIn: https://www.linkedin.com/in/petersbarski/
• A Cloud Guru: acloud.guru

Transcript

Jeremy: Hi, everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week, I'm chatting with Dr. Peter Sbarski. Hi, Peter. Thanks for joining me.

Peter: Hi, Jeremy. Thank you for having me.

Jeremy: So you are the VP of education and research at A Cloud Guru. So why don't you tell the listeners a bit about yourself and what A Cloud Guru does?

Peter: Yeah. Thank you, Jeremy. So my background is in computer science. I got a PhD about 12 years ago, from Monash University in Australia. I worked as a consultant focusing on cloud projects, primarily. Then four years ago, I joined A Cloud Guru and have been with A Cloud Guru ever since. So at A Cloud Guru, we create awesome fun online education. So we help people get skilled up on AWS or Azure or GCP, or just learn cloud related technologies in a very fun and engaging and practical way as well.

We help people get certified, but also learn how do you use containers? How do you use Kubernetes? How do you go serverless? How do you do things with best practice in mind? So we focus on making sure that we produce that high quality, curated education that anyone can access.

Jeremy: That's awesome. All right, so you and I have bumped into each other, and you're all the way in Australia, and I'm over here on the East Coast of the United States. We've bumped into one another in Seattle, and at re:Invent a couple of times. Every time we get together, we are always talking about serverless education. I think last time we were together, we went maybe even way beyond serverless education. That's what I want to talk to you about today is just the state of serverless education.

And we can go a little bit deeper. But one of the things that I think is unique about serverless as opposed to maybe learning even containers, or even some of these other cloud concepts is, serverless just seems to be such a reworking or re-engineering your own mind to think about these things differently. What are you seeing in terms of maybe the challenges between training people, just on programming languages and some of these other cloud computing, concepts versus training people on serverless?

Peter: Yeah, it's a great question, Jeremy. Look, I hate to use the word paradigm, but it does feel, it is really a paradigm shift. Because serverless, it feels like, this is what cloud was supposed to be all along, right? You're not dealing with low level infrastructure concerns. You're not provisioning your servers and thinking about memory capacity, but you're thinking at a high level of abstraction, you're thinking in terms of code, you're thinking in terms of functions and services and event driven architectures. That's interesting. It's different and it requires people to really think in new ways.

Look, I think, honestly, the adoption of serverless will hang on education. If it can educate people, serverless as a concept as an idea will be successful. I think that's what we're all working towards. This is what you do nearly every day, right? You educate people on serverless. You blog, you talk, because this is the way we get people to understand.

Jeremy: Yeah, so that's actually a really good point about education, because I think there is an education gap. But before we talk about the education gap, I think from a more maybe structural standpoint, one of the things that is really interesting about cloud computing in general, and I think you're right, it's hard to draw that distinction between what is serverless and what is just eventually cloud? What we understand that to be. I'm thinking that I watch people struggle, trying to figure out, "Okay, AWS just launched some new feature that has now made some of the workaround that I was using in the past has made that obsolete."

I think that you have this speed of innovation in the cloud. It's not just AWS, it's Google, it's Azure, it's Alibaba, it's Tencent. All of these cloud providers are just going through now, and releasing all of these really cool new features. So how does the average human that doesn't read 800 articles a week like I try to do, how do they stay up to date with this stuff?

Peter: It is actually very difficult. It's very hard because the pace of innovation, especially in cloud computing like you said, is incredible, right? It's so funny. We actually do a weekly show, a round up at A Cloud Guru covering everything that has happened in AWS or Azure for that week, right? And we always have material to talk about because there's always something new. So yeah, you have to have a trusted source, you have to watch a show like AWS This Week or read a round up blog or something, because it is so hard to keep up with everything.

Look for us, it's a full time job, right? You just have to stay up to date, then hopefully, we can share what we've learned and what's important with everybody else. But yeah, it's a challenge. I don't blame you if you miss a few things. It's just too quick.

Jeremy: Yeah, no, it goes beyond that too, right? If you think about saying, "Okay, well, the great now they've released Lambda destinations, or now there's the HTTP API, or there's these other little things they do." The Lambda destinations really changed probably what the best practices for dead letter queues with Lambda functions, right? Because you get more context when you use the failure path of a failure destination, I guess. So that's the other thing. Forget about just knowing what's available, knowing the right ways to use it, or the best practices or the leading practices. That's a whole nother thing you have to keep up with.

Peter: That's it. It's so funny. I remember, I was writing my book, I wrote a chapter on the API Gateway, and API Gateway came out. I remember I finished that chapter. I was so happy. Then literally two days later, I know Proxying came out. So now you could proxy request straight to Lambda. So you no longer have the right velocity templates. And I'm okay, well, let's scrap that chapter. Let's do it all over again. All right, had to start from scratch and come up with that new best practice. It happens all the time. It's hard.

Jeremy: Right.

Peter: Yeah, this is why ...

About Suphatra Rufo

Suphatra started her career at NPR and PBS stations around the country, and quickly found her way into technology. She worked on social good initiatives like Microsoft’s Imagine Cup, a competition for young inventors; We Day, working with Selena Gomez to advocate for more young women to learn how to code; and TEALS, a program that places industry engineers in high school classrooms to teach computer science.

She has deep product experience and led the effort to create a nonprofit SKU for Office 365 and Azure and bring cloud computing as an upsell to the social sector to 93+ markets and realize a new revenue stream for Microsoft. She was part of the original team that built Microsoft Teams and saw the product from Preview to GA, all the way to v2. She worked at the forefront of cloud computing at Amazon Web Services, managing their $6B database category's developer advocacy and customer storytelling efforts. Today, she heads up solutions marketing at Couchbase, a late-stage VC-backed cloud database startup in Silicon Valley valued at nearly half a billion dollars that develops open-source, NoSQL, multi-model, document-oriented and key value databases.

• Twitter: @skprufo
• Couchbase: couchbase.com

Transcript:

Jeremy: Hi, everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week I'm chatting with Suphatra Rufo. Hi, Suphatra. Thanks for joining me.

Suphatra: Hey, Jeremy. Thanks for having me.

Jeremy: You recently became the head of solutions marketing at Couchbase, so why don't you tell the listeners a little bit about yourself and what Couchbase does?

Suphatra: Hi, I'm Suphatra. I'm head of solutions marketing at Couchbase, which is a small start-up in Silicon Valley that develops open source NoSQL multi-model, document oriented and key value databases. We've raised $155 million in funding and we're valued at nearly half a billion dollars. As head of solutions marketing at Couchbase, I create the company's market strategy, sales plays across different industries and solutions, and I handle all of our compete scenarios. In my typical day to day, I'm usually looking at complex technical and business challenges and trying to diagnose how we can create solutions around that, and working with our engineering team to influence product road maps so that our solutions can be integrated in features and helping our business teams determine our next go-to-market investment areas.

Jeremy: Awesome. All right. You have a ton of experience and you have a very impressive resume on marketing cloud databases... Is maybe a good way to say it. I'd love to get some insight from you into how companies, especially enterprises, are looking at migrating data to the cloud and moving away from maybe more traditional on-prem type installations. I guess maybe the best place to start is, I think most people know what relational databases are, that's a pretty common thing. And I think people have a sense of what NoSQL is, people might be familiar with DynamoDB, MongoDB, Cassandra, those sort of things. But maybe you could just give us a little bit of background on what modern NoSQL looks like.

Suphatra: Yeah, yeah, like NoSQL 2.0, but I'll just start from the very beginning too, because I think a lot of people are confused NoSQL still, which is funny because it's been around for almost a decade at this point, but NoSQL is essentially a different kind of database that doesn't rows and columns. One good example is if you think about an application like Snapchat, on New Year's Eve, millions of people want to use Snapchat at the exact same time. So 11:59 PM, millions of people get on their phone to use Snapchat because they want to capture the exact same picture at that exact moment. So Snapchat, as an application, has to be built in a way to accommodate for a very sudden and huge surge in performance for a very brief moment of time, and then scale right back down... Because once people take that picture of them kissing their loved one when the bell rings, or the ball drops, I should say, then they stop using Snapchat, so then that goes straight down.

What NoSQL databases are great for is they can handle those types of really heavy spikes because they can scale up and down really easily because they aren't constrained by rows and columns like a typical relational database. That's what the NoSQL databases really offer. Since NoSQL databases were invented a decade ago, they've really branched out to lots of different types of NoSQL. Now you have document databases, you have adjacent documents, key value databases... Couchbase is cool because they do both of those things. When I was at AWS, I helped with stories about DynamoDB, which is specifically just key value database, which is also really strong database as well.

Jeremy: The thing that's interesting about NoSQL, and we're hearing more and more about it, there's a lot of different companies that are offering solutions for it. And more importantly, I think there are companies that are starting to adopt... And specifically for the workloads like you talked about, that New Year's Eve... Billions of records or billions of transactions in a very, very short amount of time, but is this something that you're seeing companies, maybe not just your start-ups and your Snapchats, but you're seeing other companies start to adopt?

Suphatra: Yeah, yeah. I think the way that consumers behave, the retail industry is a good example. You probably didn't know that Sears, Kmart, Barneys New York, Party City, I can name a dozen more retailers that just last year, either completely closed down or had to significantly reduce their number of stores, just last year. It's because retail isn't done the same way anymore. Those spikes are now a common part of life and people are having a hard time figuring out how to handle it. Tesco, which is the largest grocery chain store, I'm not sure in America or in the world, I'll have to check that... But they, in 2014, crashed on Black Friday because they couldn't handle the spike in the demands they were getting online. So they lost an entire day of business on Black Friday because they couldn't handle that workload. And then the year later, they went on a NoSQL database and now they can handle that load.

I think what people are seeing is that normal day to day business operations are fundamentally different. For example, the fashion industry used to have only four clothing seasons. Your mother probably remembers buying a new outfit every season... So winter, spring, summer, and fall. And so women's clothiers would go and create new clothes four times a year. Now the fashion industry has 52 seasons, so every week is a different season of women's clothing, which means there's a spike every week for every launch of every new clothing line. So that's another big database problem that's now just becoming a regular part of life. A decade after NoSQL databases are invented, it's really not a new invention anymore. Now this is just the way of business.

Jeremy: Wow. I can't imagine buying something new every week. I buy a new hoodie maybe once a year or twice a year or something like that. That's the extent of my fashion choices. I think that's really interesting. I think that's where everything is moving, is that just you have to become global now, right? You have to be able to handle these workloads that are just gigantic, and obviously there's some major players in this space. We have AWS and we know of things like DynamoDB and now some of the managed services...

This is PART 2 of my conversation with Rick Houlihan. View PART 1.

About Rick Houlihan:

Rick has 30+ years of software and IT expertise and holds nine patents in Cloud Virtualization, Complex Event Processing, Root Cause Analysis, Microprocessor Architecture, and NoSQL Database technology. He currently runs the NoSQL Blackbelt team at AWS and for the last 5 years have been responsible for consulting with and on boarding the largest and most strategic customers our business supports. His role spans technology sectors and as part of his engagements he routinely provide guidance on industry best practices, distributed systems implementation, cloud migration, and more. He led the architecture and design effort at Amazon for migrating thousands of relational workloads from Oracle to NoSQL and built the center of excellence team responsible for defining the best practices and design patterns used today by thousands of Amazon internal service teams and AWS customers. He currently work on the DynamoDB service team as a Principal Technologist focused on building the market for NoSQL services through design consultations, content creation, evangelism, and training.

• Twitter: @houlihan_rick
• LinkedIN: https://www.linkedin.com/in/rickhoulihan/
• Best Practices for DynamoDB: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html
• 2017 re:Invent Talk: https://www.youtube.com/watch?v=jzeKPKpucS0
• 2018 re:Invent Talk: https://www.youtube.com/watch?v=HaEPXoXVf2k
• 2019 re:Invent Talk: https://www.youtube.com/watch?v=6yqfmXiZTlM

Transcript:

Jeremy: So one of the things that you have never mentioned or at least I don't think I've ever seen you mention it, at least not in any of your talks for your modeling is local secondary indexes.

And I used to think, "Hey, this is great. They've got really strong guarantees and then it's sort of this great use case if you want to do a couple of different sorts." But LSIs are not quite ...

Rick: Not the panacea you might think they are.

Jeremy: Yes, correct.

Rick: So LSIs, I'm not exactly sure. I mean, I think you're exactly correct. The biggest value of LSI is the strong consistency, right? But the limiting factor of the LSI is it doesn't really let you kind of regroup the data, right?

Jeremy: Right.

Rick: You have to, you have to use the same partition keys to the table. So the only thing you can really do is resort the data, right? So right there, that's a limited set of use cases, right? There's not a lot of access patterns. I mean there are, but there's not necessarily a ton of access patterns or applications that only required me to resort the data. Most applications are going to require to group the data on multiple dimensions so that limits the effectiveness of the LSI. The other thing about the LSI that kind of stinks is they have to be created at the time the table is created, they can never be deleted.

So if you mess it up, then you've got to recreate the table to get rid of them and I find them to be extremely limited use. I mean, most developers can tell you that strong consistency is an absolute requirement, but when you get down to it and started looking at the nature of their application, yeah, what they really need is read after write consistency, right? It's worth kind of talking about the difference, right? Strong consistency implies that no update to the database is going to be acknowledged to the client unless all copies or all indexed or copies of that data are also updated, right?

Jeremy: Yeah.

Rick: That's strong consistency. That means if I'm in a highly concurrent environment, that no two clients could read different data, okay? Unless the read is not, or the write is not yet fully committed. As long as the right hasn't committed, you're not going to get two copies of the data. Well, most use cases are really more about like if I make the write and I read back, did I get the right data?

So what we're really talking about is read after write consistency. If you think about the round trip between the client and the system, if I have a let's say in DynamoDB, GSI replication is 10 milliseconds or less, it's highly unlikely that you're ever going to be able to return to the client, that the client is ever going to be able to returned to the server and ask for the same data back in 10 milliseconds.

Jeremy: And honestly, if you do, welcome to distributed systems.

Rick: That's exactly right. I mean, that's the other thing I was going to say and most distributed systems, what you'll find is there's a propagation delay on configuration data. So oftentimes, even if you get to the point where the developers are going to tell you that there's going to be concurrent access on this data, when you back up a step, you're going to find configuration data is going to live in multiple entities. So hey, all bets are off, right?

So let's take a look at that need for strong consistency and not make arbitrary requirements because as developers when we make arbitrary requirements, it's like hooking a fire hose up to our wallets. Let's make sure that we're actually making requirements that are meaningful to our business. 90% of the application workloads I work with, I would say even maybe even higher don't require strong consistency. So let's just use those GSI. They're much more flexible, right? They can be completed anytime, they carry their own capacity allocations. They don't pillage capacity from the table. Overall they're just a lot more flexible.

Jeremy: Yeah, and you've got more control. I mean, that's one of those things too. If you are doing the single table design and you're using all those different entity types and so forth, what are the chances that all those LSIs and the sorts all align with one another too. It seems like a lot of wasted capacity.

Rick: Inevitably, you're going to end up using GSIs, right?

Jeremy: Right. Exactly.

Rick: You may be able to use an LSI for one use case, but you can't use them for all of them.

Jeremy: Yeah, and I mean, and I think just the important thing about LSIs too is regardless of the inflexibility of them, there's also a doubles the costs, right?

Rick: Well, all indexes double the cost, right? I mean [crosstalk 00:49:35]

Jeremy: Of course, yeah.

Rick: Because actually, one of the things people kind of ... It's kind of an incorrect assumption about LSIs is that customers believe that, "Oh, they use the same capacity as the table. Oh, they must be free." No, they're not free. You still pay for the storage, you still pay for the capacity. I'm just going to have to allocate twice as much capacity to the table now.

Jeremy: Moving on from LSIs and GSIs, the other thing that always comes up is this idea of hot keys or hot partitions where you basically have one key that gets access quite a bit. You sort of pointed this out in your slides where you s...

About Rick Houlihan:

Rick has 30+ years of software and IT expertise and holds nine patents in Cloud Virtualization, Complex Event Processing, Root Cause Analysis, Microprocessor Architecture, and NoSQL Database technology. He currently runs the NoSQL Blackbelt team at AWS and for the last 5 years have been responsible for consulting with and on boarding the largest and most strategic customers our business supports. His role spans technology sectors and as part of his engagements he routinely provide guidance on industry best practices, distributed systems implementation, cloud migration, and more. He led the architecture and design effort at Amazon for migrating thousands of relational workloads from Oracle to NoSQL and built the center of excellence team responsible for defining the best practices and design patterns used today by thousands of Amazon internal service teams and AWS customers. He currently work on the DynamoDB service team as a Principal Technologist focused on building the market for NoSQL services through design consultations, content creation, evangelism, and training.

• Twitter: @houlihan_rick
• LinkedIN: https://www.linkedin.com/in/rickhoulihan/
• Best Practices for DynamoDB: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html
• 2017 re:Invent Talk: https://www.youtube.com/watch?v=jzeKPKpucS0
• 2018 re:Invent Talk: https://www.youtube.com/watch?v=HaEPXoXVf2k
• 2019 re:Invent Talk: https://www.youtube.com/watch?v=6yqfmXiZTlM

Transcript:

Jeremy: Hi everyone, I'm Jeremy Daly and you're listening to Serverless Chats. This week, I'm chatting with Rick Houlihan. Hey Rick, thanks for joining me.

Rick: Hey Jeremy. Thanks for having me on.

Jeremy: So you are a principal technologist for NoSQL at AWS. So why don't you tell the listeners a little bit about yourself and what it is that you do at AWS?

Rick: Yeah, sure. So I've been at AWS almost six years now, I guess five and a half years. My primary focus in life since joining AWS has really been NoSQL technologies. Shortly after joining organization, I joined the specialist team and then for about two years, I spent a large amount of my time focused on the migration of Amazon's internal application services from a relational database, specifically Oracle to a NoSQL technology which was DynamoDB, of course.

So that was my mission in life and the last two years or so, I've been more focused externally taking the learnings that we gained from that exercise out to our customers and helping them solve similar problems.

Jeremy: Awesome, and I love the fact that you are actually working with customers and working with these big data problems, actually solving these problems as opposed to just sort of advocating for ...

Rick: ... thinking about them, right?

Jeremy: Exactly. Exactly.

Rick: We got called out. Yeah.

Jeremy: And that's, I mean, again, obviously this firsthand experience and all this work you do, you see all these different permutations and different ways that you can use DynamoDB and NoSQL. So I think if anybody is in the sort of AWS ecosystem, if they've ever sort of thought about using DynamoDB, your name has probably come up. You've become somewhat of a legend at AWS re:Invent with your NoSQL talks on data modeling in NoSQL.

So there are a million different things that we could talk about obviously, and I could probably talk to you for quite some time. I don't want to spend a lot of time rehashing the things that are in your presentations and I will put these in the show notes and people can go and spend some time looking at these things. But I actually, I want to be a little bit selfish here because I have all these questions that I've sort of come across and some people have asked me and now that I've got you here, I would love to sort of ask you those and see if we can dig a little bit deeper in them.

But what I do want to do is be fair to people who are not overly familiar with DynamoDB or NoSQL in general. So maybe we start quickly and just kind of explain or if you could explain to us what's the difference between NoSQL and relational databases or RDBMS.

Rick: Sure. Yeah, great place to start. So if you think about the relational database today, it's about normalized data. We're all very familiar with the idea of a normalized data model where you have multiple tables, we have all these relationships, parent child relationships and many to many relationships. And so we built these tables that contain this data and then we have this ad hoc query engine that we write called SQL. We write queries in SQL to return the data that our application needs.

So the server, the database actually restructures the data and reformats the data on the fly whenever we need it to satisfy a request. Well, NoSQL on the other hand eliminates that CPU overhead and that's really what the cost of the relational database is and the reason why it can't scale because it takes so much CPU to reformat that data.

So with NoSQL, what we're going to do is we're going to actually denormalize the data somewhat and we're going to tune it to what we call the access pattern, tune it to the access pattern to create an environment that allows the server to satisfy the request with simple queries.

So we don't actually have to join the data together. So we talk about the modeling and whatnot in my sessions, we can get into how do we do that, but the fundamental crux of the issue here is that the relational database burns a lot of CPU to join the data and produce these materialized views whereas the NoSQL database kind of stores the data that way and makes it easier for the application to use it.

Jeremy: All right, and then one of the things I think that you see all the time when people are sort of migrating or trying to figure out that NoSQL mindset is they think about access patterns and one of their access patterns is something like list all customers.

Rick: Right.

Jeremy: And it's one of those things where I think it's really hard for people to make that jump from just being able to say select star from customers and understand that data will get back and we can add limits and things like that. It's not quite the same with something like with NoSQL, so when do you suggest people not use NoSQL?

Rick: Okay, so that's actually a really good question. So NoSQL is really suited and as we talked about, we have to denormalize the data, right? Which does that means I have to structure it and tune it to the access pattern. So if I don't really understand those access patterns, if they're not really well-defined, then maybe what we're looking at is a different type of application that's not necessarily so well-suited for NoSQL, right?

And that's really what it comes down to. There's two types of applications out there. There's no OLTP or online transaction processing application which is really built using well-defined access patterns. You're going to have a limited number of queries that are going to execute against the data, they're g...

About Yan Cui:

Yan is an experienced engineer who has run production workload at scale in AWS for 10 years. He has been an architect and principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. He has worked extensively with AWS Lambda in production, and has been helping clients around the world adopt AWS and serverless as an independent consultant. Yan is an AWS Serverless Hero and a regular speaker at user groups and conferences internationally. He is also the author of several serverless courses.

• Twitter: @theburningmonk
• Blog, Courses, Workshops: theburningmonk.com
• GitHub: github.com/theburningmonk

Transcript:

Jeremy: Hi, everyone, I'm Jeremy Daly and you are listening to Serverless Chats. This week I'm chatting with Yan Cui. Hi, Yan. Thanks for joining me.

Yan: Hi, Jeremy. Thanks for having me.

Jeremy: So you are a developer advocate at Lumigo. You are an AWS serverless hero, you are also an independent consultant and I think more people know you as the Burning Monk. But why don't you tell us a little bit yourself and what you've been up to lately?

Yan: Yeah. I'm all those things you just mentioned. I'm doing some work with Lumigo as a developer advocate where I'm focusing a lot on the open-source tooling and articles and in my sole capacity as an independent consultant I also work with a lot of clients directly. A lot of them are based in London where I used to be based. Nowadays I moved to Amsterdam. I still do a lot of open-source work. I just started a new video course focusing on Lambda best practices. Then I'm also doing some workshops around the world. In Europe and also now looking at U.S as well. So doing a lot of different things to keep myself busy.

Jeremy: Awesome. Listen, I can talk to you probably about anything. Anybody who knows or seen some of the work that you've done, it's quite expansive. It's very impressive. In 2019, I have some numbers here, you did 70 blog posts, something like 2200 students to your video courses. You spoke at 31 conferences in 17 cities. But more importantly, you helped 23 clients in 11 different cities. So you are on the front line here in seeing how companies are adopting serverless. And not from one perspective and I think that's what we get a lot from different companies is, there is one perspective of how they adopt serverless and how they are working with that.

You've obviously seen this from multiple perspectives, so just, I want to talk about adoption a little bit. We'll talk about a few other things, but just what are you seeing with companies now? The customers you're working with or the clients you're working with, what are they using serverless for?

Yan: They are using it for all kinds of different things. I think depending on, I guess the maturity of the company, the domain they're working in. I've got a lot of clients that they are either enterprises or a lot of small and medium sized enterprises, and even some stealth-mode to startup as well. And obviously your constraints are completely different. That's one of the things I really enjoy about being a consultant. Where I get to see a lot different perspectives and what may work for one company may be completely inappropriate because the constraints a different company would have. So in terms of the adoption patterns, you see a lot of the, I guess startups that are in that position where they can go all in on serverless.

They are your great serverless-first going to the game. But then at the same time, you also have lots of, I guess midsize companies and enterprises. They have so much existing intellectual properties that it wouldn't make sense for them to rewrite everything just so that they can run code on Lambda. For all those companies, you see a mix of Greenfield projects. They are serverless first and then at the same time there's some effort to migrate some of the existing projects to work on serverless at least to some degree, at least gradually. Of course, depending on a lot of constraints around how much of on-premises stuff you have.

Do you have to run everything in Java in which case it is the cold start performance that's a concern. So a lot of those limitations I guess affects how quickly and how much you are able to go in on this whole serverless first mindset that we like to have and I think that is probably one of the reason that serverless adoption hasn't been as fast and as many people expected a few years ago because, the fact that, you can't just lift and shift your weight anymore. It means that you always have to allow more thought process behind it and planning and also just risk involved if you make a big mistake and it's your flagship product and of course that's going to put you in a really difficult position. But we do see that companies of all sizes and all fields and all industries are adopting serverless for lots of different workloads, not just APIs but a lot of data processing, IoT, you name it.

Jeremy: That's actually one of the things I'm curious of too. You mentioned customers in all different industries, which is really interesting. Because we get to this point now where I think every company is a software company. Everybody is building some sort of software now. But so, what are the constraints that these companies are working in?

Yan: A lot of them, I guess again, it depends on the industry you're in. For finance companies you have to be very careful about a lot of the, I guess, regulated requirements. In terms of how you handle data and also in some cases you having a plan in case you have to move away from a database for example, that's where some of your vendor lock-in arguments start to kick in. And also for example, you have enterprises who have millions lines of Java code that has been accumulated over 10 years. It's not possible for them to move everything into Lambda if they're seeing one to three seconds of cold start time on those user facing APIs. So some of those constraints are being lifted.

At least they are now getting better with new features on the platform but still it's something that people have to be aware of and also have to understand the mitigation strategies, which a lot of times is where the constraint is, is a lack of knowledge and knowhow because you can even think of Lambda as the extension to a lot of AWS offers, then it means that, you can't just know is it to visualization, you have to know a lot of different services to take full advantage of serverless.

That's where I think a lot of companies are struggling, is that they just don't have the skillset available in-house. They're exposing developers to things that they've never had to think about before. And I think that's where you get a lot benefit from serverless from having autonomous teams that can be self sufficient and look after so many different things, but at the same time, a lot of developers are just not used to working that way. They're used to working in silos where they have very few responsibility, just write your code, someone else will manage running the code in production. They'll manage the infrastructure, but now more of that is your responsibility which can be a gift, but it can be a challenge to companies that are not used to working that way as well.

Jeremy: Yeah, I totally agree. And I think that, as you mentioned learning all these other services, I think we're at a point now where most of these use cases there is some sort of ...