AWS Expert Ruben J Garcia: Streamlining Infrastructure as Code for Startups and Enterprises

Hello everyone, welcome back to Mastering Tech Grow. Today we have a special guest for you. We have Ruben Garcia, who's a maestro with AWS. So we'll cover the essentials today, so strap on. We're talking about cloud infrastructure on AWS. Welcome, Ruben.

Hello, thanks for having me here.

Of course, thanks for joining and thanks for doing this. So let us know who Ruben is, how you ended up in tech, and what you're currently doing.

Well, um, I've been working in tech for the last maybe 16 or 17 years, so I've been doing a lot of things. I started as a programmer using Java and doing some consultancy work in different consultancy companies, from small companies to big companies, working for other companies like insurance company, big insurance company here in Spain, or companies, telco companies in here. So basically my first 15 years is been in consultancy. So I've been a consultant in, in these companies, and then I moved to the product because I have enough consultancy for, for my time, and I prefer to focus in creating some products and something that is developing in my own experience and where I can have more, um, more focus in delivering the things that I want to deliver. Because you, your, with a consultancy, is the client the one that drives everything. And I prefer to be myself, that the one that leads the, the way of the product and everything. So I did the change a few years ago, and I'm very happy because right now I can do things, um, my own way.

Okay. So that was actually interesting, Ruben. So you did so many years, pretty much the whole career or majority of your career being a consultant. And now you went on doing your own things because you just wanted to, as you rightly put, have things in your hands. So can you give us a flavor of how actually consulting job looks like for you? Like, you know, it's like Yeah, just like, how do you get requirements? How did you know? How do you get projects? How you move through this? Because I'm quite intrigued to understand the difference between actually, you know, doing your things as you want, or, you know, versus being a consultant.

Yeah, well, at the end, the consultant is the— you are the one that creates the things for the client, but in the client terms. So It's sometimes difficult to change, for example, the culture of a company. If you get there and they are using some kind of technologies, it's very difficult because they already have an IT team that works this way. You can't change anything. Or we are using this framework, or we are using— so it's more complicated unless you are starting a whole project from scratch and you have the freedom to do things in your own way. But this is more difficult in big companies. For example, if you are working for a big company, very big company, you are not going to be able to, to do your own things. Or maybe you, you can use your own cloud, or if you prefer to use AWS and they are using Azure, you know, you are going to have to use Azure because everyone is using that. Meanwhile, if you are in a product company, you can use whatever you want, whatever meets your, your requirements in a more efficient way without having to, to consult or to ask for permission for, for other teams or whatever. Because at the end, right now I'm the CTO, so I'm the, the person that says, okay, we're going to use that and this is how it's going to work because it's better for us, or because it's cheaper, or because we don't need to stick to some technology. We can create, or we can do new things or try new technology. So that's why I wanted to join a product company and try not to be tied to another company. So because at the end you have two visions and it's sometimes it's very difficult to, to have those visions in the same way.

Okay, I get it. It's more creativity and more freedom to effectively experience with different things, isn't it?

Okay.

Yeah, I fully get it. So you basically went like, you know what, I'm done with consultancy, I want to be in this picture now. So you went and created your own picture, which is great. How did you end up becoming an expert with AWS? Because, you know, I've seen you have the certificates and, you know, you have such a depth with AWS. Was that by choice? Because, you, you know, you looked at AWS, you were like, you know what, I know they're gonna own the whole market? Or was it more situational where you somehow worked for companies who had a lot of AWS and you just ended up knowing a lot?

Well, I was working in one of the consultancy companies and This is like 8 years ago, something like this. And I started to, to be aware of this cloud, and it's not new at that point, but here in Spain is basically new. So we were, we were doing some POC for doing something into AWS, and I like that very much because prior to that we have to create our own infrastructure, or we have a server inside our offices. So it's a small office and we have a room with the server already there, and I have to go there and plug everything and, and put everything in the server. So I was, I was doing that in AWS and I said, this is very easy, this is the way that we, we need to go from here. But the CTO in that company wasn't too wasn't enough eager to try this. So at the end, I left that company and I went to another company where they were already using AWS. So I started to use more and more and starting learning. And then I started to get my certifications and doing all my trainings with AWS as well. I'm an AWS Authorized Trainer. So that means that I can, or I train, well, I teach courses for other companies, companies all over the world, online or in person. So yeah, I think the cloud is the present now, and in that age was the future. But I wanted to focus only in one cloud because you have a lot of clouds and you can be master of everything. So I focus in on AWS, and AWS has good things, uh, Azure has another good things, Google Cloud has another, but you have to choose. You can be an expert in all the, the clouds, so I wanted to be expert in one of the clouds, and that's AWS, because I can learn about Azure, I can learn about other things, but they are huge clouds. There are so many services in AWS. You have almost 300 services. So it's impossible to know everything in the three clouds. So I prefer to stick with one and be an expert on that one. And that's my career from that point. Only choose projects that lead me to that. Position where I have the expertise. And I had the possibility to go to Azure project, but I didn't want to because I wanted to be the expert in AWS.

Okay, I love that, by the way, Ruben, because you just talked through my own mindset and my own story as well. I remember it was back in 2010, So it was just a beginning of cloud. I think, you know, AWS came out and they offered EC2s and S3 and a couple more services. And it just so that ended up in my feed somehow. I can't remember if it was like a newsletter or blog, but I started playing with this and I was like, like, I love that, exactly what you said. And from that point on, for about like 6 to 8 years all the roles I went to, I was very picky. I was like, do you have AWS? Is AWS part of your strategy? Because I want to continue working with this. And, uh, I mean, it's been quite some years now where I didn't really actively work with AWS, but I know they're doing well and, you know, they became a huge and owned and still owns a huge amount of market. So, so good to hear you just basically resonated with me and I was like That's so nice to hear. So let's imagine I'm a new company, Ruben. So I'm coming to you, right? And maybe I'm a startup, maybe I have something, you know, maybe I'm like 20 people and we have some cloud, you know, maybe we have a little bit in AWS, a little bit in Azure, because we didn't know what we're doing. How do you approach that initial, or, you know, investigation of realizing how can you help companies?

Well, first of all, I always have this, um, this way of approach this kind of project. That is, if you are going to choose, if you're in a startup, if you're starting, you have the power to choose. It's not like if you're a big company and you have these, uh, this bureaucracy that you need to use that, that. But if you're a startup, you have to choose, and you have to choose based on, first of all, the people that you have in your team. So it's, it is better if you have some Azure expert, don't go to AWS because it's not going to work. It's going to be— but if you don't have any expert in cloud, of course, if you ask me, I'm going to go for AWS, of course. But maybe it's not the best choice for you. It depends. But if you are going to start with AWS, I would say, okay, right now maybe you have one account, maybe you have POCs or whatever, but this is going to grow. If your company is growing, this is going to start growing. So you need to put the foundation on these things. On this cloud. Because once you start creating everything, if you don't put the foundations in the beginning, then it's going to be very hard to, to refactor everything, or to, to be complaining, or to have everything in infrastructure as code. So my first approach is, okay, if you are going to use AWS, forget about the console. Use, if Infrastructure as Code and start with a good foundation. For example, Control Tower. Control Tower is a service that it creates a landing zone. And sometimes people said to me, okay, but this is too much for us. And I said, it's too much for you right now, but in the future, if you don't have this and you want to start using this, you're going to have a lot of problems. So I prefer to use that from the very, from the very very first beginning because it's easy to set up, it's free, so you're not going to be charged for anything. And it puts the foundation of all your accounts, users, uh, the guardrails that you are going to use to prevent attacks and everything, the good practices from day zero. So you are going to have everything in place from the first day. And then maybe you are only using one account or maybe two accounts, but if you want to use 100 accounts, you're going to be prepared for that. And you never know if you are going to have success the next year and you need to move fast and you don't have this, you're going to spend a lot of time rewriting things, removing things. And if you have things in production, it's going to be very difficult for you to do that. It's going to be time and money for you.

Okay, so while you were talking through this, one thought which came to my mind— let's say I didn't listen to you, Ruben. Let's say I was like, you know what, I don't need this Tower thing, I'll just spin up some EC2 manually, connect with, you know, Aurora or MySQL, and I'm off we go. Like, I don't need that foundation. And then after 12 months, I'm doing well, you know, the business is growing, the scale shows its own challenges. How easy it is to take that step back and then set the, you know, right foundations with AWS Control Tower? Like, it's, it's, is it too late, or can we actually retrospectively try to, you know, improve everything we already have through the Tower?

Well, it's not that hard. It's going to take time, it's going to take some effort, but you can do that if you need it. So if you have already an account and you have things created by hand, and you can create another account with the foundation, with the landing zone in Control Tower, and then you can join your actual account to your organization. So it's very easy to do that. But then you have to decide, how are we going to treat this, or this infrastructure that we have already here? So you have things, you have frameworks, you have tools to, to import things into infrastructure as code that are already created in your account. So you can do it in not a hard way, but medium way to do that. So it's not going to be easy, but it's not going to be very hard. But you can— or you are going to lose some control because if you want to change something, it's going to be hard for you because basically it's going to create— if you're using, for example, CDK or CloudFormation, it's going to create everything in a, in a big, uh, in a big code that is going to be very hard to, to change. But at the end is going to be infrastructure as code. So I think it's something that you can do, but it's going to cost you more time to maintain. So maybe the approach will be, okay, create that, do a mirror of your actual infrastructure in code, deploy in a dev account or whatever, and once you have everything like this, you can you can switch to this. Depending on your application, maybe you need some downtime or maybe not. It depends. But it's— if you have a lot of things, it's better to, to try to do this mirror and move, because if you need to change something, it's going to be very hard for you if you import everything.

Okay, I actually love that. If you would put that from your experience with all the consultancy clients you had and, you know, your own things you're doing and you look at the cost, you know, because cost is important, you know, for startups it's, it's very, very important. So if I'm starting this right from the beginning, I'm, I'm spending more in the beginning, so making an investment for the future, versus I'm already in the future, now I need to put more money forward to fix the mistakes I made. If you compare those two, which one is more expensive?

Well, um, there's always a I think with the, with the things that we didn't do in the past, the more time you have this without fix, it's going to be more expensive to fix in the future. So as soon as possible, you have to, to start fixing things that, you know, the technical debt that you had. If it's only one month, it's going to be fine. If If it's one year, it's going to be very expensive for you because you will have more things. Maybe you have more clients. It's going to affect your business. So this is something that is very difficult in the companies to fix or to pay the technical debt. But I think it's something that we are not doing very well with the stakeholders because the stakeholders when you get in, you say, okay, we have to refactor all these things, and they say, but you are not going to have new feature this month. Yeah, but this is costing us money, and if we spend 3 months more doing feature, it's going to cost more, more and more money, and it will be a point that we need to fix that, and it's going to be worse. Instead of using 1 month to refactor everything, maybe it's 2 months and we are going to use more resources. So it's something that is always the fight between the technical part and the product part, that they want more features and you want to do things better. So it's a balance there, and it's very difficult to try to explain to a non-technical person why this is going to cost money. Because at the end, if you are doing the things right in AWS, it's cheap. If you are doing the things in a wrong way, it's going to be very, very expensive. Okay, so when people say cloud is expensive, cloud is expensive if you don't know what you are doing. If you know what are— what are you doing, if you have with serverless application with Lambdas and everything, maybe it's 10 or 20 times cheaper than the thing that you have now. But you have the— you, you need to choose the right technology for every part, not only in the way that is technically possible, but in the cheapest. And this is where a good Solutions Architect is, uh, it's in the game. So you have a good Solutions Architect and you can go from something that is cost you €1,000 €1,000 per month to €10,000. So I did this in some companies, some project that we have €12,000, and I tweaked some things and now it's costing €1,000. You say, but this is the same application. Yes, but we are using the right services. We are using the, the, uh, the cloud how it's meant to be used. That's the difference.

I love that, Ruben. The last bit where you talked about it's gonna cost you a lot more if you don't know what you're doing with the cloud. It's, it's just nail on a head. It's, it literally that. I've been myself a couple of stories where you go from tens of thousands, even hundreds of thousands, to back to hundreds when it comes to AWS monthly, yearly bill. You're absolutely right on that. And when you talked about technical debt, you know what I was thinking? I was thinking insurance. So the model is that if you have an insurance, you're gonna pay this insurance premium every month, which might feel as a loss of money or additional cost which you don't want to have. But then when something big happens, you know, that insurance actually protects you quite well. That's how I think about technical debt. It's just if you start accumulating that, there's going to be this breaking point where that's just going to become very, very much expensive. And if you invest in the right ways, you know, good engineering practices such as, you know, doing things good from the beginning, it's just like insurance. You're paying a little bit more at that point in time when you probably don't need it, but for the long run, it actually comes up being a lot cheaper as a, as a strategy moving forward. So what if I'm a regulated business? Let's say I'm in finance or health. Or online gambling. How does the AWS Control Tower help with the governance and compliance?

Yeah, in Control Tower you have a lot of guardrails that are based in these, well, the good practices, but you have as well, you have GuardDuty, you have Security Hub, and you can put more controls for you. For example, If you are finance or health, you can put your— for example, in, in, in US, you have the HIPAA that you have to be compliant, and you can put directly this kind of controls for you and apply only for you. Or for example, for the PCI, for if you have payments, you can apply those controls in here. So if you have any problem, it will inform you, or even maybe you can do some things with this control because it's going to be— instead of preventing, it's going to— sorry, instead of information, it's going to be preventing. So it's going to prevent you to, to do something that is not compliant with your, with your controls. So this is a must for, for this kind of companies that you have a lot of compliance, and you have to inform GDPR in Europe that you can store some kind of information outside your server. So if you try to do that, it's going to hit an alarm, and you are going to be that there's some problems with this. So Control Tower with Security Hub and GuardDuty is the way to do that. When you put Control Tower, it's going to be by default activated for you. So you're going to have a lot of controls that already are there, but you can create your own control if you need. For example, if you have some rule in your, in your company that you can use whatever region, so you can only use Ireland region, you can disable other regions so no one can do it by accident using, I don't know, the Mumbai region, for example.

Okay, in the same context of compliance and, and governance, do you think AWS Control Tower has sufficient capabilities for everybody, or did you have use cases where you need to step out of AWS to meet the compliance and certifications or regulations?

Yeah, well, you have a lot of rules here, and you can add rules from third-party vendors as well, in GuardDuty for example. And you can put these new rules for you. So you can, uh, well, sometimes they have some cost for you because it's a third party that has in the marketplace their own rules that you can have the CVE problems and bugs and everything in your application as well. So you have enough information. And even if you're a big company, you can have a different level of support from AWS where they put some technical account manager for you, and you can ask them, and they are going to help you to put everything in place. So there's another option that the big companies usually have.

Okay, so those third parties— so you talked about AWS GuardDuty. So if I want to pull in some third-party rules, Are these paid or are these just free and it's just a config which you load?

There's some paid and there's some that are free, depends of the— there's some third party that put everything for free, but others are paid.

Okay, but in theory and in practice, in your experience, you never were in a situation where you actually needed to step out of AWS to look for some custom solutions? It's, it's always in the bucket? This is quite reassuring, you know, to anyone listening, because I feel like if you're walking into that more regulated industry, like, you know, payments, PCI you mentioned, or health apps, there's going to be a lot of effort for you to stay compliant and hit all the marks. And having that automated effectively to majority of this extent with AWS Control Tower and just AWS Cloud in general, that's there's so much time and so much cost which is being saved just out of that.

Yeah, I've been working in, in some insurance company in with AWS accounts, and we have a lot of regulation, and at the end, uh, we meet all the regulation. We can put our VPC, for example, to go outside the internet, so we have everything in, in a private network, and we connect to this network using Direct Connect directly. So We can upload anything using the internet. We need to use the private, using VPN and everything. So at the end, with AWS, you can be 100% compliant. You have a lot of different services to, to be compliant with the hybrid, even your hybrid connecting with your own services or your own servers if you have any server in your in your data center, you can connect directly. So it's an extension of your internal network. So it's very easy to be 100% compliant.

Very important, by the way, very important. It might be not applicable to, you know, a lot of listeners, but whoever is exposed to any type of compliance work, they would appreciate the, you know, the help which sits with Control Tower and AWS. So we talked about this, You mentioned one good practice, which is start with infrastructure as code. Are there any other best practices you would put straight at the top for someone who just either thinking to start with AWS and thinking about their infrastructure in AWS or someone who wants to migrate to AWS?

Yeah, well, the first one is that there's a lot of people that create the— when you create your account in AWS, you have to enter your email, you have to enter your password. And then you create that account. That account is what we call in AWS the root user account. So you have this root user that is your email plus password, and there's a lot of people that use that because it's the way that use all the services in internet. So you have your email and password. This is not a good practice for AWS. You should create some user with admin privilege to do that instead. And I will, uh, I will hide this user and password using an MFA, of course, in, in, in a lock and never use again unless you need to change something for the bill or something for the contact details. But anything about anything that is not that I won't use the root user because you can't— you can filter the permission, for example, or you can, you can do everything. And that's a problem in security because you don't have the, the scope of the user limited if you need it. So it's better to use one user that is only a user. And the other practice that is now, um, or that I'm using right now is I'm not using users, uh, with the new Identity Center that AWS has now. Everything is used using a role. Why using a role? Because a role is a temporary, um, a temporary permission, a temporary user for you, if you want to call that. That is not a user, but it's temporary. Your credentials are temporary, maybe 1 hour or 12 hours. So if you are compromised, you are going to be only compromised for 12 hours, for example, or 1 hour. So right now, in the new accounts that, uh, I'm creating, or the new startups or companies that are calling me for some consultancy for AWS. I said, okay, let's start with this Identity Center. We're going to create the users, and these users are going to use the users to use our role inside this application. So you can change your role and the user are going to have different policies. And if some user has this password or this credential stored in some place is not going to be there forever, so it's going to be only 12 hours at maximum. So this is another thing that— and AWS is recommending doing this as well, using Identity Center with roles instead of using users. Users are deprecated for now, so it's better to use that.

Okay, so let's talk a little bit about SSO and how that really connects up. So I have an application, um, let's take for the sake of argument I have a mobile application, it's a regulated industry, maybe it's a payment app or something like a saving account app. So I want to enable people to be able to authenticate with their Gmail, Apple ID, you know, Amazon ID. I just want to have an SSO for my app. So once they do that, I capture my users, they go into AWS infrastructure. So once they're there, I wanna potentially maybe apply roles to these users and what access they get to what resources. How do you go about setting this up?

Well, you have AWS Cognito that is the service to do this. So there's two type of different SSO in AWS. You have the SSO that is the, the company SSO, the enterprise SSO, where you have your users in maybe Azure Active Directory or Microsoft Active Directory, or you have with Gmail Workspace or whatever. So you can connect your AWS account to that directory and you can use that for logging into AWS with different roles for your users. That is something that we are using in my company right now using Azure Active Directory. And the other thing that you mentioned is that, well, I have an application that is for everyone, so I need to give these people, uh, different roles. So for that, you're going to use AWS SSO with Cognito. So sorry, you're going to use Cognito for SSO, and you are going to, to put some role into your Cognito saying that everyone that is in this pool have this role, or maybe you need some, some role for unauthenticated users, for example, to download some file from an S3 bucket or to go to the database or whatever. So you can have different permissions and you can have different groups for different users. So you have groups of users, for example, admin users, or you have premium, premium users where they pay and they can do other things, they can access to other API endpoints. So you can have all these policies for them. So with Cognito, you can do anything that you need with the permissions in, in AWS. But I'm not a very big fan of using roles directly. So if you need to download something from an S3 bucket, I won't use a role for that with my SSO incognito because that means that you need to, to have the credentials in the, in the web, in the, in the browser, and you have to deal with refresh tokens and you have to deal with that other thing. So it's easier to have an API This API is going to create pre-signed URLs, for example. And if you need to go to a database, it's easier to use an API that connects directly to that and put the permissions in the API. But that's something that you need that in order to get your application running. So you can do it if you want using Cognito.

Okay, so there's a lot to unpack in this one. Um, so let's park the enterprise access because that's a local access, right? That means that As a business, you have employees which have a directory, you know, maybe it's Google Suite, maybe it's Azure, where you're accessing all these tools. You're connecting this up with Cognito, which means you're just leveraging the already setup you have to give access to your AWS infrastructure. That's for like local. So let's put that aside and concentrate on that public application. So what you're basically saying that with Cognito, I get the access done, so I get the authentication done, and once the person authenticates, I can apply the roles of how that person would get access to my APIs. So effectively, I'm removing the need of actually code this access up in my codebase, and I'm put, you know, pushing this up into infrastructure level, right?

Yeah, so there's one good thing that is, uh, you will have everything in, in the code that you are developing in, in the browser, for example, if it's a browser application. So you have access, direct, direct access to the AWS API. So you can use S3 or you can use SNS or whatever. But the problem with that is that you, you need to have the credentials of the user stored in your browser, and you can control in, in a good way— not in a good way, but you need to change your, your credentials because when you, you log in into Cognito, you are going to get some credential that is the, the Cognito credentials and you need to change for, for an AWS credential. So you will need to have this as well, and you need to use reference tokens, and it's more complicated, but there's something that has sense if you want to, for example, go directly to a DynamoDB and do a read from a DynamoDB without using an API, and you can use that using an AWS access key. And this is with the role, so you have your token and you have the, uh, the credentials. You go directly to the DynamoDB instead of going through an API. Okay, but there's good points, bad points. So yeah, it depends on your application.

It's a trade-off, isn't it? Yeah, I think you very rightly pointed out the complexities which then becomes almost like a black box because you don't really see— you didn't code that, you know, you don't see what's really happening around API Gateway and, and how it's all set up with Cognito. And in my experience, that's exactly what happened. I remember we dealt with application which has a lot of API Gateway, a lot of Lambdas, had Cognito baked in around authentication. And anytime we would get an issue, which is just a breakage in all of that setup, it would be quite hard to find, you know, where that is, and then the debug process would actually take some time. Is there a way of improving this, like, you know, like debug or monitoring tools AWS offering, you know, maybe, maybe a better framework or not for the API Gateway? Just in general, just in general, imagine, you know, you have all this AWS setup, which is fairly complex one, how do you go about dealing with issues?

Well, you have a lot of different tools. For example, if you are creating some microservices and you have to go, for example, from, from an API Gateway to a Lambda, this Lambda hits a DynamoDB, and then you go to an S3 bucket and everything, you have a, a lot of moving parts that you need to, uh, to know exact times that you are getting this, or maybe if you have some bottleneck in some place. So you can use an AWS service that is called X-Ray, where you have basically, you have a map of everything that is going on in your code. So once you go to the API Gateway, it will say, okay, it took from the API Gateway to the Lambda 2 milliseconds, from the Lambda to the DynamoDB it takes 500 milliseconds. Then for this, so you have everything and you can, you can put even some, no breakpoint, but information points in your code. So it's going to, to measure everything and it's going to track everything for the different services. You, so you are going to see what are the parts that you are spending most of your time in, in your application. How can you improve things. Or if you are using these points, you can measure, for example, an external API call for a third-party service. You can see this, and then you can put some alarms. If you have, for example, more than 1 second in this operation, you can put an alarm, and it's going to be in CloudWatch, and it's going to you can put that you can receive an email or a Slack message or whatever. So it's very interesting to put X-Ray and it's not very, very known for a lot of people that you only use Lambda, you only use API Gateway, but not with X-Ray. And X-Ray, it's a basic tool for debugging and for performance. It's the tool that you are going to use.

That's a very good shout. And now I'm thinking about the application and how we were debugging. We weren't using X-Ray, we were just literally going like elimination process, just trying to follow the network calls. And, and CloudWatch was in play, just looking at, you know, where things are breaking. But X-Ray was not, was not part of the tooling. So likely we missed that one to, you know, to have our life easier. So, um, one thing when we're talking about, you know, all of this setup, which is just in my mind, it's, you know, fairly complex setup. Can you go and do too much? Like, can you actually, you know, by utilizing all what AWS is offering, uh, potentially maybe using AWS frameworks— I, uh, I'm not sure if Amplify is still alive, but, you know, it was one of the main frameworks of how you sort of connect Cognito and authentication. So let's say you're just onboarding all of these tools. Can you end up in a situation where, where you just have like too strict of an environment which has a huge impact of how quickly can you change things, debug things, and add things feature-wise?

Yeah, well, with these frameworks, uh, you mentioned Amplify, but there's more frameworks and more services that, uh, they try to, to simplify the, the life of the developers, of the life of the, the the people that are trying to start in AWS, they are a good starting point. But the problem is that you don't know what is happening under the hood. So you create, uh, you go to Amplify and say, I want to create authentication, and that's everything that you know. You create authentication, and authentication is working, but you don't know anything about Cognito. You don't know how Cognito— or I want to have a storage and it's going to create an S3 bucket, but you don't know what is an S3 bucket. So these are good for starting with AWS, but if you need to change things, you are not going to be able to, to change that. And if you, if you want to understand what is happening, you're not going to be able to understand anything. You know that you have authentication, yeah, and that's everything that you know. Or you need to, to tweak something in, in a very specific way, with these frameworks you are not going to be able to do that. So I prefer to have everything by my own because I have the, the expertise of this, or try to learn about the services that I'm using. That's the same with Beanstalk. If you go to Beanstalk or Lightsail now, you can create a lot of things, load balancers, and you can create databases and everything, and you don't need to know anything about how to create or the, the parameters and everything. And that's good if you want to start fast, but if you need to grow, you need to understand what is happening for you in these databases or load balancers, how to tweak that, or how to create another replica or something like this. So you have the two parts: the easy, easy way, that is AWS is going to create everything for me, and the other way, that is I'm going to create everything and I'm going to understand what is happening and how everything is working. And I prefer this second because you're going to be able to debug better your things because you are going to be able to understand how things are happening inside your VPC or inside your cloud.

Effectively, you're just getting a lot more control over everything. Yeah, by understanding, which means you're probably going to control your cost as well, much better than just, you know, looking at the generic frameworks. But you're right, Ruben, it's— I mean, starting point is just like you just pull the framework, few keystrokes, boom, you know, you got things running. So there's a real trade-off over there to make. Um, you did mention roles and AWS moving away from users. Same question, is it possible to end up in this administrative nightmare where you have hundreds of roles and you just don't remember what some of these are doing? Like, how do you actually deal with that at scale?

It depends on the number of the users that you have, or the number of— not users, the number of different tasks that you have in your team. So for example, when I was working in one of the insurance companies, we have almost 200 accounts. So you can imagine the number of different things that you can do in 200 accounts. So it's not only to the roles, just think about the networking. So how all these accounts can connect to each other. So you have to have a very good control of everything. So you will need to have some matrix or some anything to know that the role X is is for doing this, this, and this. So there's not a good way to do that in AWS in a brief or in something that you can go and see the roles with everything and you can understand because you have maybe 100 different policies and you don't know exactly what is everything. So you have the description in the role, so you can put in the description, this role is for this, this, and this. And if you have this infrastructure as code, you can have a history of the, of the different roles and how they change in, in the different versions. So, but you have to have something if you are using Confluence or you are using Google Docs or whatever, where you put all the information, because it's not easy to know exactly what can you do only seeing the policies that you have, or if you have policies with different filters, it's going to be hard for you to know exactly why is this using this with this, um, with this filter, or why are we using this other kind of thing. So this is only connecting to the account 1234, what is this account? So this is something that you have to do by your own. So there's no other option.

Okay. Is there any— I mean, you mentioned it, there is not, so I feel like this question might be redundant, but I was going towards, can you connect some type of, um, charting tool to AWS where it just goes through all your infrastructure and it goes like, here's your map?

Yeah, you have, you have some of these tools but they're, they are, they are difficult to understand because you have these tools and they do a map of all your infrastructure. But for example, if you create a VPC, you're not creating a VPC, you have to create a VPC with the subnet. The subnet has to create the route table. The route table have the rules. So you have a lot of things and you have this big chart where you have everything, and it's very complicated to, to read that. Even you can do that if you go to CloudFormation and you have some stack already deployed. You can go to the graph and you see the graph, and you can see that there's a lot of different things. So it's very difficult to understand anything from this. But then you have some tools that, um, help you to create a documentation for AWS, so you can document your things but not automatically. So you can put, this is a role, and they put the, the role icon, and you can put the description and everything. So, and it connects directly. But if you try to get everything, all the information from your account, you are going to have a very big chart. You're not going to understand anything.

Okay, that was my experience as well. I tried a couple of softwares, you know, while in the back, and none of them were really delivering on a promise of simplifying the view of your AWS infrastructure. Um, can you go— if you're using infrastructure as code from the beginning, which you rightfully pointed out, that will be helpful because you're going to be changing things through the code, so you'll be able to look at your commit history, look at the comments and why the decision was made to make these changes. Let's say I didn't do that. Let's say I manually created majority of my infrastructure, but now I want to go to the infrastructure as code. Does AWS offer something which goes in reverse, where it just looks at everything you have and goes like, here's your CloudFormation And from that point on, you can move as infrastructure as code.

There's a tool where in CDK you can import your, your infrastructure that you have already. Now, the problem is that you are going to create a level 1 construct that— well, in CDK you have the level 1 that is basically a one-to-one mapping from CDK to CloudFormation resources. And you have the level 2 that are, for example, if you say new bucket, this is going to create not only a bucket but a lot of things, but you are only going to see the bucket. If you import that, you are going to import everything in your code using bucket, bucket policy, bucket ACL, or whatever. So you are going to end with a lot of code that is not going to be easy to— not easy to maintain, but it's going to be bigger than something that you create using level 2 construct. But you can do that. So if you have something that is already created, you can import everything to CDK, and then you can apply in CloudFormation.

Okay, so there is a way of, of stopping, you know, manual management of your AWS infrastructure and going to, to code. Which I think is important because eventually, if things are going well with your product or with the business, you're going to end up with too much to manage manually, and you will, you will want to take that step towards the infrastructure as code. Um, so one question around integrations, right? So we talked about SO, which effectively integrates your, your local, uh Active Directory or whatever you have to manage your employees. You have connecting with the, you know, AWS via SSO. What if I want to plug in like a third-party tool, like, I don't know, Jira, GitLab, GitHub, or something like that, and, and have, you know, some, some integrations around AWS with that? Is, is there a way of doing that securely? And, you know, what's your experience with that?

Yes, you can put a lot of different applications with AWS. For example, if you are using CodePipeline, you can get information from GitHub when something is, is pushed to your repository, or from GitLab, or you can integrate with third-party application like— no, Zapier, the other one. Okay, but anyway, Zapier. You mean maybe—

yeah, it could continue, Ruben.

Yeah, yeah, or Splunk or whatever. So yes, you can integrate with third-party application in an easy way. And you have— if you don't have a, a straightforward way, you can only create, for example, if you need to, to use— this is something that I've been using before. We have the integration with GitLab in CodePipeline, so we need to put some code pipeline in here. So instead of doing that, we have a webhook in an API Gateway, and we have a webhook in GitLab where when you do a push, they get to us, to our API Gateway, and the API Gateway has the permissions. The Lambda behind the API Gateway has the permissions to start the pipeline. So you can integrate doing this kind of things in a very easy way. And now you don't even know an API gateway because you can put a Lambda with, with an URL, a unique URL. So it's easier to do that if you need that.

Okay, so you mentioned the pipelines, uh, and effectively integrating with, you know, GitLab or GitHub, which is a breathing life for every development team, right? This is how you're gonna do things, like you're gonna have your repository somewhere and you're going to be releasing code all the time. That's fairly easy, right? It's, it's a fairly easy setup. But what if I have multiple environments? Let's say I have, you know, staging, pre-prod, and production. That's like 3 environments. And then I have multiple accounts as well. So managing maybe, you know, couple accounts— one account is for jurisdictional zone in North America and another is something like India or whatnot. Any tips or best practices of how you deal with the, with that complexity when it comes to pipelines?

Yeah, so here when I create something new for a new company, I basically create a Control Tower account that is going to create the Audit account, is going to create the Logs account, and starting from that you can create new accounts. So the first account that I'm going to create always is the build account. So we're going to have a build account where is going to be everything is going to be centralized for creating, uh, infrastructure in other accounts. So basically this is going to, uh, to create everything in other accounts, uh, RDS or EC2 instances or whatever from this account. So you give permission to this account to put other stacks in these different accounts and you centralize everything in there. So there's different approaches here. You can have different pipelines for different environments. That is the preferred approach for me at least. So you have a dev pipeline, you have a staging pipeline, a production pipeline. Or you can have with the BitTube pipeline, you can even create different pipelines— not different pipelines, sorry, different builds depending on the branch that you are using. So for example, you have everything in your environment in the dev branch. Once you push something into the branch, it's going to use the build for the dev. And you can have parallel. So it depends on the approach. I prefer to have different pipelines, but this is only my preference. You can do it in another way. And maybe because this is something relatively new for pipelines, and I've been using the other way and it's getting good. And this is what I like to call that Inception, if you saw the movie Inception, that is going to a dream and a dream and a dream. So this is infrastructure that can create infrastructure that creates infrastructure. So we go 3, 3 levels. So you have your infrastructure is creating the pipelines that are creating infrastructure that are creating infrastructure in the other account. So you can go deep and deep, and this is something very interesting for managing multiple environments with different, for example, connecting on URLs, or you have to create different environments with different, different services. So for example, maybe in, in your, in your dev environment, you are not creating EC2 instances, you are creating some mock application, but in the staging you want to create the actual, um, the actual RDS or the actual API, so you can save money in the dev doing some kind of mocks, but you want to create the real application or the real infrastructure is staying, so it's similar to the production. So there's a lot of different strategies to go from this. You can even have the Approve. So if you, if, if you don't go to the Approve button in the pipeline, it's not going to be deployed. For example, if someone puts something to master and it's going to get to the production. You need to do the— you need to go and press the button to release everything. So you, you don't put something in production on a Friday at 12 and everything is going to freak out. So, or maybe you receive a Slack message and you click the button and everything is released. So you can integrate with a lot of tools for doing that.

Okay. Is that— so the pipelines, that's, uh, that's AWS Pipeline, right? Is it only the tool, or do you depend on things like Jenkins or some other third-party tools to finalize your pipeline, or is it predominantly just AWS tools?

Yeah, I, I used to use, um, Jenkins with AWS, but right now I'm not using anything because Basically, I'm creating everything with using infrastructure as code. So everything is created in CodePipeline. And then if I need to build, for example, um, I know I'm creating a React application and I have to use webpack to minify everything and put everything in, in the bucket, for example. I do everything into the pipeline in the build phase. So you can put your own scripts, you can use libraries. You can install libraries in, in a Docker image that you can bake for yourself. So it's not necessary right now. I've been using this in some companies that they already have this Jenkins since 15 years, so they are used to use Jenkins. But in a real application, in a real Sorry, in a modern application, a modern company, I won't use this kind of thing because you can do the same things with CodePipeline and with the build script.

Okay. And the releases are zero downtime and as well the rollbacks are just one click away?

It depends, it depends of the configuration. So you have this blue-green deployment, it's going to be zero downtime. And you can do the rollbacks, but it depends on how are you going to create your pipeline. So this is something that you have to put in your code.

Okay. Is there anything which you don't like in that setup, Ruben? Because I mean, it sounds like almost like to be too big, you know, too good to be true, or sounds easy, right? And it's never easier. So Is there any, like, bits around setting up these multi-environment, multi-account pipelines which you think could be done better from, like, AWS perspective? Maybe a feature which you're missing, maybe a, you know, a tooling improvement?

Yeah, there's something that I like from Azure Pipelines, that is you can create your scripts and do drag and drop and create your, um, your everything, your script that you need. For example, if you need to do an npm build or, or webpack build, you can drag and drop this and you create your script using a visual tool. And it's very easy for doing this from that. So this is something that I would like to see in AWS because right now you have to create your script using YAML notation with any— sorry, with all of these steps. But the good thing is that you can test this in your local environment. So you can download an image and you are going to see the output without uploading everything. So that's a good thing. And the other thing that I would like to see is that they are faster. Than now. Because when you are creating or you are deploying infrastructure as code, that is going to create infrastructure and you have to do a synth of all your, uh, all your code and you have to build and everything. Maybe you are changing one line of code and it's 10 minutes of build. So you need to pay attention to how your application is built or how to improve these kind of things by your own, it's not easy to do it in AWS. So you have to be aware that if I change this thing, for example, if you are creating a pipeline that is deploying an API behind an API Gateway and you need to build everything and, and you need to deploy everything to a production environment, sometimes it's better to split the pipeline in two pipelines. One is the pipeline that is creating the infrastructure, and the other is the pipeline that is updating the application. So you will, you will end up with two pipelines that are not related in AWS. They are related because you are creating in the same CDK. This is why I told you about Inception, because you create pipelines that create pipelines that create infrastructure and everything. but you don't see the actual information that this pipeline is related to this. And sometimes if you don't know all the stack, it's difficult to know that this pipeline is created because I need it for this. So there's no relation in this. So there's something that can be improved in pipeline as well. But AWS is good at improving things.

Yeah, I do agree. They're actually quite rapidly changing things and things are moving very quickly. So before we go and dig deeper into AWS SDK, we have this question which is in the spirit of the show, and it goes like this: what, what is one most important thing for any tech venture growth, in your opinion?

For any company that is starting, right?

Or maybe it's already started. So let's, let's, let's think like this. I'm a tech company, I could have any tech product. What is one most important thing so I want to see, you know, growth happening?

Yeah, well, you need to move fast and you need to use the right the right tool for your application. I think you need to choose wisely when you are creating your application because if you have a problem in the design at the very beginning, it's going to be with you a long time. So I prefer to spend days or even one month doing different POCs of different ways to do things and see the pros, the cons of the different models before starting to do the thing like this. I know that this is very naive, uh, from me, that everything should be like this. Yes, but you are in a startup and everything is fast and you have to, to deliver a value for your clients. Yes, but if you have a problem in your architecture in the very beginning, it's going to be very hard for you to reverse all your work. Or I know one startup that I was working with that they have this big problem that they follow this NoSQL, uh, for everything way to do things. And they end up with a lot of problems because they need transactions. Oh, you don't have transactions in MongoDB? Oh, there's a problem because right now instead of doing some transaction in SQL, we are going to have this system that is going to use Saga to reverse things. And so it's costing a lot of money and a lot of problems for you because you didn't stop 5 minutes or 1 day and think about Okay, what if we need transactions? How is it going to impact our architecture? So yeah, at the end they migrate to MariaDB because they need transactions. But this process was a lot of money, a lot of time, and they stopped doing features because they need to change that in order to get the feature that they need in the future.

Okay, so if I understood this correctly, Ruben, it's, it's move fast, but don't move fast and forget strategies and thinking and assessing things when it comes to choosing the tool. So yes, move fast, but not too fast so you just randomly making decisions and ending up in actually worse situation than moving a little bit slower and but being, you know, safe and controlled in the sense of how fast you move.

You need to move fast. Well, there's this quote, move fast and break things. Yeah, I agree. But you need to know how is the cost of break these things. So if you break the thing that is going to be the foundation of your application, it's going to be very cost for you. You can move fast if you are trying to integrate with some service and you don't know exactly how it's going to work. Okay. This is not working. We go back. But the foundation that is how everything is going to be stored, how are we going to communicate with the services, these are the foundation things that you need to think carefully because everything is going to be tied to that. But then maybe instead of using MariaDB, you want to go to try Aurora. That's fine, but it's not the same using DynamoDB than using Aurora. So this is the big question that you need to understand, how— or we are going to use GraphQL or we're going to use REST, because it's different the way that you create an API, the way that you use your frontend to communicate using a GraphQL or an REST API. So these kind of things I think that you have to think about more than 1 hour and you have to put at least that what things are we going to have with this and what things are we are not going to have. So, but then you can try different, for example, Elasticsearch, or we're going to use Elasticsearch, or so you can change some things, but not in the foundations.

Okay, so effectively, technology strategy for business sustainability and growth— don't, don't overlook it, right? In a— don't, don't make— don't move fast and break things in exchange of that. Okay, I get it. Um, right, let's go back to AWS SDK. So, um, so I know there's kits and I know there's boilerplate, and as well we talked about these frameworks such as AWS Amplify. So if I wanna start very quickly with infrastructure as code, what does AWS offer and what's your experience with this offering and how in general can I just, you know, pull something in and just go out and start doing infrastructure as code?

Yeah, well, this is something that I've been seeing a lot and I've been working with a lot of companies and at the end I'm doing the same thing that is Okay, you will need some pipeline, you will need some API, you will need some Cognito or some authentication, you will need some— so this kind of things, they are the, the main things that you will need. So once you have this, you need to create everything in AWS. So it's easy to go and use some service from AWS that you can, um, go and put in an easy way, but you don't have enough control. As I mentioned before, you're not going to have enough control to do that. So this is how I ended created the aws-boilerplate.com application that I'm nearly to put now in production. That is, okay, I'm going to give you this boilerplate that is going to have everything that you need Okay, but you can change anything that you want and you can put more things because it's like a puzzle. Because I'm tired of doing the same things in the same companies over and over again. So at the end, you need to stick to the good foundations, to the, uh, well-architected framework, but you need to have everything that you are going to use in your in your application, that is authentication, storage, and everything. So if I need to put everything in AWS with the, I don't know, the Composer service that AWS has, or Beanstalk, yeah, but I want to change something because in my company we need this special feature, or we need to put this new thing here, it's going to be very complicated to change with the things that AWS has because you don't have enough control of your infrastructure. Or if you're using Amplify, you don't have the control of everything that is happening under the hood. So you need both things— the, the part that you are going to have these boilerplates or good foundations, and the part that you can extend that, or you can create your own things, or you can put your own services in this in this boilerplate. So this is something that, um, someone asked me to do. Say, we can do this in a way that we can reproduce, because we are creating— basically, we are creating an application that creates an application. So it's a SaaS application that creates SaaS applications. And it says, maybe we can put a template and create that And we end up doing that. And I said, okay, this is something that other companies can, can use as well, like we are doing here. And this is something that I think someone is going to, to be interested in doing. And this is something that I'm finishing to, to put in for everyone.

I love that, Ruben. So we'll put in the show notes, by the way, you know, for everyone listening Ruben is an AWS trainer, consultant, and as well has this, you know, a project coming. So if you have any questions, I would like to have chat with Ruben. You know, there's going to be a link in the show notes, so, you know, reach out. Welcome to reach out. And that sounds like a great project, by the way, Ruben. And I'm sure people will benefit because, again, what you're doing is a value. You, you're giving that ability to quick start even quicker, right? And just understand that much better. So that led me to think of this question: what is the learning curve when it comes to AWS SDK? So let's say if I'm making a choice between like any other solution such as Terraform or AWS SDK or some others for infrastructure as code, how do I make that choice? It's like, which one is the most popular on the market? You know, which is the most easier to learn?

Well, you have three options. That is AWS CDK. That's one. The other is you go CloudFormation. It is for real brave people. And you have the third one that is Terraform. So at the end, the three of them do the same. But I, I have— well, I started using Terraform in, in the previous days, but then I started using CDK when they have only 2 or 3 months of developing, so in an early stage. And I say, okay, so if I'm going to focus only on creating some things for AWS, it's better to use CDK. Why? Because CDK is maintained by AWS. CDK creates CloudFormation, so it, it gets your code and it puts everything in CloudFormation. So you are going to use the AWS services to create— sorry, the AWS stacks to create all your infrastructure. So you are going to be more near to the to the native way of doing things. And you have then things like hot swapping in with CDK. You have debugging directly. So when you are using the hot swapping or the leaf in CDK, you can see all your invocations in your Lambda. You are going to have everything in your local, in your local machine. So there's a lot of things that can help you to do things quicker in AWS using CDK. But I see, or I saw, that in big companies they are using Terraform. Why? Because they have different clouds. So you have different clouds, it's easier to have one team that is responsible of creating all the infrastructure in the same language. Maybe you have some tools that create things or automate things creating templates for Terraform. And it's easier for, for your team to know only one thing, that is Terraform, that you can create Azure things or Google Cloud or AWS in the same way. Not with the same— this is something that most people have run that, no, I'm using Terraform because 'Uh, it's multi-cloud and I can change from AWS to Azure.' No, that's not the way that works. You can use the same language to create this, the different infrastructure in different clouds, but you can't change directly from AWS to Azure because you are using Terraform. But you have the knowledge how to create things in Azure using this language that is the HCL for Terraform. So you know how to create variables, you know how to— the files are going to inject. If you need to put more tools, you know how to do that. So in big companies has more sense, or if you are using multi-cloud, has more sense to have this Terraform. But if you are going to use only, or 99% or 98% of your thing is going to be in AWS, has more sense to use CDK or even SAM, that is the Serverless Application Model. But I will prefer to use CDK because you can use CDK with SAM and you can develop in your local machine using these two. They tie very good together. And as I mentioned, it's from AWS, so they know exactly how to move, put more features in. Every 2 weeks they are releasing new version of the CDK framework. So you have every 2 weeks new and new improvements, bug fixes, and everything.

Okay. Did you ever feel limited by capabilities and flexibility of AWS CDK?

No, because there's a good thing about CDK, that is you can create your own libraries and you can create your own a big constructor. So for example, in my company, we have a CDK pipeline standard. So you only need to put one line of code that is CDK pipeline my company or my company CDK pipeline, and you put your repo, you put your— what is your repo? You put what is your branch. And everything is going to be created for you. So we have some people that are creating this construct, this level 3 construct, that are big stacks where you not only— you are not only creating a bucket or EC2, but you are creating a CodePipeline with different stages with different CloudWatch logs that is integrating directly with the Slack channel that is integrated with a lot of things. So you don't need to worry about any of that. You need to worry only about putting your branch, and everything is going to be, uh, in our standards for our company. So we have this for API Gateway as well. We have this for ECS services. We have for different— for example, if we want to create a public website in S3, you only need to put what is your code and it's going to create the CloudFront distribution for you, the, the domain names and everything. So you don't need to worry about anything because there's an expert doing this kind of things in a way that is, that is standardized and it met all the security standards and everything. So you need to be an expert, and this is This is great for developers because developers start to own the, the deployment phase. So you are not only creating the code, but you need to know how to deploy this, even if you only need to know that you have to create a pipeline or an stack or whatever. But you are starting to, to give them more more tasks and starting to get into the, the cloud part of your company, that sometimes there's something that a backend developer doesn't know anything about cloud, but now you're introducing them using this level 3 construct. Maybe they don't know anything about CloudFront, but you know that CDK is going to create a stack and this is going to be deployed. So You have hybrid developers where you have knowledge of cloud and you have knowledge— because before that you have the deployment team, the developer team, and developer team put everything here and the deployment team put everything in the cloud. Right now we have everything mixed and everyone is aware of everything and know how to deal with Lambdas and how to create Lambdas and all this kind of things. So I prefer this way to approach. So even people that don't know anything about cloud, in 1 month or 2 months with us, can create a lot of infrastructure in AWS.

Okay, so I am using AWS CDK, so I am using a kit, a framework if you will. In your view, how's the documentation around this? Like if I need some help, will I find the help? If documentation is not giving me an answer, how's the community behind AWS CDK?

Yeah, well, the documentation is very well documented and the good thing is that you have a lot of examples into the documentation. So if you go to the, for example, the EC2 module, you have example of how to create an instance, how to do this, how to do that, or VPC, how to create subnet, how to, So it's very easy to start with the documentation that we have. In the community, you have different pages, even the, with the forums in AWS where you have a lot of information and a lot of people there. Even you can join some Slack communities that I think there's a Slack community on CDK or something like this, I read. Where you can ask for, for this, or even in Stack Overflow you have some code and some answers to that. So it's very easy, and I found it very easy to start with this now, because when I started 3, 3 and a half years or something like this, it was very hard because there's barely documentation. But right now you have all the samples and you have a lot of, uh, posts in Medium or things like sites like this where you have different examples too.

Okay, Ruben, that was great. Thank you for coming to the show. Thank you for sharing all of that valuable information. I hope that was enjoyable to you as it was to me. Thanks for joining.

Yeah, thank you for having me. It was It's good. It was a good time to be here and sharing my expertise in this topic.

Thank you again, Ruben.