Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Luciano: Hello folks, I'm just back from re:Invent, the biggest AWS conference of the year and probably the biggest conference where I've been so far. re:Invent is hosted in Las Vegas and it was on last week, so I just came back. I'm still a bit jet-lagged, but I'm super excited because I had the pleasure to meet many experts and thought leaders in the cloud and AWS space and they decided to share some of their bold opinions with us.
So today we are going to get expert opinions about topics such as how to get started with the cloud effectively, favorite AWS announcements, bold predictions for the future of serverless, should you go multi-cloud or not, and of course there is going to be a little bit of Gen AI because you cannot escape that these days. My name is Luciano and thanks for joining me for another episode of AWS Bites podcast. AWS Bites is brought to you by fourTheorem, the ultimate AWS partner for modern applications on AWS. We can help you to be successful with AWS, so check us out at fourTheorem.com. So let's start with favorite AWS announcements. The first opinion we have for you is from our friend Alex Kearns, Principal Solution Architect at Ubertas Consulting, who has an astonishing collection of AWS certifications, which is 8 different certifications. So we ask Alex, what's your favorite AWS announcement so far?
Alex: We're only on Monday, but my favorite announcement from reInvent so far is the ability, or to at least in preview, the ability to take applications that you've built in the console and convert them to infrastructure as code. So I believe this is only in one region at the moment, in very, very limited public preview, but super excited to see exactly how this works in practice. Things really important to encourage infrastructure as code and anything AWS can do to make it even easier to get there is a massive bonus in my eyes.
Luciano: The next question we asked is if you could give one piece of advice to someone starting their cloud journey today, what would that be? I think this is a great question that can help all of you who are just getting started with the cloud and AWS, but it can also help people that are involved in training or that are supporting you and your colleagues. So we had 3 awesome folks giving us an answer to this particular question. And the first one is Emily Shea, Head of Application Integrations, Go-to-Market at AWS.
Emily: So this is one of my favorite questions, particularly because I have my own personal experience with it. So when I started at AWS, I didn't have a tech background at all. And so I really kind of built that up as I went with some of the certifications, but then also building hands on myself because I thought it'd be so much more fun if I built an actual kind of use case that I wanted for myself. So I'm actually giving a session tomorrow that's all about that journey of getting started from a very simple use case to solve a problem that I had.
Mine was around wanting to get daily reminders to study Chinese language and then building up an increasingly complex application with serverless around that. My recommendation to folks is definitely start really simple with maybe just like one or two services. I think it's nice to build something around an event coming in. So for mine, I built a daily schedule event with EventBridge that would trigger a Lambda function, pull a word from S3 and then send that out with SNS as a text message.
So it's a super basic use case. And then I took that and added more complexity and more features over time. I think getting hands on and starting simple, maybe with just an event trigger and building on top of that is a really nice way to get started. I also think that there's some really cool stuff that's come out recently around visual designers. So maybe if you want to start messing around with Application Composer to build a serverless application, or also the Workflow Studio for step functions that allows you to pull in different services and figure out the workflow that you want those services to step through. Those are really cool, nice visual tools to get really get a feel for how the services come together and then be able to export template to go and deploy that application.
Luciano: So that's really a great answer. Thank you, Emily. You should actually watch Emily's session. The link is in the show notes. Next up is Ran Isenberg, Principal Software Architect at CyberArk and a fellow AWS Server Hero. So let's hear from Ran what people should be doing when they get started with the cloud.
Ran: My advice to you is basically don't focus on certifications too much. I think it's great to know it. I mean, it's great to have knowledge. It's a great in theory. But in order to get a job, you need to have practical knowledge. You need to know how to solve a problem. And you gain that only from actually working with the tools, right? It's not with theory. So my advice to you is basically try to build something, maybe solve a problem.
Try to build the REST API in serverless, maybe use CDK, Terraform, whatever you want to learn. Just try that. See how it works for you. When you really start to do something, you really understand the corners, the edge cases, and you know how to test, you can learn how to test it, how to build it. And that's usually what I do. I try to do some PoC. I read the documentation and just try to build it.
And that's usually how I gain the most insights. Then I can write a blog post about it or recommend it to my work for a design or something like that. So another option that you can do when you have more confidence and you have some knowledge is also to go to the road of code contributions. So usually I look for an open source that I really care about. I look at the issue segments, I look for maybe a label for good for first contribution, and I look for it and try to solve it. So you can talk with the team, write in the issue there. Hey, I can help. Maybe I have an idea. Maybe I can help. I can do it. Just try to solve it. Again, you're going to learn so much from just trying to solve a very specific problem in one of your favorites open sources. So that's my advice.
Luciano: Ran mentioned writing blog posts. He's actually a very prolific writer. So if you want to find out lots of interesting serverless material, make sure to check out his blog, RanTheBuilder.cloud The link is also in the show notes. Now we have Maxime David, software engineer at Datadog and AWS community builder.
Maxime: So maybe try not to reinvent the wheel. AWS has a lot of different services, so maybe there's already something for you there. I would highly suggest you to reach to community builders, read blogs. And as soon as you learn something new, maybe you should write a quick blog post about that. First to get feedback on it and just to make sure that you understand it well, you're using it well. So yeah, that would be my advice. Start to learn as quickly as possible and then try to share and receive feedback from that.
Luciano: Build, share and get feedback. This is probably a good summary for all these awesome opinions. So let's now move on into another topic, favorite and least favorite AWS services. We have Danielle Heberling, senior software engineer on an healthcare company called Ensomata. So Danielle is also an AWS Serveless Hero and a community builder. So let's talk about Danielle's favorite AWS server services and of course the least favorite ones as well.
Danielle: Favorite thing about AWS by far is definitely the community. I do know that one of AWS's principles is customer obsession and I think they do a really great job with the community in terms of more active community members getting recognition, getting opportunities to talk to the service teams. Mostly speaking about the community builders program and the heroes program. So that's definitely my favorite. My least favorite part about AWS is there's a lot of services and there's some services that do the same thing yet slightly different. Thinking mostly in terms of all the different types of databases, all the different ways you can run a container. It can be kind of challenging and daunting especially if you're just getting started with the AWS ecosystem to know which solution to go with because it's confusing.
Luciano: Indeed the AWS community is awesome. I can certainly say that after my experience at re:Invent. But it's also true that there are so many AWS services and they can overlap quite a lot. I find particularly funny thinking about all the messaging and data streaming services such as EventBridge, SNS, SQS, Kinesis, Kafka, Amazon MQ, etc. It can be really daunting to figure out which one of those offers the best trade-offs for the specific problem you are dealing with.
I suppose there is also a good thing in having variety because you will probably be able to find the perfect set of trade-offs if you really put your effort into it. So that's kind of pros and cons of AWS and you might like it or dislike it. But I suppose with experience things get a little bit better and more accessible. At this point I want to talk about bold predictions for the future of serverless. And because you know I love serverless and I had to ask this kind of question, especially having these amazing thought leaders in the room. So I actually had a few people volunteering to answer this question and the first one we have is Jones who is a fellow AWS serverless hero and a senior developer advocate at Freshworks.
Jones: To talk about the future of serverless, well it's scary and it is exciting for me because it's scary first because we are losing the meaning of serverless as we go about with a lot of things coming out. The true meaning of serverless is being lost and that scares me. At the same time the exciting things that happen and the future of serverless could be more distributed, more granular in nature where if you would want to have a scheduler and monitor it maybe it's going to be much more simpler and much more easier to do it. You don't have to go through EventBridge, right, write the cron job, stuff like that. It's going to be much simpler. That's just a simpler thing for instance, right. But a lot of things is going to change. A lot of things is going to happen. So I'm excited for that future but also scared about it.
Luciano: Now let's compare this opinion with Sam Williams, founder of Complete Coding, a company that provides training and content for serverless and AWS. So let's hear from Sam what the future of serverless is going to look like.
Sam: In my opinion there's kind of two big things that are going to change going forward. The first is that we may see an evolution kind of on top of infrastructure as code. So at the moment you always define a very physical infrastructure and that is what you then run your applications on. And I think we're going to find that there's going to be an evolution over the next couple of months or even years where it's more based on the functional requirements that the business has or the company or the client has.
And we define our requirements and there is kind of an interpolation layer from our requirements to our architecture. And the second is that with all of the AI stuff that's going on with all the LLMs, there's going to be some really cool functionality built into our serverless pipelines and our serverless development process, whether that's like with those requirements, running that through a large language model and that is going to generate our architecture for us. And then we can tweak it or being able to have tools that can kind of critique our designs, critique our implementations. A bit like what we've got at the moment with CodeWhisperer and GitHub Copilot. But for more of the architecture side of things. So yeah, I'm really excited to see what happens and the new tools and new software and how much quicker and how much better we can make our applications using serverless with these new tools that come out in the next couple of years.
Luciano: Yeah, I'm also really excited to see what kind of innovation AI is going to bring to the table for serverless developers. But we also have AJ Stuyvenberg, staff engineer at Datadog and AWS Serverless Hero as well.
AJ: My bold prediction for the future of serverless is that one day we're going to solve some of the outstanding problems like serverless search in a true scale to zero, pay for what you use, scale to infinity kind of fashion. That is what I'm looking for when I use any managed service. I want to be able to deploy anything and not pay for the number of deployments I use and only pay for the actual compute that I use or storage that I use when I use it. That's what I'm hoping to get out of every single launch here at re:Invent and I'm excited to see what they launch.
Luciano: I totally agree with this one and I hope AJ wasn't too disappointed about the new serverless ElastiCache, but that's probably a topic for another time. Now I think it's time to discuss multi-cloud: yes or no. And this is something that we actually have talked about before, so I'm really curious to hear other expert opinions. And to answer this question, should you go multi-cloud yes, no and why, we have Faizal Khan, who is the founder and CEO at Ecomm and Xite Logic and he is also an AWS Community Hero.
Faizal: To answer the question about whether multi-cloud or not, like all great answers, it really depends on your particular use case. There are certain advantages that you get in terms of redundancy if you need it or maybe even compliance where you need to ensure that you're using two completely different networks or two completely different providers, you can have that. But it is not always a necessary thing.
It's kind of like the question of whether you need to go completely serverless with your application or still run on servers. It really depends on your use case. It's not always a necessity because there's a lot of things that you have to do in terms of retaining your workforce, ensuring that you have adequate redundancy set up and all of that. So there's a lot of additional work, expense, time that's going to go into that. So if it is like a real requirement, then I would say yes, but otherwise just stick to a single cloud provider because it provides you almost everything that you need. So you can actually in fact set up redundancy within the same providers as well if you need to.
Luciano: I totally agree with Faizal and if you want to find out more about this topic, you can check out our previous episode on this and we have the link in the show notes. But this year was the year of Gen AI. We all know that. And of course, I wanted some opinions about Gen AI and especially how Gen AI is going to change life in a way or another for software developers and cloud developers. Let's start with Heitor Lessa, chief architect at AWS and also the mastermind behind Lambda PowerTools. So let's hear it from Heitor.
Heitor: If you know me working on open source, one of the features that amazes me in Gen AI is that you can create documentation for people who are terrible at writing documentation for developers, for data engineers and so forth. One of the pieces that I noticed just now is that while it creates an amazing structure, it's not very well aware of the way people think and learn and the different personalities and personas when reading the documentation.
So one of the ways that we use right now at PowerTools is we generate the structure of the text, but then we have to have the human element to think all the diversity and the plurality of customers using the product and how would they perceive? How do we take someone who knows zero about AWS or barely anything about serverless or Lambda specifically for the matter? So we take this text and we start optimizing it, reviewing it and doing multiple editings. So I would say roughly about 30 to 50 hours just goes into editing of that text. Even though the Gen AI gets you there very quickly, should remove that block of your content creativity. The reviewing of those and trying to match to people's reality and people's limitations and their also plurality on how they think, which makes all of us special, it still requires human. I still cannot see a place where Gen AI will replace that. That human element is so special to us and what bonds us together.
Luciano: Yes, documentation is definitely one of those things where Gen AI can be a fantastic assistant, but where I definitely agree that we still need the human element if we want to provide a great experience to our users. So let's talk a little bit more about this and this time we have Chris Williams who is a developer relationship manager at Hashicorp, also a Cloud Therapist. By the way, I love that job title, probably my new favorite job title so far and he's also an AWS Community Hero. So let's see with Chris what he has to say about Gen AI.
Chris: So how do I think Gen AI is going to affect me and is it going to help me as a developer? I think it is going to, that's a very nuanced question and I think that it is going to help folks that have a little bit of experience to accelerate their development cycle, create tests more efficiently, create documentation more efficiently, create Git comments more efficiently. I do think that there is a danger in making it an easy button for folks that might not have as much experience and that they will fall victim to not understanding the fundamentals before stepping into something and potentially making big problems. So I think it's going to help. I am very excited to use it. It is helping me a lot on my day to day and I do use it daily. But I think that we need to make sure that we have a good set of guard rails around leveraging it and using it expeditiously.
Luciano: That's really a fantastic opinion. So let's move on to the last expert opinion for this episode. We have Praneeta Prakash who is a senior product manager at AWS. Praneeta works on building tools to improve developer productivity, which is the best kind of tools if you ask me as a developer. So let's see what Praneeta has to say about AI.
Praneeta: Honestly, we've been thinking a lot about this on our side. At AWS, we have this thing we call two-way door and one-way door decisions. For us, a two-way door decision is reversible and a one-way door decision is when you need to make a change that cannot be easily reversed. For me, AI comes into play where it can help you with those two-way door decisions. But every time there is a decision that needs to be made that's a one-way door decision or it needs a human in the loop to approve it. And so how I'm thinking about AI is how can it help that human in the loop make better decisions as part of their development journey.
Luciano: I actually didn't know about this concept of two-way door and one-way door decisions. And I think this is actually a pretty cool idea and it's probably something that we'll have to think a little bit more and maybe use it in the future because it seems like a very good framework to think about architectural decisions or decisions that might have an impact on the business in a way or another. But I think this brings us to the closing of this episode.
I hope you found all these answers insightful and inspiring as much as I did. And I've added all the links so that you can connect with all our guests on LinkedIn in case that you want to reach out to them and maybe ask additional questions, clarify their opinions or maybe just engage with them and build new meaningful connections. But how would you have answered all these questions? Maybe you have a dramatically different view on some of these questions. I really love to know. So in that case, don't hesitate to reach out or drop a comment on YouTube. And as always, if you found value in this episode, make sure to like and subscribe and share this podcast with your friends and colleagues. Thank you very much and we'll see you in the next one. Bye.