Episode #121: Educating Serverless Developers with Ivonne Roberts

November 29, 2021 • 55 minutes

On this episode, Jeremy and Rebecca chat with Ivonne Roberts about her new role at Bill.com, how she transitioned into tech and became an AWS Serverless Hero, what drew her to serverless in the first place, why making content is so important for your career, and much more.

Ivonne Roberts is a recently named AWS Serverless Hero and currently a Software Architect at Bill.com. Prior to joining Bill.com, she was a Senior Software Architect, Principal Engineer at Edelman Financial Engines, where she and her team were critical in the company’s adoption of a serverless-first software development philosophy. She has experience in modernizing applications as part of cloud migration initiatives based on serverless architecture, and her expertise includes researching new technologies and design patterns, building prototypes, establishing reference architectures, and gaining buy-in from members across the organization. On her blog ivonneroberts.com and her YouTube channel Serverless DevWidgets, Ivonne focuses on demystifying and removing the hurdles of adopting serverless architecture and on simplifying the software development lifecycle.

Transcript

Jeremy: Hi everyone. I'm Jeremy Daly.

Rebecca: And I'm Rebecca Marshburn.

Jeremy: And this is Serverless Chats. Hey Rebecca, how you doing today?

Rebecca: Hey, Jeremy. I am actually doing very, very well. I did something really special last night, which was went to a four-course dinner at a very esteemed Seattle restaurant.

Rebecca: And it was because I asked a friend to help me move, and instead of what I would have paid for moving services, I was like, "I will take us to the nicest place that we've never been in the city." So it was a really great way to spend those moving dollars.

Jeremy: Wow.

Rebecca: Yeah.

Jeremy: The last time somebody asked me to help them move, I think we got pizza and beer. So your idea is better. We should go with that next time. I like that.

Rebecca: Yeah, it was really nice. How are you? Is there anything you want to talk about before we dive in?

Jeremy: No, I mean, I think it's just, re:Invent's right around the corner, and yeah, I'm just getting ready to go. I'm excited.

Rebecca: Well, I'm excited too, and I'm also excited to introduce our guest today. Not only will she be at re:Invent, she'll be speaking at re:Invent, the Monday evening of re:Invent. We'll talk to her a little bit more about that.

Rebecca: Our guest today is a software architect Bill.com, a speaker, YouTuber, blogger, and AWS Serverless Hero, which means she's super close my heart as having been a head coordinator for the Serverless Heroes program. Ivonne Roberts. Hello, Ivonne. Thank you so much for joining us.

Ivonne: Woo-hoo. Hello. It's so nice to be here. This is so exciting to talk to you guys about serverless and all the magical stuff happening.

Jeremy: Well, I mean, we're excited to have of you here. And one of the things that I love about your story, and we try to do some research on our guests and look and see all the things that they're doing. And of course, you've been in the space for quite some time, and obviously Rebecca knows you from the Serverless Heroes program.

Jeremy: But what was interesting is just learning more about your background. You have a nontraditional background. I think I heard somewhere that you started out by maybe designing T-shirts or something like that, right?

Ivonne: I did.

Jeremy: And then you go from designing T-shirts, and then you end up becoming an AWS Serverless Hero working for Bill.com now as a software architect. I love hearing these types of stories, where are you start off doing something else, and then you make this transition into tech.

Jeremy: So I'm just really curious, if you could tell the listeners a little bit about what your journey into tech was like, and how you got to where you are today.

Ivonne: Yeah, so you're right. My first job out of college was to be a T-shirt designer. I literally was coloring for... Actually, I don't know how much I was paid back then. But it seemed like a lot to me back then, I'm sure.

Ivonne: All I had to do was take these little clip art images and fill in the colors. And there's this whole concept of for T-shirt printing that the colors have to overlap, and all these little nuances that you have to measure and calculate and so on and so forth. Which was really cool to get paid to do that, I think.

Ivonne: But I was really curious about computers and how it made life easier. I would do these little mini-scripts for... What is it? Adobe? I don't remember what their desktop app was for... Illustrator, I think it was.

Jeremy: Yes, Illustrator. Yeah.

Ivonne: There you go. So for Adobe Illustrator, you could create scripts that would then replicate your little image multiple times on the page, and doing little things like that.

Jeremy: Actions, right? Were they called actions or something like that?

Ivonne: I think so. You know, honestly, I'm not going to say how many years ago this was, but it was a while ago and my memory does not serve very well that far. But I really enjoyed that, being able to outsource my manual labor to a computer. And that whole concept of tinkering, and playing with things, and seeing how they break and then fixing them, was really cool to me.

Ivonne: At that same T-shirt company, I started working on their website, and helping them make updates, and make it not obvious that I had changed a lot of things. It still looked like whoever they paid way back when to design it. And it just built on from there.

Ivonne: Then I started doing like web design, and designing email blasts, and things like that. And the more I got into it, the more I realized, "Okay, I want to do this for the rest of my life. I want the paper to prove that I can do this so that somebody will hire me." And so I took a risk. I went to school at night, and I worked on that compsci degree to prove that I could do this. This was a lot of fun. I love this. And please hire me today.

Rebecca: And it sounds like you're still loving it. Can I be correct in making that assumption?

Ivonne: Yeah, I definitely do. I'm working at Bill.com right now. It's a new position for me. And so I'm going along this journey of showing them the magic of serverless. Because to me, honestly, serverless is magic.

Ivonne: And my first gig into demoing this was creating this tic-tac-toe app that's serverless, and I don't have to worry about relational database or anything like that. So that was a lot of fun to me to be able to say, "For the last week I've been paid to create a tic-tac-toe game, to be able to teach a lot of these really cool concepts to my coworkers."

Jeremy: Yeah. That's awesome. And speaking of serverless, this is a serverless podcast, so I'm curious. You go through this process, and I think you got a master's in computer science. And then you worked with, I think I saw on your resume, you worked with EC2, and some of those other things that you probably had to.

Jeremy: So what was it that when you... I mean, first of all, how did you discover serverless? And then, once you did, what did you think was magic about it? Or what really drew you to say, "Yeah, this is how I want to build applications?"

Ivonne: Let's see. So how did I start with serverless? I think, while I was working on that master's program, there was a project where we had to create an FTP application with S3 backing it. Which was pretty neat, because, again, there were no servers in that.

Ivonne: And while I think it's a little bit of a stretch to say that S3 is serverless, I liked the cool part of not having to worry about that hard part of a server, and storing data. I think it just kind of built from there when... Was it 2015 that Lambda was announced?

Rebecca: End of 2014.

Jeremy: Yes.

Ivonne: End of 2014.

Rebecca: Yeah.

Ivonne: There you go. And when that was announced, it was pretty cool. One of my coworkers had started tinkering with it, and it was just so cool to be able to see how much he was able to accomplish. I went on to play with it, and I created one of those gift beacons that you put in an email so you'd be able to track if somebody opened it, and so on and so forth.

Ivonne: And to be able to have something up and running so quickly without much heavy lifting, to me was just like, "Wow. This is where it's at." I will never SSH into another EC2 instance again. I'm not going to do that whole get a Java heap dump, or all that kind of stuff. And that's where it started for me, and just kept getting deeper and deeper into it.

Rebecca: So I wanted to go into this a little bit more, and you already, cat's out of the bag in terms of Lambda being announced in late 2014. Okay, so in 2013 you were at Financial Engines. In late 2014, Lambda was just getting started. And by 2016 you were establishing patterns in development processes for serverless microservices-based architectures using, I would say getting a whole band together almost, Lambda, API Gateway, DynamoDB, at that time.

Rebecca: And while that's a long time ago for you, there are lots of companies just now who are starting to ask themselves whether we should go down this route. Lots of teams are trying to secure internal buy-in. So I'm wondering, if you can get in the way-back machine, can you share a bit about how those internal conversations went for you? And if there were specific metrics or outcomes that enabled you to convince the organization that this was the direction to move in?

Ivonne: I think at that point, it really was about empowerment. The manager I had was more of like, "Okay, there's this new toy I heard of, see what you can do with it." And really gave us this really opened... I don't know what the right word is. But there wasn't a set requirement like, "You have to accomplish this. You have to do this. You have to do that." It really was, "Just try it. See what happens."

Ivonne: Some of my coworkers had started, and I came in on the tail end, creating an app for EV Concierge is what we called it. Where basically folks at the company could register to reserve a spot to be able to charge their car downstairs in the garage.

Ivonne: And so we pretty much got to do whatever we want. We ran into issues. In the beginning, we actually used, what is it called now? Serverless Inc, or Serverless Framework?

Jeremy: Serverless Framework.

Ivonne: That you work with very well. So we actually started out with that. There were some issues we had here and there, and then we kept iterating on that pattern, on what made it easier for each additional microservice to get rolled out. And that was really cool.

Ivonne: For him, what that metric was, what that outcome was, was that a team could take a business case, take a use case, and roll that to production within days instead of weeks and having to deal with procurement of, well at that point it was an EC2 we were in on-premises. And so you had to get an actual server.

Ivonne: So to be able to pivot from that, and be able to get teams to onboard actual business use cases that provided income for the company, that provided ease of use for our end users. Improve latency on some of our services as well. That really was what he was looking for.

Ivonne: And to your point, going back into the way-back machine. I think back then, I did not realize how big or what I was really achieving. I didn't realize how early on we were on that journey. And how, like you said, there's a lot of companies that haven't really started doing this, and they're just now asking that question, "Could this really give me something? Is there really a benefit here?"

Ivonne: And you're right. It's a little humbling, like, "Little old me." But it's also pretty cool, because I've tried so many different things, and I can tell you how it will or won't work and go from there.

Jeremy: I think that's interesting about, that your manager at that time was sort of like, "Do whatever you need to do to accomplish what needs to happen." Because there's so many engineering managers I think still now, who are like, "Oh no, this is what we do here. These are the platforms we build on. Here are the only allowed tools," and so forth.

Jeremy: So is that something you see? I mean, you've worked for a couple different companies now, and I'm curious with Bill.com actually, considering that you seem to be advocating for serverless there, which is awesome.

Jeremy: I mean, have you seen that generally, where you would have engineering managers that would kind of push you into this serverless, or at least let you experiment with it? Or has that been few and far between?

Ivonne: I think at the end of the day, companies need to allocate a set of resources, a set of engineers, to do this sort of tinkering. Because you're right, if a business manager has these metrics, these business goals that they have to meet, to reserve a month is probably painful, and frankly hard.

Ivonne: And so if companies can come to the table and say, "Okay, we're going to take these three engineers, and we are going to let them tinker for the rest of the company." And then let them define those patterns. So that the business managers that don't have the time to give, can then say, "Okay, here are all the patterns. Here are the quick how-tos. 1, 2, 3, 4, do this to be able to meet my business metrics," I think a lot of companies will have success in adopting some of these more modern architectures. And then at the end of the day help their end users, their customers.

Jeremy: Yeah. And I think you said earlier, that in terms of your role at Bill.com, that really what you're doing there is helping modernize what it is that they're doing. So I'm curious how much you can share in terms of, where are they now? Are they traditional EC2? Or traditional virtual machines or on-prem? I'm sure they're not on-prem. But I don't know, maybe they are.

Jeremy: But is that what the goal is? Is that part of you joining the team is really this effort to modernize what Bill.com is doing?

Ivonne: It is. That's pretty much my job description, right? Help us modernize our application. They are on-premises.

Jeremy: Wow. Okay.

Ivonne: They do have workloads on-premises that will probably have to stay there. But there is a desire to be able to build faster, to be able to grow faster.

Ivonne: We recently purchased two companies. We have Invoice2go and we have Divvy, that really expand our product offering for our end users. But that also means that our growth, our opportunity of growth, can increase five, 10, plus X. Whatever that amount is, our software developers need to be able to quickly build features that meet the needs of those end users.

Ivonne: And with that monolithic architecture that a lot of companies have these days, that gets very difficult. There's a lot of process there. You are limited to maybe monthly releases, weekly releases. It's not common that you can have a monolithic application that you can deploy three times a day, for example.

Ivonne: So what I'm really coming in to do is help them do that. Help them take the set of microservices that they have today and build on that. Make those have concrete patterns that they can replicate across microservices to decrease that time, that window out the door to production.

Ivonne: It's a lot of fun. I think there's a lot of opportunity there, and we definitely need the help. So if anybody is looking for work, Java developer, I would definitely enjoy working with you.

Rebecca: We'll put a little audio ding, hiring. Just a nice little overlay.

Jeremy: Well, first of all, I think it's amazing that companies are doing this and are modernizing. And there's so many opportunities for developers right now. So even if somebody's there working on designing T-shirts right now and you're thinking about this. Getting into tech, there's a lot of work in tech right now. And I think it's going to just keep getting bigger and bigger.

Jeremy: But just bringing it back to the Bill.com thing though. In terms of, I mean, you talked a lot about microservices and patterns and some of these things that you see. Going in and looking, and I can imagine the first... I know the first few days, or weeks, or sometimes months at a new company can be a little bit overwhelming trying to understand, "Why did you do that? Why did you make that choice?" Trying to figure out that architecture.

Jeremy: But I'm just curious, is that something where you've... You've had a little bit of time to breathe some of this in. Are you already seeing immediately places where you say, "Oh yeah, this pattern will apply to that, and this pattern will apply to that. And yeah, if we rip this out and replace it with SQS or EventBridge or whatever, it'll be so much better." I mean, are those ideas already in your head?

Ivonne: Oh yeah. I mean, I have this long mental list. I will neither confirm or deny that it's in a Google doc, and there are multiple pages. And really it's just bullet points, so you kind of get a picture of how much it really is.

Ivonne: But yeah, I mean, I think the more you work with these technologies, the more patterns you can quickly identify. I think for me personally, and maybe even a lot of architects out there, when you have that long list, you just want to attack all of it.

Ivonne: And I think what's really important, and it's actually what I'm talking about at re:Invent, is this whole concept of an MVP. Of starting small, of taking a little chunk, a little slice. It's the whole strangler fig pattern.

Ivonne: Just take a tiny little bit, move it, see what happens. Exercise that code and iterate on that. And then bring a little bit more. That whole concept of an MVP, I think, cannot be stressed any more of how critical and how important it is.

Ivonne: Like to your point, taking a monolithic application that is millions of lines of code. You can't really feasibly say, "Okay, well, in three months this is all going to be out of there. It's going to be serverless. It's going to be perfect." That doesn't always work out that way.

Ivonne: But I think realistically, and also cognitively, for engineers to be able to take these palatable steps to one by one, take a little feature, move that feature, move that here. So that's my challenge right now is trying to get that whole MVP feature phased approach. But there is a long list that I have.

Rebecca: So you do a really great job talking about these types of topics on your blog. And then I'm so glad that you're bringing this one specifically to re:Invent, to talk about building an MVP. But you also cover other essential topics. And I would say pervasive and persistent, and all the other words that start with P, of these questions that we constantly hear, right?

Rebecca: Like recently you about how to choose a database on AWS. And at the time of writing, you were like, "By the way, there are more than 15 options." And so we have been asking our guests lately, especially those who ascribe to the serverless is magic, because it can reduce your work, and it can reduce the over-complexification of all these different things. And there are so many things abstracted away.

Rebecca: But as we see capabilities for serverless, and different services come on to then help you achieve more with serverless, there's maybe a friction between simplicity or reduction, to this other movement of potential for over-complexification, if that's even a word I can say.

Rebecca: So I'm wondering if you would share your thoughts around the growing, not shrinking, capabilities being added to the serverless portfolio. And how you approach that idea of serverless is magic, and can offer reduction, but also there's all these... There's more than 15 ways to do everything with every service at AWS.

Ivonne: Yeah. I think, it's sometimes difficult, but what needs to happen is you kind of have to just try it. And sometimes you might start, to your point, start simple and see what works and what doesn't work.

Ivonne: And might realize that, for example, "Okay, well, I need more memory on this Lambda." And you keep upping it and upping it and upping it, and it's still not performing. Then you realize, "Okay, well actually I need more CPUs. So, let me look and see what is my next option." How do I go from having little responsibility, to kind of growing that responsibility to meet your business case?

Ivonne: And these new features, like serverless Fargate now. That whole concept of serverless container. And start growing out into these other services that do require maybe a little bit more heavy-lifting than you originally intended. I think it's important to start small, and then code in that flexibility to be able to grow and try other features.

Ivonne: And sometimes it actually goes the other way around. Like for example, having Apollo Server on a Lambda. Or realize, "Okay, now we have AppSync. How can we leverage that to outsource even more heavy-lifting?" It's like a constant moving dance. And to be able to have flexibility in your application to be able to make those moves, I think is really important.

Ivonne: But also to be judicious about it. Because I could say, "Well, let me move to AppSync because I just don't want to deal with this anymore." But you might actually look and realize, "Well, the amount of time I'm managing this Lambda is actually pretty low. There's not much effort that I'm pulling here. And okay, but I'm going to have to pay 50 cents more per request on AppSync," for example. And I'm kind of throwing numbers out there.

Ivonne: But basically you might realize that move might not be worth it at this time. Spending the engineering effort might be more costly. And it's really constantly evaluating, constantly reassessing your application. That observability is so key. To be able to say, "Okay, this service is working for me. Oh, this new service that just released might give me like 10X growth," or something like that.

Ivonne: Which I think is pretty awesome. But you have to stay almost on the pulse of news and information and education. Our field changes every day.

Jeremy: And I think that's kind of the point Rebecca was trying to make too, is that the complexity itself is... It's like the complexity of choice is one, or the cognitive load that's created by, whether it's "Do I run Apollo on Lambda or do I use AppSync?" There's obviously the choice there. But there's also this choice where... And like you said, keeping up with the education.

Jeremy: Because if you don't know that Lambda functions now do batch windows, or the different modes of SQS in terms of whether you're using FIFO or you're using regular SQS. And then what's the drawbacks versus using EventBridge? And then API destinations. I mean, we just add all these things, that I think most developers are probably used to saying, "Well, I have a execution environment somewhere and maybe I interact with a third-party service."

Jeremy: But even something like handling dead letter cues, or error handling, and some of these other things, that are now built in to the cloud, built into the connections between the code and the service. Or something like step functions, where you don't even have to write any code anymore. All of the stuff is sort of done and managed and transformed between these steps.

Jeremy: I mean, I think that's the thing that we hear a lot of our guests talking about, is just to say, "Yeah, I mean, you need to really keep up on all the new things." And especially as somebody new coming into serverless, there's just a wall of information that I can see really overwhelming people.

Ivonne: Yeah. For sure. I will neither confirm or deny that I do feel overwhelmed from one moment to the next. But it is a challenge. And then there's a lot of resources out there. Things that you and Rebecca are doing, I mean, I think is great. To get those bits in small, consumable forms is really awesome.

Rebecca: Well, thank you. We're blushing. For those listeners who can't see us, we are blushing. So two of the topics that you've discussed in the past have been microservices and... Ooh, we talked about this hexagonal. Hexagonal. Hexagonal [crosstalk 00:24:42]

Jeremy: I say hexagonal. Microservices and hexagonal architecture. My two favorite topics.

Rebecca: Yeah, they happen to be two of Jeremy's favorite topics. And so I'm going to toss this, I'm going to dev to ops it, toss it over the wall to him. But first, before I do that, if you could explain a little bit to our listeners who might be unfamiliar with the term, what is a hexagonal architecture? What are the main benefits of it? And then I'll let Jeremy take it from here.

Ivonne: Yeah. So you might notice I use magic a lot. I apologize. But the magic of hexagonal architecture, I really think is that whole loosely coupled components. It's a way of organizing your code where you can swap out different implementations, or you can test really small areas. There's unit testing, there's integration testing. And hexagonal architecture, I think, really makes integration testing much easier to do that.

Ivonne: I think one of the benefits, for example, I was talking about this at work recently. One of the benefits that I think a lot of times get overlooked is you have engineering teams that... Let's say you have five engineers plus working on one project and one microservice.

Ivonne: And you can imagine that having hexagonal architecture, having all these loosely coupled components, lets engineer focus on the database layer. Let engineer two focus on the use cases. Let's another engineer focus on, for example, the rest API layer.

Ivonne: And everybody's working without getting into git merge hell. Which I think is definitely, in and of itself, one of the amazing reasons to adopt that. But I would say, that one-liner is, this loosely coupled organization of your code that makes life easier.

Jeremy: Yeah. And I like how you use loosely coupled, which is a term that comes from microservices, or is a term used in microservices. But I think that's an interesting... And that's one of the things that I love about hexagonal architecture, is that you do have that ability to create those interfaces between ports and adapters, as another way to sort of look at it.

Jeremy: You do have the way to create those interfaces between two different things. Which also helps with things like dependency injections. So you can say, "I'm not calling my real database. I'm just calling this mock of my database, but I have a standard interface to it." And then other people can use those standard interfaces.

Jeremy: And I've always found too, that starting with hexagonal architecture or starting with ports and adapters, is a really great way to then think about planning your application and start understanding it. So you can kind of move into that microservice space where you actually say, Okay, this user adapter that I have, that does lookup of users. It adds new users. It removes them. Maybe it does some flagging of them or whatever. But maybe this does need to be moved into its own separate service, and do all of the information hiding and scale independently, and deploy independently and so forth.

Jeremy: But I'm curious what your thoughts are on microservices, especially for companies that are just getting started. Because I tend to see a lot of companies who are like, "All right, we're going to build our first version of our app, and we're going to build 15 microservices to support it." I think this probably ties back into your re:Invent talk about MVPs, and maybe where some of these companies should be starting.

Ivonne: That's interesting. A lot of times, I think, even as an architect myself, when I look at a business use case, I already start grouping things automatically. I'm like, "Okay, well this goes there. This goes there. This is that." And that knee-jerk reaction is saying, to your point, that's 15 microservices to support this one use case.

Ivonne: I think sometimes that's not actually beneficial. And there's a lot more maintenance, there's all these different pipelines, and coordinating deployments, and making sure backwards compatibility, and all that. That a lot of times I think it's perfectly okay to say, "I'm going to start with, let's say for example, a Lambda lift, that supports these 20 use cases."

Ivonne: And then in code have different bounded contexts that would have its own little hexagonal architectures, all cute and organized in code. Then, as you see, to your point, as you see one of them growing obscenely, you say, "You know what? In retrospect, that should have been its own microservice." But because I have it organized in hexagonal architecture, it's all these loosely coupled components in this application, ripping that out after the fact is a lot easier to do.

Ivonne: And I will neither confirm or deny that I have actually done all of these things. Both the doing too many microservices, and then realizing that this tiny little microservice that only had 100 lines really should have never lived by itself. As well as basically making little Lambda lifts that were not little at all.

Jeremy: Well, I will confirm that I have done all of these things. I had started a new project. Now this was a second... What do they call it? Second version syndrome or whatever it is, where we were rebuilding something that already existed.

Jeremy: And I immediately jumped down... I already know the bounded context. I already know the services that need to be created, and I went right down that path of creating all microservices. And it was just me. So I was like, "Why am I building separate deployable services just for me?" And then I quickly realized... When I say quickly, about a month and a half in, I was like, "Why did I do it this way? This was the worst idea."

Jeremy: Now I have built plenty of other microservices that have worked perfectly because they were on larger teams and so forth. But yeah, I think that's good advice. I think you think about it... And this is why thinking in hexagonal architecture or using that pattern is so important, especially when it comes to growth. Because then it is so much easier to just say, "Oh, well now my port that connects to this user adapter, now it just connects to this user service."

Jeremy: Now again, there's all kinds of issues and complexity with separating things out into separate services. But I think it gets you a lot closer, and it's not like you have to refactor the entire application to make it work.

Ivonne: Yeah, for sure. I mean, it really does simplify that process. And as architects and designing software, that is probably one of my top design patterns that I think everybody should do. Which probably might make me a little annoying to some of my coworkers, and I apologize if you're listening to this. I am sorry. But to have that organization, it really gets me excited.

Rebecca: So I think, I mean, whether or not you have or have not done all of these things. And you have or have not taken lessons from them, which I think we know that you've likely done and then learned a lot from them. You actively share all this education around these things that you have or have not done, or have done. You do that through your blog, YouTube.

Rebecca: And I'm wondering, as you see your audience coming back to keep learning from you, do you see a pattern of questions emerging from them? What are these things that they are keeping like, "Ivonne, please, will you cover this?" What do you see in terms of people trying to build, and they keep getting stuck.

Rebecca: If there are certain emerging questions that you're like, "Okay, this is what we constantly hear. There probably needs to be more education around this." More people screaming from the rooftops in terms of trying to help answer some of these pressing, burning questions.

Ivonne: I think the biggest question I get is really around observability. And honestly, it's between software developers who've been doing this for years, and they're used to that traditional three-tier web application, for example. And then folks that are doing this brand new. They've never done serverless before.

Ivonne: It's just understanding what my application is doing, how it's doing, what it's doing. And if something goes wrong and things hit the fan, how to figure out how to solve that, and figure out what's going on.

Ivonne: I think observability is hard. And I think that the better that we get as content creators to be able to simplify, giving clear lists, clear set of patterns, I think that'd be better for people from different experiences.

Ivonne: I think that's what surprised me the most. I guess I would've thought observability might've been difficult for someone coming from three-tier web application, because it was hard for me. And so that's kind of one of the surprising things. It's like beginners alike. It's a hard concept to understand, especially with Lambda and the way it's deploys, and what you can or can't get out of that running instance, has been really interesting for me.

Jeremy: Yeah. I think observability is definitely... I mean, I think just serverless architecture, thinking about it differently, event-driven, that's... People are so used to request-response. I tell the server to do something, it responds back to me. So this idea of asynchronous patterns and all those other things get kind of complex.

Jeremy: But speaking, again, more about the education stuff that you are doing out there. I'm a content creator. We've had a lot of content creators on the show. And I know for me, one of the most rewarding things is when you get confirmation that you helped somebody, right? Somebody's like, "I read this. I watched that. It helped me. It got me to do X, Y, Z."

Jeremy: I'm just curious, have you had those experiences? Or what else has been the most rewarding things that you've gotten out of producing this content?

Ivonne: I think it's that. It's the, "I am a developer. I'm trying to build this use case. I don't have time. There's a crunch. I'm going to use my amazing Google skills, and stack overflow skills, and get an answer yesterday." And time and time again having folks say, "You know what? I found your blog post. It clearly gave me the steps that I needed to take. I spent two days struggling with this, and then I solved it in five minutes after reading your post."

Ivonne: And I find that so rewarding. Because I feel like a lot of times I went through those same pains. And to, Rebecca, your question before. Going in my way-back machine of when serverless started. I mean, everything that I struggled with, there was not much out there, because it was new, it was shiny. And not a lot of people were doing it then.

Ivonne: So to be able to like speak to my five-year, six-year-ago self, and then create content for people who are starting now, I think it's pretty cool. To be able to say, "I saved that person a week of work. And I know I saved them a week of work, because it took me a week to solve this problem." I think that's-

Rebecca: And it might not even be time at point. You're probably saving some people from tears, because you get so frustrated if you can't find... It's more than time. You're saving sanity.

Ivonne: Oh, that I'll admit. I've definitely shed tears. "Why doesn't it work? This looks like it should work. Everything is in line and pretty and perfect." Oh, by the way, you have to add this to cloud formation and then suddenly it works.

Jeremy: Well the other day, this is a front end use case, but I was doing something with Axios. I switched from a post to a get, and I forgot to put the data in as the second object, and instead was passing my headers in the second object. And I was literally banging my head on the desk trying to figure out what it was that I did wrong.

Jeremy: But the other thing, so you also mentioned, again, you're able to find a piece of content, it helps you out. And I think that lots of people can produce content. There's not a ton of people that can produce content well, and can really get to where it needs to be.

Jeremy: And the videos on your site, they look great. They're all well produced, which is great. The other thing that I tend to find frustrating when I go and I'm trying to search for an answer for something is, I'll click through to the first link. It'll be like a 700,000 word blog post that goes into the history of Unix or something like that before it gets to the simple answer that I need. And those kind of things are frustrating.

Jeremy: Now I think some of those long-form posts work great. But also just being able to present clear answers, get people to where they need to be. I think you do a great job of that. And again, your content is really, really well produced.

Jeremy: I'm just curious. For you, I think that skill probably helps you out. But, I mean, in terms of you being able to do that sort of stuff, have you found that that actually helps your career too? I mean, Bill.com. Is Bill.com a result of all of this effort you've put into creating content as well as obviously your experience?

Ivonne: It definitely has. I think that's a skill that, to your point, not a lot of folks have. To be concise, to use simple words. When I started out in my career, I moved to Silicon Valley. I was like, "I'm going to get that Silicon Valley job. I have this degree. I am like amazing. Everybody needs to hire me."

Ivonne: I remember one of the interviews, I came out of it and they gave me feedback. And she was like, "Oh, she doesn't use enough technical terms." I remember thinking like, "Oh, that's a shame. I must not know something [crosstalk 00:38:19]"

Jeremy: Did you just say hexagonal. Hexagonal architecture. Is that enough for you?

Ivonne: Hire me now. I know it. [crosstalk 00:38:26]

Rebecca: You're like [crosstalk 00:38:28] octagonal, you got them all

Ivonne: Exactly. And so I remember being so crushed. Like, "I'm not going to cut it out." I'm like, "Silicon Valley, they're just going to eat me alive and spit me out," and so on and so forth.

Ivonne: But as I grew and mature, I've realized that we're not meant to know everything, one. Which is, I have to keep repeating that to myself all the time. But most importantly, being able to speak in plain English, speaks to someone. And not everybody is at that academic level.

Ivonne: I will admit that still to this day, I have a difficult time transitioning from the plain English to the academic level. I think I still struggle there. Maybe it's preconceived notions, I don't know. But I mean, I think that's important. To be able to speak concisely, to be able to be simple about it, and not make it seem something more than it really is.

Ivonne: I will also say that this skill not only helped me get the job that I have today, but it's also helped me in my marriage. Because my husband says I am very verbose. And if I want to say something, I say... I mean, well, we've been talking for some 45 minutes. I say a lot. And he always has to remind me. He's like, "Okay, wait a minute, take a deep breath. Just tell me what the problem is. And then give me your opinion."

Rebecca: Well, you-

Ivonne: And that has... Go ahead.

Rebecca: You go, you go.

Ivonne: No, that has helped me in my marriage, because there's probably a lot of times where I'm saying why I feel the way I feel, but I haven't even said what the problem was. And he's like, "I can't help you."

Rebecca: You are on the right podcast. Because Jeremy and I, neither of us are known for being non-verbose. Our questions will be like, "Hey, we have two paragraphs, and now here's the final question." And people are like, "How did we get here?"

Jeremy: Right. And we're like, "Oh, and we're out of time. Sorry. I took too much time with my question."

Ivonne: There you go. But talking is good. It's fun.

Rebecca: I do think too, especially if you're trying to build any business that has an infinite time horizon, air quotes around infinite. But an infinite time horizon, is that to start with plain language is the best way to include or invite newcomers in.

Rebecca: It's as though you're saying to a newcomer... If you only want to have rigorous expert academics using whatever your product is, then sure. Use this really highfalutin language. But if you're going to get new people in, and they try to get in and they're like, "I don't know how to speak this. I can't understand what you're saying." You're just going to lose a lot of potential customers or users, or even just fans or advocates. Because they're like, "Nevermind, this is not for me."

Rebecca: Anyway, I would imagine that starting from the plain language, almost the first principle of the thing. And then moving onward or upward or forward, or however you might want to call that, would likely be the best place to start. And I'm now getting to my question, as we know for verbosity. Do you think there's value in developers learning these types of skills to create content?

Rebecca: There's certainly the production side, but I think there's also a really huge skill involved in being able to quote/unquote "reduce things to plain language." So I'm wondering if you see certain skill sets that you think are valuable for developers to have, or that you think they perhaps should be nurturing in themselves in terms of content creation and bringing more people into the fold?

Ivonne: I think so. A couple of reasons. To your point is, them bringing more people into the fold. The likelihood of them speaking the way they speak, that somebody else would speak that way too, and speak that same language, and that same thought process, I mean is exponential, right?

Ivonne: I think I still could not really talk like a beginner anymore. I've been corrupted with hexagonal architecture, and now I use that word all the time. And I think it's important for developers to be able to do that. Not that it's important to be able to do that, but they realize the value and the importance of doing that.

Ivonne: The other thing I think in general as developers I think that we really should hone in on, is being able to communicate period. Whether it's creating content to get other people in the fold or teach other people, that's one thing. But to be able to communicate to your manager, or to your peers, and say, "This is the idea I have. This is why I think it would work. These are the metrics I think we can meet," and so on and so forth, I think is really important.

Ivonne: In my degrees, and all the education I've had, there was no class that said, "How do I market myself? And how do I market my ideas?" And I think that's really important, even just for your own career. Forget content creation for a minute. To be able to communicate is, I think, key. To be able to write well, and to write plain sentences. And to be able to get that thought across in a concise way. I really think all engineers should learn that.

Ivonne: I know that's general education classes in school, and usually we avoid that or we pad our semesters so that we have not stressful things. But we should really value those classes. I think those soft skills are really key to engineers and their success.

Jeremy: Yeah. And I'm blanking on who it is that the quote's from, but it was, "If I had more time, I would've written you a shorter letter." [crosstalk 00:44:13]

Rebecca: I think it's either Abraham Lincoln or Ernest Hemingway. Or Mark Twain.

Jeremy: I don't know. We just start naming people. It could be anyone.

Rebecca: I'm pretty sure it's one of those three.

Jeremy: Yeah, right. But I think that you're right, that the... Like for me, if you say, "Hey, can you come give an hour-long talk?" No problem. "Can you give a five minute talk?" Probably not. I'll spend the first five minutes and never... If you time box me like that, it's so hard. When I do write, I usually can go back and try to slim some things down. But I always feel like, "No, there needs to be more words here. There just needs to be more words."

Jeremy: But you're right. That ability to really shrink down what it is you're trying to say, make it concise, cut out all those filler words. And then... Dumb it down's not the right word. You can still not, I guess, patronize someone with small words or with non acronyms. Acronyms drive me nuts when people load up with acronyms. I'm like, "Oh, what does that mean?" And then you search it on Google and you get 50 things that come back for that acronym.

Jeremy: But yeah, I think that's a... I don't know. I'm rambling now, too. So as you can see, I wish I was more prepared. Anyways, well, so moving on from this topic, you have a re:Invent talk. You mentioned about MVPs. This should be airing, I'm assuming, on the Monday of re:Invent, which means that your talk is actually tonight, if you are listening to this on Monday, what is what the 29th? 30th? 31st? I don't even know... There's not 31 days in November.

Rebecca: I don't know. It's the 35th.

Jeremy: It's the 35th? On the 35th of November. Anyways, you are giving a re:Invent talk, which is awesome. Can you just give us a quick preview of what we're going to see there?

Ivonne: Yeah. So my talk is about productizing MVPs. And giving folks a series of steps that they could follow that can help that growth from that small little one feature with a bunch of missing things in it, into that finalized application that's robust, it's scalable.

Ivonne: It meets all your end user's needs, and get out the door yesterday. I kind of glazing over all the nuances, but we are going to talk about hexagonal architecture.

Jeremy: Perfect.

Ivonne: That's definitely there.

Rebecca: Spoiler alert.

Ivonne: There you go.

Jeremy: TLDR.

Ivonne: Exactly. And talk about testing, and CICD to be able to automate a lot of these hard things. And using frameworks, and using tools that will make observability easier. That will make all these different things easier as you do this really hard thing, which is releasing this productized fully end-to-end application.

Ivonne: And I'll talk a little bit about my experience, about things that I will neither confirm or deny, as well as some of the wins. Some of the great things of... Taking a project I worked on, I'll talk about credential microservice that I had to do.

Ivonne: It had so many features. Credentialing sounds so easy, right? Username, password, login, you're done. But it's so much more than that, and there's so many nuances that if I sat down and started developing that fully-featured application, I would be here for six months, a year, plus. I don't know.

Ivonne: Then I would get nothing in front of an end user for a whole year. So people will have to deal with really crappy logins for a year, until I finish my product. And that doesn't work.

Ivonne: So I'll talk a little bit of how I broke that apart, and made these pattern decisions to be able to easily plug in all these missing features. And at the end of the day, make end users happy, make business teams happy, and meeting goals and metrics. [crosstalk 00:48:15]

Rebecca: Oh my gosh, I love... So excited. I love a good concrete, real-life example, and then breaking that down into pieces. Because they do feel so applicable. Especially something like credentialing, because you're like, that is something we all deal with. And every end user deals with. So that is really cool.

Rebecca: Officially that talk is on Monday the 29th, not the 35th, like I claimed. And super excited. So if you're listening to this today on Monday, go check it out this evening at re:Invent.

Rebecca: And for us today, you have ran us out of our very long-winded questions, Ivonne. But our last questions are, if people want to learn more about you, where should they find you? Twitter, your website and personal blog, your YouTube channel. And then we will put all of these details in the show notes as well.

Ivonne: Yeah. So I think that the first place definitely is following me on Twitter.

Rebecca: Do it.

Ivonne: I try to post frequently or share things that I see. That's I-V-L-O-1-1 on Twitter. Which one day I probably need to do a talk just on why I have such a weird username. But we ran out of time and it would take me a long time to explain that. Anyways, I-

Rebecca: It's a mystery.

Ivonne: Hey, there you go. I-V-L-O-1-1 is my handle on Twitter. I also have a YouTube channel, Serverless DevWidgets. DevWidgets, one word. I'm probably dating myself using the word widgets. I don't know, I'm sticking to it. And then also I have a website, ivonneroberts.com, which I try to be a little more diligent on. I'm not very good at it, but I'm getting better. And that's what matters.

Rebecca: I think you're being harsh on yourself. I really enjoyed the website. So thank you. It was great.

Ivonne: [crosstalk 00:50:12] Thank you.

Jeremy: Awesome. Well, thanks again, Ivonne, and looking forward to your re:Invent talk.

Rebecca: So excited.

Ivonne: Thank you. Thank you so much for inviting me. Oh, I do have one more request.

Jeremy: Oh, absolutely.

Ivonne: So the next time you do a song like you did last year with the Lambda and my shots and all that stuff, I want in.

Jeremy: Really?

Ivonne: I can sing.

Jeremy: You sing? Oh.

Ivonne: I can kind of sing. I can do this. I want in.

Rebecca: Oh, wow.

Jeremy: Okay, so right here on the podcast. We're going to talk about this right now. So the song, I have most of the lyrics written to the song that Angelica sings there, the wedding song. I don't know why it's escaping my mind right now.

Jeremy: But if you can sing that song, I am in. Because I was thinking to myself, I have nobody that can sing this. So if you have Angelica-like pipes, then let's go for it.

Ivonne: I won't go with that far, but I can defend myself. I think.

Jeremy: Well, I have software that I can adjust the pitch and so forth. So we can try to work it out. But that would be great. Because I've been wanting to do that for a long time, and I'm just like, "Ah, I'm never going to get to it."

Ivonne: There you go. I like it. Let's do it.

Jeremy: Awesome.

Rebecca: This is the beginning of a beautiful collaboration.

Jeremy: This could be amazing. [crosstalk 00:51:26] This could be amazing. All right. Awesome. Well, thanks again, Ivonne. Appreciate it.

Ivonne: All right. Thank you, Jeremy and Rebecca, this has been great.

Rebecca: It was so fun.