Serverless Chats

About Emrah Şamdan

Emrah Şamdan is the VP of Product at Thundra, a tool to provide serverless observability for AWS Lambda environments. With the development team, Emrah is obsessed with helping the serverless community with their debugging and monitoring effort both in production and during development. He is responsible for making trouble for the Thundra engineering team while finding solutions to ease the life of serverless teams.

• Twitter: @emrahsamdan
• Thundra: Thundra.io
• Blog: blog.thundra.io. 
• Demo: demo.thundra.io

Transcript

Jeremy: Hi, everyone. I'm Jeremy Daly and you're listening to serverless chats this week. I'm chatting with Emrah Sandam. Hi, Emrah. Thanks for joining me.

Emrah: Hey, Jeremy. Thanks a lot for having me today.

Jeremy: So you're the VP of product at Thundra. So why don't you tell the listeners a little bit about yourself, your background and what Thundra is up to.

Emrah: Yeah, sure. So I'm, you know me as a product manager for Thundra. I started as a product manager at Thundra while it was a start project — it was an insider project in OpsGenie. We were some engineers, me and some designers that began an internal product for OpsGenie engineers. Then it turned out to be a product and company, and now we are serving serverless developers for observability. So in 2017 Serkan, our CEO and the CTO actually acting, and he was developing some modules of OpsGenie with AWS Lambda. And he had some problems with the observability and he couldn't find any solution that fits the purposes. And he said, hey, I can write general libraries because they were writing in Java at that time which can give me some ideas about like how my Lambda functions are performing. And he developed this as like an extracurricular activity for OpsGenie, and he made this available, and it was sending data to Elastic at that time. They were seeing some Thundra produce data. And they thought that, even before I joined OpsGenie, they thought that why don't we make it as a separate product? And why don't we make it as a separate company and I joined and they hired me as a product manager for that. In October last year in 2018, we decided to spin off it as a separate company because, you know, OpsGenie was sold to Atlassian and Thundra will continue as a separate company. And we are helping serverless developers with observability by aggregating traces, metrics and logs.

Jeremy: Very cool. All right, so I wanted to talk to you today about reducing MTTR in serverless environments, because I think when we think about meantime to repair, normally we have a lot of control. Like if we're running our applications on-prem, then we likely have access to the physical servers and the hardware components, and even if we're running our applications on something like EC2, we still have access to the operating systems, the VM instance sizes, the attached storage, and the same is typically true with containers as well, right? So we have a lot of ways in which we can affect the time it takes to repair some of these hardware or even scale issues. But If you are in a serverless environment, then it’s quite a bit different, especially if you're using a lot of managed services from the cloud provider, you really don’t have access to the underlying operating systems or hardware anymore. And I know some people have changed the “R” in MTTR to mean “recovery” or “resolution” since it’s really less about actually repairing hardware. But maybe we can start there, maybe you can give us your thoughts on what's different with how we respond to incidents in serverless versus how we would respond to incidents with more traditional applications.

Emrah: Definitely. So in traditional applications, as you say, there are some resources that we can easily gather the information when we see some problems, some incidents in our system. But in serverless, on the other hand, it is like you have different piles of logs, which it comes out of box from CloudWatch, from the resource that Cloud vendor propose. But these are actually separate, and these are not actually giving the full picture of what happened in the distributed serverless environment. And what you need here is that the problems are different. In a normal environment, the problem, most of the time, was actually about scalability and you were responding to that by giving more resources, by just increasing the power of your system. But with serverless, the problem is about like some problem occurs in any kind of a system in a distributed network and you need some more than log files. You need like all three pillars of observability, which is called traces. In our case, it is distributed traces, which shows the interaction between Lambda functions and the managed APIs and the managed resources and third-party APIs, and the local traces, which shows what happens in the Lambda function, and the metrics and the logs.

Jeremy: Yeah, right. And I think you’re right that the distributed nature of serverless is something that might be relatively new to people as well, so just figuring out where the problem is, or what component is causing the issue, is a challenge in and of itself. So the point about metrics is interesting too, because as you just said, the scalability is handled by the cloud provider for you with most of these services. So we’re likely not as worried about low level metrics like CPU usage anymore. So what are the signals of failure, like, how do we know that something is broken? What are the things that tell us something might be wrong in our application that we might want to address?

Emrah: Yeah, sure. So, like, if the scalability is not the problem, so what might be the problem? So what might be the good metrics that we should look at? In this case, there are some metrics which are actually very predictable by everyone listening here. But they are actually saving our system’s availability a lot. Say first, and the most important is actually latency, because of our aim to not receive timeout alerts, right? So the latency metric, the duration of invocations metric, is something that we should keep our eye on. So you need to keep an eye on how long do our functions take? So you need to see that if the duration is approaching to timeout, if there is, we should check what might be the reason we should check that? Is there something? Is there a problem with the third-party APIs? Is the problem with the resources that we are using? And this gives you like, when you see a latency, you should be approaching it very, very carefully because you don't want to be in the storm of timeout errors. So the second metric, in my opinion, is that memory usage. So you know, we are provisioning a memory to Lambda function. And this is the only thing that we control in serverless. Most of the time, developers are giving the memory more than it actually requires just in order to increase, speed up the IO and throughput and let’s say the CPU. But, in this case, we are having problems with the cost. You know, because whenever your function gets triggered, it runs for a time, and our billing is decided by GBs per second. So in this case, if you allocate more than necessary memory, we may be losing some money for Lambda. This might be very negligible if you don't use Lambda excessively. But if you're using Lambda in production and you're using Lambda and serverless mostly, you'll have some problems with the costs. In order to do that, you should tune your memory accordingly, an...

About Hillel Solow

Hillel is passionate about security innovation, and is driving product innovation and security at Protego. Prior to co-founding Protego, he was CTO in Cisco’s IoT Security Group, where he worked on innovative security solutions for new technology markets.

• Twitter: @hsolow
• Blog: protego.io/blog
• Protego: protego.io
• Twitter: @ProtegoLabs
• LinkedIn: https://il.linkedin.com/in/hillelsolow

Transcript

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

Hillel: Hi, Jeremy. Thanks so much. It’s a real honor to be here.

Jeremy: So you're the co-founder and CTO at Protego. So why don't you tell all of our listeners a little bit about your background and what Protego is up to?

Hillel: Sure. Thanks. So Protego is a security company focused on serverless security? We've been around for a couple of years. Prior to that, I had spent about 20 years in security at companies like Cisco and various other companies. And we really started Protego because we saw that serverless and cloud native was going to really usher in a wave of changes in how we deploy applications and build applications. And that was really going to upend a lot of what we do in security. And so we really focused on trying to ground up understand what is it about serverless and cloud native applications that changes? What's the best way to secure them? What do people worry about? And how do we help them solve those problems?

Jeremy: Awesome. So I wanted to talk to you about serverless security in the real world, and by that I mean the things we are actually seeing. Because I think that there's a lot of misinformation that is out there. And I know there's a lot of security companies starting to focus on serverless and cloud native. And every once in awhile we here about these security breaches in the news, so I think this is just a good opportunity for us to talk about what we really have to worry about. I mean, obviously want to have a good security posture for whatever we do in the cloud. But maybe we could start by discussing a recent, sort of, high profile, or highly publicized, successful attack like Capital One, for example. So I know this wasn't serverless related, but what are your overall thoughts on that attack? Does that scare people when they see something like the Capital One thing?

Hillel: Yeah, it is interesting because I think Capital One has done a really great job of leaning into the cloud and taking advantage not just from a development and deployment perspective, but from a security perspective of everything that cloud can offer. So it's a bit unfortunate now that they're going to get hit on the head here. I don't think it's a result of them moving to the cloud. To a large degree, this kind of attack that we’re looking at, it's kind of similar to the other kinds of Equifax attacks in some ways. You know, it's some misconfiguration and some access to an EC2 machine machine that then had access to some S3 buckets that shouldn't have had access. So those kinds of things, you know, obviously they can happen across any kind of infrastructure. The fact the Capital One is leveraging, you know, Amazon to do a lot of the securing of the infrastructure below what they're doing is great. It does highlight the fact that at the end of the day, though, we're all responsible for our own applications. And Amazon says that you know, day and night. And so for us to focus on the things that you know, that we deploy our business logic, that's really important. It’s important, obviously for Capital One, and I think you know, they do a great job of it for the most part here, and obviously they're going to have to improve. But I think for all of us, it's a lesson in how careful we need to be about applications security and about how we're using the cloud. Because just because Amazon is securing the underlying platform might lead us to believe that we don't have to deal with security. And it’s obviously not true.

Jeremy: Yeah, definitely. All right, so let's talk about the first aspect of this, because like I said earlier, I think there’s misinformation out there about what it means to be serverless and what your security posture becomes once you go serverless or even just move to the cloud in general. So there's this concept of FUD, right? This fear, uncertainty and doubt that you tend to see a lot of people and companies using to maybe “exaggerate” the risks. And I know your team is great at sort of shutting down the FUD, right, just giving people real, honest answers. Which is really refreshing. So maybe we can jump into that, and just give me your thoughts on how you feel about — you know, this idea of people scaring people, by spreading misinformation about the security of serverless.

Hillel: Yeah, look, I don't want to discount the value of fear. You know, I think if you're a security company, it's nice to be selling a product that solves the problem people are really worried about, and that's obviously important. But I think this notion of us becoming hysterical about things that aren't really issues is something we need to avoid. And specifically for us, as we’ve looked at serverless and how it changes security, I think one thing is really clear. Serverless is not less secure than other things. I think, you know, in a lot of ways, serverless applications stand to be the most secure applications that organizations deploy for a bunch of interesting reasons. They do raise some interesting challenges in terms of where do I put the stuff that I used to run on machines or where do I put things that don't scale the way that I want them to scale in the serverless world and things like that. And obviously they do create different types of opportunities for attackers. They do change some of ways attackers are moving, but overall I mean, my strong belief is if you're making the move to serverless, you're going to get a net win on security. You just need to take advantage of a lot of what's out there. And for us, you know, I'll talk a little bit later about what we do, but in particular, a lot of what we focused on is: hey, what happens when you move to serverless and cloud native? What new opportunities are there? And how do we leverage those for security in a way that maybe in the past was challenging?

Jeremy: Yeah, and I think the other piece of that, too, is that you have developers that are now much closer to the stack. And I've said this a million times, but this always makes me a little bit nervous because there are some new things that a developer might be responsible for when deploying and securing your application code in serverless. And like you said, the infrastructure security provided by the cloud providers already gives you this great foundation. But, if you don't have those skillsets or you're just not used to implementing IAM policies because maybe they were handled by Ops people or there were tools like WAFs and things like that, that gets a little bit scary for me anyways, when I see what some of the younger or junior developers do. And certainly that’s part of their cloud learning experience, but without proper controls in place, it does open up risks. So let’s talk a little bit more about what's different with serverless security versus more traditional security systems. And one...

About Slobodan Stojanović

Slobodan Stojanović is CTO of Cloud Horizon, a software development studio based in Montreal Canada, and the CTO of Vacation Tracker. He is based in Belgrade and is the JS Belgrade meetup co-organizer. Slobodan is an AWS Serverless Hero, Claudia.js core team member, and co-author of "Serverless Applications with Node.js" book, published by Manning Publications.

• Twitter: @slobodan_
• Vacation Tracker: vacationtracker.io
• Cloud Horizon: cloudhorizon.com
• Claudia.js: claudiajs.com
• Serverless Applications with Node.js: manning.com
• Blog: serverless.pub

Transcript

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

Slobodan: Thanks for having me.

Jeremy: So you're the CTO at Cloud Horizon and Vacation Tracker. So why don't you tell the listeners a bit about yourself and what these two companies do.

Slobodan: Yeah, so for the last seven years, I’m a partner and CTO at Cloud Horizon.  We basically do services for companies, and we build web applications for them. We worked with start ups and some enterprise companies and things like that. For a long time, we thought about, like, building a product. So last year, we finally started doing that. And we built a small tool that will help us to, so whenever our... we have, like, almost 30 people in the company and it's really hard for us now to track who is on a leave and who will be on a leave at some point. So we built a tool to help us out, to track just that. We don't need the full HR system and things like that. So we used serverless to build Vacation Tracker, our product, which is basically a slackbot and now web application that will help you to manage leaves for your company in just a few clicks, and people can request leaves through Slack and things like that. Besides that, I'm  writing a lot about serverless. Not a lot in the last couple of weeks. But before that, I wrote a book about serverless called “Serverless Applications with Node.js” with my friend Aleksandar Simović and I have a couple of Medium posts and a few other articles that are explaining mostly testing architecture of serverless apps. So, that’s it, basically.

Jeremy: Awesome. All right, so I wanted to talk about testing in serverless applications. And so maybe for people who are either new to development or, you know, are maybe used to different,  ways of testing. I mean, why is testing so important? Let’s maybe start with that.

Slobodan: Um, probably the best example I saw so far is the story, one of the stories from the previous book from Gojko Adzic called Humans vs Computers. So there was a guy somewhere in, I think, US that wanted to have custom plates for his car and he tried to fill out the form and he was into sales and boats and things like that. So, he had three choices in that form. First one was like ‘boat’, second one was ‘sailing’ and he didn't want the third choice, so he tried to leave it empty. He wasn't able to do that, so he typed ‘no plates’ or something like that. The first one was occupied, the second one was occupied, so he got ‘no plates’ plates. That was fun so he kept them and after a month, he started receiving a lot of tickets for parking because, you know, in the software for the guys that were filling the tickets for parking, no one predicted that there will be a guy with no custom plates or without plates. And whenever they don't get the plates, they just typed something. And most of time, they typed ‘no plates’ plates. So with testing, they would probably have handled that thing much before it hit the production and everything. So our applications are not perfect. There are so many things that when people start using, that can do in our applications. And when we start testing first we do some analytics of our application and think about the end users and the way that they will test our application. And on the other side, when our application grows really big it's easier for us to, like, be sure that we didn't break something. Unless we wanted to break it, of course.

Jeremy: Right. And when people are building applications, too. I mean, this is something where I mean, I'm a big fan of test-driven development. Where you you actually write your tests first and then you write code to make the tests pass, right? Because then you know what the expected outcomes are, as opposed to, you know, kind of going back after the fact and trying to make some changes there. So, let's talk about testing with serverless, right? Let's get a little bit specific. So is there, or are there, different things that you need to do or, sort of, what's different about testing serverless versus maybe testing a traditional monolithic application?

Slobodan: There are a few different things but, in general, testing is still the same. You want to check if your application works and the way that you want it to work. But some of the things are not your responsibility anymore. For example, infrastructure is, like, the responsibility of your vendor, such as AWS or Microsoft or someone else. So there's no point in really testing that part because that's not really something that, they have their own testing, things like that. But you still need to be sure that your business logic is working in a way that it works. And also all serverless applications are basically microservices, that they're working together. Most of the time, you don't have one monolithic application that is just uploaded to AWS Lambda or something like that. Most of the time, you have, like many different functions. For example, in Vacation Tracker we have, I think more than 80 functions now that they're working together. So it's really important to be sure that all those small services are working together the way we want them to work together, and that our end users have a decent experience and that they can use our application.

Jeremy: Right. And so that the types of tests that you would run I mean, you're still gonna do unit testing, right?

Slobodan: Yeah. So, basically, these types of tests are not that different. We still want to have unit tests because they are still the fastest. But, we also want to have integration tests, that are more important than ever, because we want to check if all these things work in integration, not just our code with the database, but maybe two different Lambda functions that are talking through some SNS topic or something like that. And of course, you wanted to have some kind of end-to-end tests. And maybe UI tests if your application is heavily using UI and things like that. So you still want to keep all these different types of testing that we had in previous non-serverless applications.

Jeremy: So, the other thing I think that's important about UI tests and integration tests is with serverless, they're not quite as expensive as they were before, right?

Slobodan: So yeah, one of the things that I used to kind of show that these testing pyramids. So, testing pyramid was defined by, I think Mike Cohn in his book Succeeding with Agile, a couple of years ago. Probably much more than that, actually, 10 years ago or something like that. So, ...

About Gunnar Grosch

Gunnar is Cloud Evangelist at Opsio based in Sweden. He has almost 20 years of experience in the IT industry, having worked as a front and backend developer, operations engineer within cloud infrastructure, technical trainer as well as several different management roles.

Outside of his professional work he is also deeply involved in the community by organizing AWS User Groups and Serverless Meetups in Sweden. Gunnar is also organizer of ServerlessDays Stockholm and AWS Community Day Nordics.

Gunnar's favorite subjects are serverless and chaos engineering. He regularly and passionately speaks at events on these and other topics.

• Twitter: @GunnarGrosch
• Webpage: https://grosch.se
• LinkedIn: linkedin.com/in/gunnargrosch
• YouTube: youtube.com/channel/UCTltOOcP1UZTpEQKQjjO-5Q

Links from the Chat

• Gremlin: gremlin.com
• Chaos Toolkit: chaostoolkit.org
• Adrian Hornsby Lambda Layer: github.com/adhorn/aws-lambda-chaos-injection
• Thundra: thundra.io
• Yan Cui's Article: hackernoon.com/how-can-we-apply-the-principles-of-chaos-engineering-to-aws-lambda-80f87e3237e2

Transcript

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

Gunnar: Hi, Jeremy. Thank you very much for having me.

Jeremy: So you are a Cloud Evangelist and co founder at Opsio. So why don't you tell the listeners a bit about yourself and maybe what Opsio does?

Gunnar: Yeah, sure. Well, I have quite a long history within IT. I've been working almost 20 years in IT, ranging everything from development through operations, management and so on them. Um, about a year and a half ago, we started a new company called Opsio. And we are a cloud consulting firm. Helping customers to use cloud services in any way possible and also operations.

Jeremy: Great. All right, so I saw you speak at ServerlessDays Milan, and you did this awesome presentation on Chaos Engineering and serverless. So that's what I want to talk to you about today. So maybe we can start with just kind of a quick overview of what exactly chaos engineering is.

Gunnar: Yes, definitely. So chaos engineering is quite a new field within IT. Well, the background is that we know that sooner or later, almost all complex systems will fail. So it's not a question about if it's rather a question about when. So we need to build more resilient systems and to do that, we need to have experience in failure. So chaos engineering is about creating experiments that are designed to reveal the weakness in a system. So what we actually do is that we inject failure intentionally in a controlled fashion to be able to gain confidence so that we get confidence in that our systems can deal with these failures. So chaos engineering is not about breaking things. I think that's really important. We do break things, but that's not the goal. The goal is to build a more resilient system.

Jeremy: Right. Yeah, and then so that's one of the things that I think maybe there’s this misunderstanding of too is that you're doing very controlled experiments, as you said, and this is something where it's not just about maybe fixing problems, either in the system, it's also sort of planning on for when something goes down. It's not just finding bugs or weakness, it's also like, what happens if DynamoDB for some reason goes down or some backend database like, how do you plan for resiliency around that, right?

Gunnar: Yeah, that's correct, because resiliency isn't only about having systems that don't fail at all. We know that failure happens, so we need to have a way of maintaining an acceptable level of operations or service. So when things fail that the service is good enough for the end users or the customers. So we do the experiments to be able to find out how both the system behaves and also how the organization, their operations teams, for example, how they behave when failures occur.

Jeremy: Well and about the monitoring systems too, right? I mean, we put monitoring systems in place, and then something breaks and we don't get an alarm. Right? So, this is one of the ways that you could test for that as well.

Gunnar: Yeah, that's a quite common use case for chaos engineering, actually, to be able to do experiments to test your monitoring, make sure that you get the alerts that you need. No one wants to be the guy that has to wake up early in the morning when something breaks. But you have to rely on that function to be there so that PagerDuty or whatever you use actually calls the guy.

Jeremy: And you said this is a relatively new field. You know, when you say new, it's like a couple of years old. So how did this get started?

Gunnar: Well, it actually started back in 2010 at Netflix, so I guess it's around nine years now. And they started a tool or created a tool that was called Chaos Monkey. And the tool was created in response from them moving from traditional physical infrastructure into AWS. So they needed a way to make sure that their large distributed system could adapt to failure so that they can have a failure. So they use Chaos Monkey to more or less turn off or shut down EC2 instances and see how the system behaved. So, that was in 2010, then I guess the first chaos engineer was hired at Netflix in 2014. So about five years ago, and in 2017, the team at Netflix published a book that's on Chaos Engineering. I think it's out on O'Reily Media, which is like the book on Chaos Engineering today that's used by most people who use chaos engineering.

Jeremy: So we can get into some more of the details about running the experiments, so I want to get into all of that, but I'm kind of curious, because this is something where, especially with teams now, and maybe as we get into Serverless too, you've got developers that are closer to the stack, there may be less OPs people or more of this mix. So is this like a technical field? Is it the devs that do it, the OPs people, like who's sort of responsible for doing this chaos engineering stuff?

Gunnar: Yeah, that's a good question. I would say that it's a question that's being debated in the field as well. Where does chaos engineering belong? And I think it's different in different organizations. Some teams have specific or some organizations have specific teams that are only working with chaos engineering like Netflix, like people at Amazon as well. But other organizations, they use chaos engineering and it’s spread out in the organization. So it might be operations that works with chaos engineering. But it also might be a DevOps team or just developers as well. But to do the experiments, you need to involve more or less the entire organization. So you use people from from many teams.

Jeremy: Right. Cause you're gonna run, in some cases, you run this earlier on where you’...

About Ran Ribenzaft:

Ran is a passionate developer, with vast experience in network, infrastructure, and cyber-security. He's constantly chasing new technologies, with a current focus on Serverless. He is an open source contributor and currently the co-founder and CTO at Epsagon, a tool for monitoring serverless applications.

• Twitter: @ranrib
• Epsagon website: Epsagon.com
• Epsagon blog: Epsagon.com/blog

Transcript:

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

Ran: Thank you very much for having me, Jeremy.

Jeremy: So you are the CTO at Epsagon. So why don't you tell the listeners a little bit about yourself and also what Epsagon is doing?

Ran: So I'm Ran, the co-founder and the CTO over at Epsagon, based in Israel, Tel Aviv, a fun place to be, very warm. In my previous roles, I've been doing mostly cybersecurity stuff. So mostly getting into kernels and things that I can't tell you, you probably heard some of them in the news. But let's keep it discreet. And in my recent role, I'm the CTO here at Epsagon, a start up where I'm one of the co-founders, and mainly focuses on monitoring and troubleshooting modern applications. But in general, the idea is to have a single platform where you get both the monitoring capabilities, which is "is my application working properly," "is it meeting the SLAs performance,"  and so on. And the troubleshooting part, where something bad happens, you need to scroll through the logs and correlate between them and do all this distributed tracing. That's Epsagon in a nutshell.

Jeremy: Alright, great. So I wanted to have you on because I want to talk about observability in modern applications, and by modern applications, we mean cloud native, or serverless, or distributed, or whatever sort of buzzword we might want to use to describe it. But as our applications grow beyond the traditional monoliths, being able to observe what is happening in your applications is a huge part of what we need to do when we are building these modern, interconnected systems. So maybe you could just give me a minute or so on what's the difference between your traditional monitoring and observability systems, and where we are now and what's changed ?

Ran: Definitely. So it starts with the change in our infrastructure in our way we code. So if we used to have this monolithic application running on our on-prem servers, so the things that you wanted to monitor are like: what is the network throughput, and what is the CPU usage, and hard disks and so on. And, you know, just making sure the application, the process itself is alive there. But shifting to more modern application, which I think in my mind the modern application is something that you don't mess with the infrastructure around it. You get most of the services out of the box working for you in a matter of configurations that you just can, you know, tick some boxes that I want this feature and so on. And you just built your own business logic through that where it can run — I don't care whether it's in your server, something like a function of the service or other thing. So this is modern application, and in this kind of modern application, there's a big difference in what you want to monitor. Honestly, we're doing monitoring to make sure our business works. Our application is our business. I want to make sure it works, so things like how much CPU is being consumed or network throughput, or all these kinds of metrics that just show me charts about infrastructure are getting irrelevant over time. Like, for example, if I used to have a chart of how much CPU usage my database is consuming, so now we don't really care if I'm going to a managed database - a fully managed one, not like a semi-managed - I don't really care about the CPU or anything else. I just want to make sure it works, and my application can speak to it at the right timing, at the right performance, and it gets the right results. So that's the first thing. The second thing is mostly about the nature of these kind of applications, which we broke them from being a big monolith, a big single monolith, to multiples of microservices, you can call it microservices, service, nanoservices, but the fact that there was one giant thing that broke into 10 or hundreds of resources, suddenly presents a different problem. A problem where you need to understand what is the interconnectivity between these resources, that you need to keep track of messages that [are] going from one service to another, and once something bad happened, you want to see the root cause analysis. This is like a repetitive thing that you can hear over and over. This root cause analysis, so the ability to jump from the error - the error can be like a performance issue or like exception in the code - all the way to the beginning. The beginning can be the user that clicks on a button on your business website that caused this chain of events. So these are the kinds of things that you want to see where, in traditional APMs, in traditional monitoring solutions, you don't have it. And in the future, once you'll find it more and more like that.

Jeremy: Yes, so you mentioned, you said logs. You said metrics. You said interconnectivity. You talked about a couple of different things, and I think it's probably important for listeners who maybe aren't 100% familiar with what observability is. There's this thing called the three pillars of observability, which are logs, metrics and traces. So maybe we can talk about that and you can sort of tell us why each one of those things is important.

Ran: Yeah, I'll start first with the metrics. So metrics are like the key component that you can ask questions about. Let's say how [many] events that I got per day, how [many] purchases, how [many] events of [this] kind that promote my business [are there] per day or per timeframe that you want to see. These kind of metrics are the base unit that you want to monitor. Now, when something bad happens in this metric, sometimes you need to see something bigger than just a number that will tell you, "Hey, we found out that the amount of transactions that you're seeing per day is lower than 100." So you want to see a trace or, in my opinion, a trace is more like a story. What happened — like tell me the exact event where this metric was below that 100 or the KPI that I've measured. I want to see what you talked with, which resources were being involved, how long each kind of these operations took, and why or how is it different from being a good trace. Now, when you wanna dive even deeper, so you need to get to your logs. Logs are like the ultimate developer utility to troubleshoot problems. I mean, regardless, what you'll see in metrics or in traces, logs are the core thing that developers put in their code in order to troubleshoot and debug their applications and often, you want to see correlated to one another. So, for example, I want to ask these questions: "How many purchases did I have on my website in the specific day?" Now we'll see there is a spike, or the opposite of a spike, some down in their registration. It's probably going to be because of a problem. So I want to see all the traces that correlate to these specific events, and I want to see all the logs that correlates to the traces that have found to this metric. So all three are connected to each other and all this observability, which is a nice buzzword, it's a just a translation of being able to monitor our business in production. That's for me, the things logs, m...

About Taylor Otwell:

Taylor Otwell is the creator of the Laravel framework, Laravel Forge, Envoyer.io, and Laravel Vapor. Before building Laravel, Taylor was an enterprise .NET and COBOL developer. He now works on Laravel and its ecosystem of tools full-time.

• Twitter: @taylorotwell
• Laravel on Twitter: @laravelphp
• Laravel: laravel.com
• Laravel Vapor: vapor.laravel.com
• Laravel Forge: forge.laravel.com

Transcript:

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

Taylor: Thanks for having me.

Jeremy: So you are the creator of the Laravel Framework, which is a very popular framework for PHP. So why don't you tell the listeners a little bit about yourself and what Laravel is and what it does?

Taylor: Sure. So I started programming professionally in 2008 after I graduated college, and I was originally a .NET developer in the enterprise world and started tinkering around with PHP on the side in 2010, and sort of in the fall or winter of 2010, I wrote my own PHP framework, sort of inspired by a variety of things: inspired by Rails, inspired by my experience with ASP.NET MVC, inspired by Sinatra and Flask and all these other frameworks, and sort of put something out there in the PHP world that sort of riffed on all of those ideas and brought them together in sort of a really productive way, I thought. And so I put it out there in 2011 and you can think of it as sort of Ruby on Rails for PHP, mainly. So it has, you know, controllers and routes and a database ORM and queued jobs and all kinds of other stuff to let you build web applications in PHP in a very productive way.

Jeremy: Awesome. So people are probably wondering why you're on a serverless podcast. But recently at Laracon, you just announced Laravel Vapor. So why don't you tell us about that?

Taylor: Yeah, so Vapor is something that I've been working on for about the last nine or 10 months, full-time, 40 hours a week. And it all started really over a year ago. I was just really inspired by sort of the serverless ecosystem, what people like Zeit were doing for JavaScript with their Zeit Now product and I really wanted something like that for PHP and something that could tell sort of the whole story for PHP, because there's a lot of moving parts that Laravel developers expect if they were to go on serverless like, you know, what do I do about my database migrations? What do I do about my queued jobs? And so I wanted to build a product around serverless that sort of made sense for Laravel developers and that they would understand, that would provide a really good experience for them.

Jeremy: So I want to jump into the details of Laravel Vapor. But let's start with some background on Laravel. So you said it was sort of this Ruby on Rails for PHP. So what types of applications do you see people building with Laravel now?

Taylor: Oh, gosh. I've seen everything from help desk, you know, accounting applications. I've seen, you know, all kinds of back-office applications, intranet applications. Of course, I've written Forge, a server management platform on Laravel. I have a zero downtime deployment platform on Laravel. So I've really seen such a variety - hotel room management platforms - almost anything you can think of really, I've seen on Laravel.

Jeremy: So is this something that anything you can build with the Laravel Framework now, you're going to be able to just do serverless-ly with Vapor?

Taylor: That's sort of the hope, you know, that your application will translate well and there's a few differences, you know, when you're operating in serverless, we can get into. But that was sort of the goal, though, is to make it so you can deploy on Vapor, and things sort of work as you would expect, and you could build your application as you're used to in a traditional server environment. You can just deploy it on vapor and sort of have the same experience. That was the end goal I was shooting for.

Jeremy: So does the development workflow change now that you're dealing with different types of resources?

Taylor: Sure, your local development workflow is a little different depending on what you choose to use. You know, most Laravel applications are used to interacting with something like MySQL. We also ship with Vapor, a sort of a docker container, where you can run all of your unit tests against the production PHP build that actually runs on a Lambda side of Vapor. So we try to provide some tooling to make that experience a little better.

Jeremy: Very cool. So you mentioned this interest in sort of the serverless ecosystem, but what were your main reasons for building Laravel Vapor?

Taylor: Because I don't ever want to think about servers ever again. Basically. So it goes back to sort of Laravel Forge where really I built and released Laravel Forge in 2014. Sort of the idea there was, you know, I was building Laravel applications professionally, and I was constantly configuring servers with nginx with PHP, with Redis or whatever I needed. You know, and I was building them on let's say, like, DigitalOcean or Linode or some VPS provider and I had written bash scripts to do all that and automate all that. And so I sort of built a platform around that called Laravel Forge. And you can, you know, link your DigitalOcean account, create a 2GB server, and it installs everything you need, and then you can deploy your application out there. And that's all great. Like that works really well for a lot of applications. But there's still like a lot of headache that comes with that, even though a lot is automated for you. For example, like my operating system goes out of date. I sort of kind of have to worry about SSL certificates renewing. I have to worry about various vulnerabilities. I have to worry about all kinds of stuff I just don't want to think about. And then if I'm load balancing those servers, now I've got, you know, 5-10 servers to worry about. All those same problems just multiplied. And so while Laravel Forge does provide a lot of automation and sort of the traditional server environment can be automated in some fashion. The idea of going totally serverless and just never ever thinking about servers at all, never thinking about, you know, how am I gonna load balance them. All of that sounded really, really appealing to me, after managing, basically, thousands of servers with Forge so that was really appealing. And that's what really drew me to the whole ecosystem.

Jeremy: So was there something that prompted this? I mean, at what point did you look at AWS or Microsoft Azure and say, "Okay, now I can go serverless with this." Because PHP wasn't even supported as a runtime until November of last year when they came out with with custom runtimes for Lambda.

Taylor: Yeah. So there were some key things that happened. I remember the first most important thing was we could get Laravel up and running with a Node shim where when a HTTP request comes in, we use Node to sort of invoke PHP. And people were doing this with other languages too, you know, before custom run times. But always the big problem for me was how are we going to  hook into the Laravel queue syst...

About Erik Peterson:

Erik Peterson is the CEO and founder of CloudZero. Previous to founding CloudZero, Erik was Director of Technology Strategy for Veracode and has nearly 20 years of software industry experience, including senior leadership and technology roles at HP, SPI Dynamics, GuardedNet and Sanctum. Erik has also held IT & InfoSec roles at Moody’s Investors Service, SunTrust Bank, U.S. Embassy Vienna, Austria and the United Nations International Atomic Energy Agency where he provided technical assistance to UN weapons inspectors.

• Twitter: @silvexis
• Email: [email protected]
• CloudZero: cloudzero.com
• CloudZero Twitter: @CloudzeroInc

Transcript:

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

Erik: Hey. Great to be here, Jeremy.

Jeremy: So you are the CEO at CloudZero in the great city of Boston. So why don't you tell the listeners a little bit about yourself and what CloudZero is up to?

Erik: Sure. So gosh, so I'm a recovering AppSec person, actually, by trade. I think I spent 20 years in the application ⁠— in the security industry trying to move the needle on one thing, which was to get developers to care about security. I didn't necessarily start there, but I I certainly thought a lot about application security through the years and where I think the applications security industry ended up is a good place, focused on the people who create the software that we care about. But about 10 years ago, maybe 11 now, in 2008, I got bit by the cloud bug and I started experimenting with AWS and taking that where I could take it. And I had the good fortune of bringing Veracode, the company I worked at before CloudZero, over into AWS and had a lot of fun doing that and learned a lot along the way. So, recovering AppSec person. Now true cloud connoisseur I hope.

Jeremy: And what's CloudZero all about?

Erik: So CloudZero. It's pretty simple. It gets back to my roots. I want developers to care about cost, right? And so CloudZero, we're the first cloud optimization platform that is specifically built to tie engineering decisions directly at cloud cost. You look at a lot of cloud optimization solutions today, they're focused on the finance team or parts of the organization that are outside of the people who are actually making the decisions writing the code. And so we want to empower DevOps team to make smarter engineering and infrastructure decisions. And we do that by giving them a platform that could allow engineers to understand in real-time the cost ramifications of their actions. So really powerful solution that, ultimately, we're going to help the business manage costs, move faster and drive innovation for it. And we love developers. We're focused on that world.

Jeremy: Do you have any big features coming out that you want to share with the audience?

Erik: Yeah. So we are building a whole set of capabilities for engineering teams to get right into the details of what matters most to them, which is how much are the things that they're actually building costing them, and take out all of the noise. You know, today if you go look at Amazon's Cost Explorer; you look at another product. You see all this data related to cost. All I care about is what is the thing that I'm working on right now? What does it cost me? And how are my decisions affecting that? So we have a number of new dashboards that are coming up for that and a few other little surprises around the corner around anomaly detection coming out this summer.

Jeremy: Awesome. So I wanted to have you on to talk about an extremely exciting topic that I actually, surprisingly, am a little bit passionate about because I do see a tremendous amount of value in this. But I want to talk about cloud computing costs. And obviously, you have quite a bit of experience in this, but where I want to look at this is we now have this sort of very, very granular billing that goes well beyond what maybe a SaaS company might provide. And obviously, you have SaaS bills and that's a metric that you could use. But now that you have cost associated with every sort of cloud engineering action that you take, how do we need to think about this differently? Maybe let's start there.

Erik: So, you know, I think every cloud engineer should view cost as something that they ⁠— their expertise in understanding the bill needs to be something that they feel proud enough to put on the resume. You think about what was the very first Amazon service. It was, a lot of times, it's really easy to say, "Oh, it's SQS or S3." No, it was actually Amazon Billing, right? Because...

Jeremy: That's good point.

Erik: Amazon wasn't going to do anything if they couldn't bill you for it. And over time, they've figured out how to, like you say, get deeper into the metered billing. We have a millisecond billing. EC2 used to be billed by the hour, and now could be billed even tighter than that. You go look at the reports. Everything is kind of normalized to the hour, and it's a little bit more complicated to figure out. But the key kind of thing here is, whether we know it or not, as software architects, engineers, DevOps engineers, when we moved from on-prem in the cloud, we had a whole lot of constraints that just disappeared overnight. And you know, this decision about how much things cost, what used to be made for us, somebody went and bought a bunch of servers. They put it in the basement, and that was all well and good. And then we just tried to maximize our usage of that resource. Now, somebody gave us an Amazon account, and our instincts, as engineers, are a little bit off, because our instincts are how can I get the fastest path to value for my customers, innovate quicker build, you know, new capabilities. And your intuition is to expand to use all available resources in front of you in order to achieve that goal, right? It's certainly what your boss is telling you or the CEO is telling you. And so we go, "oh, I have this infinite scale. Let's go nuts." The problem, the flip side of that, of course, is if I have infinite scale, I also need to have infinite wallet, right? If I don't have infinite wallet, then actually, the reality is I don't actually have infinite scale, and so as engineers, I think we need to move past caring just about performance and uptime, and we need to add a third item to our kind of list of operational metrics, and that's cost.

Jeremy: Yeah, and and I don't know how you knew that I have a bunch of servers in my basement. They're all turned off now, but I literally have a bunch of old servers in my basement.

Erik: All have some dirty, dirty little secrets.

Jeremy: Exactly. You wouldn't believe how many hard drives I have because I didn't want to throw them away when I closed down my data center. But so you mentioned⁠ - and I think this is important - you mentioned this idea of the sort of the purchasing decision, right? And in the past, it has always been okay, we need 100 servers. We need this many copies of Windows server or we need this Oracle license or whatever we need, and those things were fairly easy to plan for. And again, they were these purchasing decisions by sort of the, I guess, the C-levels or the purchasing department or something. And you w...

About Mike Deck

Mike Deck is focused on building a community of partners around the AWS Serverless Platform. He spent the first half of his career as a full-stack software developer building enterprise applications and coaching teams on agile delivery methodologies. For the last four years he’s been working as a solutions architect for AWS on the partner team helping both ISVs and consulting partners accelerate their pace of innovation using the cloud.

• Twitter: @mikedeck
• EventBridge Product Page: https://aws.amazon.com/eventbridge/
• EventBridge Documentation: https://docs.aws.amazon.com/eventbridge/index.html
• EventBridge Partner Information: https://aws.amazon.com/eventbridge/partners/

Transcript

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

Mike: Hey, Jeremy, thanks a lot for having me.

Jeremy: So you're a Solutions Architect at AWS, and I'm pretty sure most people are probably familiar with what Amazon Web Services does. But why don't you tell the listeners a little bit about yourself and maybe what a Solution Architect does at AWS?

Mike: Yeah, sure thing. So I'm actually on our Partner team, so I work as a Partner Solutions Architect, which means that I work with both our ISV and consulting partners to help them with kind of any technical questions they have, work with our ISV partners on their product roadmaps and how they're integrating with our services, helping them with architectural questions, and things like that. Been at AWS for about four years at this point. Been on the Partner team the whole time, and most recently, I've been kind of specializing in the serverless space. So working with a lot of our great ISV and consulting partners that are doing things around Lambda and API Gateway, as well as with the new service that we just recently launched.

Jeremy: Cool. All right, so speaking of services recently launched at AWS Summit New York, AWS launched this new product called EventBridge, which is sort of this, and you can correct me if I'm wrong, but sort of this cool extension to CloudWatch Events and since you're on the Partner Team or you're the Partner Team Solutions Architect for Partner Integrations with EventBridge, you obviously know probably more about this than anybody else. So why don't you tell us a little bit about EventBridge and sort of what it does?

Mike: Yeah, absolutely. So I think you know, it's definitely accurate to compare it to CloudWatch Events. So really kind of the genesis of this service was that, you know, we saw customers building more and more with this kind of event-driven model, and CloudWatch Events is really a fantastic tool for for doing these kinds of things. I think Forrest Brazeal had a blog post a little while ago about using CloudWatch Events to do awesome event-driven things. We see a lot of customers that are interested in this space. The event for pipelines projects came out, got a lot of traction, and so we realized that, you know, there's really this kind of need to build additional services that make it easier to build these kind of things. So we took the existing CloudWatch Events infrastructure and APIs and kind of extended them to add some additional features around integrating with SaaS providers to create more native event sources that you can use within your AWS applications, and then, yeah, extended those APIs to make it easier for customers to do things like creating custom event buses and patching to SaaS event sources, etc.

Jeremy: So what are some of those use cases then that customers might build with this?

Mike: Yeah, so, you know, I think that one of the obvious ones is: Hey, I want to trigger a Lambda function every time someone creates a new ticket in my CRM, for instance. Right? I want to go and kick off some sort of workflow. Or maybe I'm going to start a step functions or do something like that. Um, we also see a lot of customers interested in doing kind of audit-and-analytics type workloads. So I just want to ingest kind of the full event stream of all of the things that have changed out, you know, maybe in my identity management tool that I'm using. So every time a failed login happens, or every time a new user is registered, I just want to ingest that, throw it into a Kinesis Firehose Data Stream, and put it out into an S3 data lake so I can go and create with Athena or something like that. And then, obviously, you know, ML and and doing kind of AI inference and things like that on all of these various data streams is becoming super popular as well, so this gives you a great opportunity to, yo u know, every time a new email is opened in your kind of customer engagement platform, you can ingest that and add it to your modeler or do some sort of inference on it in order to drive additional kind of business decisions.

Jeremy: Yes. So those are some really cool sort of things that you can do with it. And I remember Forrest's article about sort of using CloudWatch Events and using custom events as basically almost like an SNS topic, in a sense. So maybe let's get into the nuts and bolts of EventBridge, kind of how it works. So with existing CloudWatch Events, you can use a, put events API or put custom events API or something like that, where, and then Forrest explains that in his article where you can send an event and then you can subscribe consumers to it. But why this extension? What's this idea of having separate event buses?

Mike: Sure. So, um, yes. So I guess there's a few different reasons that you might want to have different event buses. So like you mentioned with CloudWatch Events, there's really just sort of the default event bus in each region of your account. We publish all of these sort of native AWS events to that default event bus. And so those just kind of appear in your account automatically without your having to do anything. You know, the ability to create additional custom event buses now lets you kind of segregate these different application domains or different context, I guess, for the various different types of events that you need to ingest across your different surfaces and applications. It also gives you a good way to create separate channels for different SaaS applications that you may have that you're trying to build event-driven architectures on the back of. So, yeah, we can we can talk a little bit more about kind of the specifics of how it all works, but basically, every individual SaaS provider that you're integrated with is going to have its own event bus so that you can write rules against that, and keep all of those different events separated from the different sources.

Jeremy: All right, so I definitely want to get into the SaaS side of things because I think that's probably one of the coolest features of this EventBridge. But let's go back, maybe, and start at a lower level, talk about events, sources and targets. So what events were you, because you mentioned that you can get all of these events that are happening within your AWS account. So anytime a new account's created or new resource is created or something changes, there's these events that are sent to that default event bus. But now with this separate event bus, how would we subscribe sources to that or set targets to trigger Lambda function or other other s...

About Chase Douglas

Chase Douglas is the co-founder and CTO of Stackery.io, the leading serverless acceleration software solution. His experience spans the gamut of technical and managerial, specifically focused on how teams of developers build products collaboratively. In prior roles he has been a VP of engineering at a web application security company, technical architect of the New Relic Browser product, and an architect of the multitouch implementation for the Linux desktop.

• Twitter: @txase
• Email: [email protected]
• Stackery: stackery.io
• Stackery Blog: stackery.io/blog
• Stackery Changelog: https://docs.stackery.io/en/changelog/
• Live Stream Series: https://app.livestorm.co/stackery/
• Portland Serverless Meetup: https://www.meetup.com/Portland-Serverless-Architecture-Meetup/

Transcript

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

Chase: Hey, glad to be here.

Jeremy: So you are the CTO at Stackery, which is in Portland. Why don't you tell the listeners a little about yourself and what Stackery does?

Chase: Yeah. So I'm the CTO and co-founder of Stackery and I've spent my career figuring out how to manage complex systems. And as serverless as an architectural pattern started to take off I was really interested in finding how do we help people adopt that architectural pattern more easily? Stackery is a product, a tool set that makes it easier for anyone from individual developers on up to teams and organizations, but especially at larger sizes, manage to design, manage environments, deploy and at the other side, help monitor their serverless applications.

Jeremy:  I wanted to have you on the podcast today because I want to talk about serverless development workflows. And I think when people start moving into the serverless paradigm, we gotta sort of change the way that we think about developing applications and that you know everything from whether you're developing locally or developing remotely, or whether you're trying to do something like offline emulation or trying to do the remote testing things like that. Just what are some of your thoughts on sort of this idea of these serverless development workflows? How does it sort of change things?

Chase: Yeah, serverless itself is a different way of building, developing and including testing applications. And one of the things that we have to step back and recognize is that at the end of the day, we're still developing software, we're still testing software, but we need to find the right ways to be efficient at how we do those. It's slightly different in a serverless world, and so we once we find the right patterns. And once we start to use those as an individual or in the team, things actually speed up once again. So there is an interesting play here. Uh, but it's all about just finding the right mix and match of how to do the things we're familiar with when it comes to the development and testing.

Jeremy: Yes, so that makes a ton of sense. So what I think I'd like to do is sort of dive down into a number of these different topics, you know, break it down a little bit and get into I mean, because again, you're an expert. Stackery obviously, is all about building out these workflows or helping developers build these workflows. So I want to get into these these details here and let's start with sort of just really maybe 30,000 foot view. How has cloud sort of changed the way that we develop software?

Chase: Yeah. So the way that we've always developed software up until very recently was it would, in the end, be running on servers, whether it's in a data center or in the cloud. But these servers were monolithic, compute resource. That meant that typical architectures might be a LAMP style stack. You've got a Linux server, and you've got a MySQL database off to the side somewhere, maybe on the same machine, maybe on a different machine. But mostly as a developer, you're focused on that one server, and that means that you can run that same application on your laptop. So were we become very comfortable. We built up tooling around the idea of being able to run an entire application on our laptop, on our desktop in the past, that faithfully replicated what happens when that gets shipped into production in a data center or in the cloud. With serverless, everything is kind of a little works differently. You don't have a monolithic architecture with a single server somewhere or a cluster of servers, all running the same application code. You start to break everything down into architectural components. So you have an API proxy layer. You have a compute layer that oftentimes is made up of Lambda, though it can include other things like AWS Fargate, which is a docker-based, serverless, in the sense that you don't manage the underlying servers approach. So you've got some compute resource, if you need to do queuing instead of spinning up your own cluster of Kafka machines, you might take something off the shelf, whether it's SQS from AWS or their own Kafka service or Kinesis streams. There's a whole host of services that are available to be used off the shelf. And so your style of building applications is around how to piece those pieces together rather than figuring out how to put those and merge those all into a single monolithic application.

Jeremy: So how then do developers need to think differently? I mean, again, I'm super familiar with the LAMP stack. That was probably where I started. Well, I started with Perl and static text files, but we won't talk about that. But as we got a little bit more advanced and we started using things like the LAMP stack, obviously, it was very easy for us to just either test it locally or to even building in the cloud. It was, or not the cloud on our hosting provider, but we could just easily upload a new file and things would magically work for us. But as you mentioned, things get more distributed. Right? Once we go into this cloud environment, you've got multiple services working together. You don't own those services necessarily. If something breaks with those service is you kind of have to deal with that. So maybe what are some of the limitations that a developer might have to deal with when they're starting to move, you know, their production workloads to the cloud?

Chase: Yeah, for all the benefits you get from serverless, with its auto scaling and its capabilities of scaling down to zero, which reduces developer cost, you do have some things that you have to manage that are a little different than before. One of the key things is, if I've got, like, a compute resource like a Lambda function in the cloud that has a set of permissions that it's granted and it has some mechanism for locating, the external service is like SQS queue or an SNS topic or an S3 bucket. So it has these two things that it needs to be able to function the permissions and locations. So the challenge that people often hit very early on in serverless development is if I'm writing software on my laptop and I want to test it without having to go through a full deployment cycle, which may take a few minutes to ah to de...

About Marcia Villalba

Marcia Villalba is an AWS Serverless Hero and a software engineer from Uruguay, currently living in Helsinki. She currently works as a Full Stack developer at Rovio, and has her own consultancy company, Unicorn.codes. Marcia also hosts her own YouTube channel, FooBar, creating fun and creative videos and tutorials that focus on how to use AWS serverless technologies and managed services. She loves to help others in the serverless community learn about migrating to serverless, and publishes courses, all of which you can find on her blog.

• Twitter: @mavi888uy
• Instagram: foobar_codes
• Blog: marcia.dev
• YouTube: FooBar Serverless

Transcript

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

Marcia: Hello, Jeremy. Thank you for having me here and I hope my cat is not meowing because she's already meowing.

Jeremy: That's fine. My kids love cats. I'm sure the people listening will love them as well.

Marcia: She always appears in my video. So it's part of FooBar.

Jeremy: Perfect. So you are a full-stack developer and an AWS serverless hero. So why don’t you tell the listeners a little bit about yourself and what you've been up to lately.

Marcia: Yes. So I’ve been doing serverless since 2015 so Lambda was launched in November 2014. I started quite early on more or less when API gateway was announced and was able to connect with Lambda. And since then I've been just working on different types of projects. My first project was to migrate something to serverless and then I've been working on greenfield projects most of the time. Then one of the things I really like is to create content. So I think, besides my show, that's what I do the rest of the time - my shows, create YouTube content, and a lot of courses. I have a small consultancy where I help companies with workshops and training, some things like that. So I spend all day doing this serverless stuff.

Jeremy: I know that feeling. You have a blog too, right?

Marcia: Yeah, as well. My blog is not really a blog per se. It’s more or less where I gather all the content I create in one place. I used to use Medium but I quit. So I think blog is more like I can do whatever I want with it. It's just a place to have my content. But most of the content I create is video. It's the place I feel more comfortable. So YouTube is the place I hang out. I just put all everything there, but well, the blog is good too.

Jeremy: You do an amazing job with all of the videos. So thank you so much for all that stuff. So I wanted to have you on today to talk about AWS AppSync. So I've seen I've seen you do your talks before. You have a great talk on the subject and you've done videos on it and things like that. So maybe let's start by, just in case people don't know, because I think this is one of those – it’s not obscure if you are in this world, but if you're just kind of getting into it, I think AppSync is maybe an obscure sort of thing. And why that's different than API Gateway. Maybe you could tell us what is AppSync exactly?

Marcia: Well, in a few words, AppSync is is a GraphQL service. So it's managed GraphQL service by AWS. It’s a platform where you can kind of – AWS will take care of all the heavy lifting for the GraphQL. And you just basically need to put your schema and create your resolvers that are a bit. But basically the schema and the resolvers are the two proprietary things that you need in order to have a GraphQL application. The rest is very generic between every GraphQL implementation. So AWS create this platform and then you just do the smallest amount of work you can and get a working GraphQL server. And that's really good for, for example, creating mobile applications. It's really fast to create fast back-ends for mobile applications or to interconnect multiple microservices or do all kinds of things. So it's a very interesting service.

Jeremy: So it's basically like a managed Apollo server.

Marcia: Well, yeah, Apollo has their own platform as well, so they have their own AppSync. So, yeah, this kind of concept is – when I talk in my talk about the ways, because GraphQL is a specification. It’s not something that somebody –well, somebody wrote it down and then different people implement in different ways. So there is, like, three ways of doing GraphQL, as I said. Either you write your whole GraphQL specification yourself. You are a hardcore developer. You want to have your GraphQL done in Cobol and then you do it yourself - I don't know why. Then the most common way is that you use some library like Apollo. That's the most popular library that you just put it in a server, and maintain that server and this kind of serverless way of doing GraphQL is using a platform where all this heavy lifting of maintaining the infrastructure, and do we know the small connections that needs in order to hook up your library to your server. That is already done by the platform, and you just focus on your business logic. That is the main mantra of serverless.

Jeremy: Awesome. So let's actually talk about GraphQL specifically because again, it's another one of those things where I think a lot of people are very used to REST APIs that has been the way to do things for quite some time. I think it was Facebook that came out with GraphQL and…

Marcia: Yes, GraphQL was released by Facebook, but now it's owned by everybody.

Jeremy: So maybe just quickly explain what is GraphQL exactly?

Marcia: So first of all, GraphQL and REST are not like enemies. So you do not have to choose one or the other. And I think that's an important starter for the discussion, because people are like, well have my REST endpoints to use GraphQL. No, we are not talking one or the other. They're two different things. So GraphQL is a specification that when you implement, usually it sits between all your microservices and your clients, and it’s, thus, like an entry point for your application. So you can, instead of having multiple different endpoints and point to the different microservices independently, you can have one entry door and that's really convenient. For example, if you're doing, um, I don't know a mobile app and you have multiple different microservices with different people working on them, then you can combine all these requests and responses into something that is like a contract between the client and the server as a big entity. So that helps a lot of the client developers, because that's one of the big problems when client developers are starting to work on a project, they need to [really understand] the whole backend architecture, and sometimes there is really not a lot of need for them to understand that. So GraphQL will provide a contract where all the possible operations are specified. All that is a strongly-typed language. So all the operations request a response with really clear defined types that they have strongly-typed. So you know exactly what you can put in, what you can get out, and then when you do these operations that you'll get a type...