Meta's AI Reality Check, Export Controls & The Next Cloud War | Software Sundays

This week on Software Sundays, KD breaks down how the AI infrastructure race is entering a new phase.

Meta is exploring ways to monetize its massive AI infrastructure by selling excess compute, following a strategy similar to the major cloud providers. We discuss why compute, memory, energy, and data centers have become some of the most valuable assets in technology and what this means for startups and AI companies.

We also examine expanding export controls on advanced AI models, why governments are beginning to treat frontier models as strategic assets, and how sovereign AI is becoming increasingly important as countries look to reduce dependence on foreign technology providers.

KD also explores why Meta now believes AI agents are progressing more slowly than expected, what companies overlooked during the recent wave of AI-driven layoffs, and why experienced engineers remain essential for building reliable systems.

In this week's Q&A, we cover what it means to be diligent as an engineer, why depth matters more than chasing every new framework, designing systems that can safely roll back changes, SSH fundamentals, and how Virtual Private Clouds work inside AWS.

We close with a reminder that every system naturally trends toward disorder, and why builders must consistently invest in organization if they want to scale.

Timestamps:

00:00 Meta's Strategic Shift in AI Infrastructure
07:41 Government Regulations and AI Model Control
16:05 The Reality of AI Automation and Workforce Dynamics
24:06 Diligence in Building and Development
31:42 Deep Understanding of Tools and Technologies
41:02 Database Migration Strategies
46:38 Understanding SSH and Remote Connections
52:47 Exploring Virtual Private Clouds (VPCs)
58:19 The Importance of Organization in Systems
01:03:45 Celebrating Milestones and Announcements

Join BLI University:
https://discord.gg/jpJHGq6kgS

Connect with Build Learn Impact:
- Instagram → https://www.instagram.com/build.learn.impact
- Substack → https://buildlearnimpact.substack.com

Connect with Kevin Dowdy:
- Instagram → https://www.instagram.com/mrkevindowdy
- LinkedIn → https://www.linkedin.com/in/kevinldowdy
- Substack → https://substack.com/@kevinldowdy
- GitHub → https://github.com/kevindowdy

Build Learn Impact is on a mission to help you create wealth and opportunity through technology.

Subscribe if you're ready to build the future.

DISCLAIMER: This episode is for informational purposes only and should not be considered legal, financial, tax, or professional advice. Always consult qualified professionals regarding your specific situation.

Transcript

SPEAKER_00 0:00

Welcome to Softdoor Sundays Builders. I'm your host, KD, and in this series, we have high-level conversations about technology and the impact that it has in our community. I want to make sure you have the tools that you need in order to grow your income, become an owner, and help shape what happens next. If this is your first time tuning in, you are in the right place. If you've been rocking with us for a minute, it is great to have you back. Welcome back. Let's get into it. First up for this week on the news, Meta is looking to turn excess compute into cash. So they're taking a page straight out of the AWS GCP Azure playbook, right? They already require for their business operations significant amounts of compute, data storage, networking in order to actually serve their customers and serve their customers using their primary services products. They're saying, hey, we've invested billions of dollars now into this compute for our own products. But if in if we decide that we don't need all of it, if there is a chance that we can sell some of that excess to other companies, then let's do that. That's another way to get rid of revenue. That's another way for them to make their return on investment from that AI data data center investments. So with that type of investment required, it makes sense that other companies that don't have the same cash flow, that don't have the same balance sheet, they won't be able to make the same investments that these companies have. So once you're in the position, once Meta got into the position, they're saying, hey, we have the memory available now. We have the chips, we have the energy, we have the land, all of the things that make it incredibly easy for them or easier for them to compete on the AI space than another company. So definitely is a smart move from their standpoint. It's very interesting that even like the companies that were not traditionally known for cloud were not traditionally known for uh selling their excess compute. They're being able to make a significant amount of money in this current uh climate, current environment because of AI. Because they're because they have some of the resources that the AI labs need to actually grow their businesses. And the expectation is that these labs are going to be able to generate the revenue, that they're going to have the demand. The only thing that they were missing was the supply. When we look at SpaceX, when they recently IPO'd, it was clear that although they are a space company, the primary mission behind the business is to create services for space, to be the catalyst for that space industry. But most of their revenue in the past 12 months is coming from them providing gigabytes or gigawatts worth of energy and worth of compute to anthropic. That's where they're getting their money from right now. So it is very interesting that Meta is taking the same stance. Like all of these companies that invested heavily into the infrastructure, the hardware, now that the we're seeing like supply chain issues, we're seeing memory, the price of memory going off the through the roof. The price of the chips already has been pretty expensive, but we're starting to see physical limitations to what can be done with AI, right? The energy, the chips, memory, all of these things that is becoming a limiting factor. So the AI labs that need these resources, they need the data center, they need the compute inside of the data centers. They're saying it is more difficult for us to actually procure this ourselves. But all of these companies, they already purchased it, they already invested into what we need, so they can now become the consumers of what these count we what of what these companies are selling. So very interesting, very interesting indeed. Uh, it is a very clear way of for me to make like so. What I'm seeing is with Meta investing heavily into open source models, and then because their models were not great for consumer-facing products, they actually use other models from Gemini or from Google, like Gemini, and they use their own open source models to power more internal tools, but they already spent billions of dollars on the hardware to continue to train these models. So they're looking for a way to get that ROI, they're looking for a way to make that investment make sense. So it seems like a straightforward plan to say, hey, this is a way to do what we need to do to make that brand back. And I don't think this play would really put Meta on the same playing field as an AWS or a GCP or an Azure. Like they have, I won't even say perfected, but they have continued to develop their cloud service model. They went beyond just offering VMs and offering compute. They're offering a platform as a service, they're offering infrastructure as a service. So even some SaaS product, right? Even if you look at AWS Bedrock, they are actually exposing Anthropics models, OpenAI's models, other open source models. They are exposing those models as an API. They are exposing databases that you can just spin up very easily. I don't think Meta is even going to attempt to compete there for right now, but at least on the AI model use case, right? The models themselves, we're still at this at the point where the per token cost is becoming important. If you're looking at any of these model providers' ability to kind of improve either their profit margin per token cost, or improve the you know, the cost for their customer, where they, if they can get a lower cost per token, they can offer a lower price. That's where the competition is going to be right now. And that competition is driven primarily by physical constraints. That's primarily driven by do you have enough chips? Do you have enough data centers? Do you have enough of the memory to actually power some of these inference workloads? So that's something that I feel like that's where they're gonna be focusing a lot of the niche. If if they're selling the excess compute, they won't be trying to sell the excess compute to remake S3 or remake some type of uh block storage or blob storage. That doesn't seem like a useful way space to compete right now, especially given the competitors in that space. But it's definitely something I'll keep an eye on, and I will continue to share the updates with you guys. And also, I wanted to speak a little bit more about the expansion of expert controls that is leading AI labs to delay the release of some of their new models. So a few weeks ago, I did mention that Anthropic was tapped by the US government, by the current administration, to basically lock down their newest model, Mythos, and as an extension, Fable 5. That directive was driven primarily by the government saying or getting a report that said that the safeguards that they put that Anthropic put in front of these models to make it less likely for someone to abuse the system, those safeguards weren't good enough to actually protect against uh a threat. Or, and so I think another company I saw reports about it being AWS, but I'm not totally sure. Allegedly AWS, uh someone from that camp basically proved that they could jailbreak the model and therefore get some of the get the model to do things that it wasn't supposed to be allowed to do. So when that news broke, it was like, hey, we gotta shut it down. We can't let anyone else have access to this. This is actually a security concern. This this is something that if our enemies get access to this model, they can have a negative impact on our infrastructure, critical infrastructure. That could be financial services industry, that could be uh power and energy grids, like that could be utilities, anything. If they have access to this, the cybersecurity threat is well that the cybersecurity threat landscape is no longer secure. So they have to shut it down. But the way they shut it down was what I thought was interesting to kind of highlight because I mentioned that it's very rare for software to get flagged under a export control, and that's that's pretty true. Like there are some encryption algorithms, or the encryption algorithms do get covered under some export control laws, but for the most part, the common open source encryption algorithms that we use, none of those are technically control, like none of those would be get would get flagged under needing to be controlled or needing to have expert controls applied to them. And I could understand if we were saying that like a I think a year ago, there were some talks about controlling the weights of models that were trained over a certain amount of data or worth a certain amount of data. Like there was a limit in place there. That law never actually got put in place. But a month ago or two weeks ago, it was decided that although we don't have any laws to specifically uh control the export of this type of software, we're going to do it because it has some militar there's a potential military consequence if this model gets or if access to this model gets uh proliferated. So it was all about saying that the model represented a security risk, but then finding laws that would make it okay for the administration to say, hey, we can lock it down with this law. And at this point, that there's been some conversation. I think the restriction has been pulled back, but it's been pulled back with the understanding that Anthropic now has to provide more open access and freer access to the US government in order for them to continue to operate and release their models freely. And that could be in the form of them requesting more data, right? When they initially made the restriction, Anthropic had to shut it down for everyone because they actually had no way of distinguishing a foreign user versus a uh US user, they didn't collect that data, they collected your email and your name. Now, they may start to collect additional data from you. They may start to collect and want to see your ID, they may want to see your address, they may want to know who you are. And once they collect that information, if it's something that the government requires them to share before they make a model known or make a model public, that's something that they may be compelled to actually share. And it's something that we're seeing happen with OpenAI too. OpenAI had to limit the release of their newest model because of the government basically not pulling the same stunt, but saying, hey, we we still want to get a sneak peek into it. We still want to know how this will work, what impacts it'll have. And so the model was only released to a select few, select group of partners that the government kind of whitelisted or allow listed to say, hey, these guys can check it out. So we're getting to the point where this technology is being used and protected again, like national security infrastructure. Even partners of the US government, like right, like, yes, the companies that are US companies, a few of the larger ones get access to the model. But there are partners in other countries that are there are companies and entities in other countries that are partners of the US government that got blocked too with this directive. So it's it's something that it becomes even more important to consider sovereign AI and sovereign digital uh systems. Like, do you have access to a model that's not controlled by someone else who may or may not take access away from you, depending on how their policies are going? That type of question becomes incredibly important when we're talking about export controls and whether or not a company on US soil can make their technology, their solutions, their products available to another group outside of the country, or even inside of the country that may not have the same uh not may not be on the same page as the US government. That's something to definitely keep in mind and definitely monitor, see what else becomes I don't even want to say government property, but what else does the government want to have access to before they allow you to make it? Or they allow you to have free reign with it? And how long do you have free reign with the technology before they start to attack you and say, hey, we gotta lock this down, or hey, we need access to it, or whatever maybe, whatever the conversation might look like from the back office standpoint, how long does it take to really get there and what does it require? Do cloud service providers become export controls? They're not currently like right now. Anyone in the world can spin up a new EC2 instance, anyone can set up a new S3 bucket, anyone can do these things to use the technology that AWS provides, but if the data that they are collecting or getting access to, if that is export control, then that's where some of the uh requirements come into place. But what export controlled data do these models have that make them or that allow them to meet the criteria for needing to be export controlled? That's something that really needs to be discussed a little bit more. But one of the potential benefits from a you know a big business standpoint, big tech standpoint, for locking down the models is that there may be less chance for model diffusion. I mentioned it a few weeks ago, models that are cheaper to build. Scratch that. Basically, there have been reports from some of these AI labs saying that there are companies and entities primarily in China that are using the frontier models, setting up fake accounts to use the frontier models from these labs to actually train their smaller, cheaper models. And when you that's basically big AI teaching the little AI how to do what the big AI does, it doesn't make the small AI as smart as the larger one, but it does make it cheaper to run, it does make it cheaper to train, it does give similar results in very specific domains. And from a business spits, business perspective, if you're able to provide something for cheaper than someone else, then you can capture more of the market, and that's what we're seeing from a cost perspective. The amount of capital required to continue to build and innovate, some of the models from Anthropic, OpenAI, that capital is looking for a return on investment today. They're starting to increase the cost per token, they're starting to lock down certain capabilities of these models unless you're paying the premium. With an open source model, you don't have to pay that premium, and so they might be able to shift and pull some of that revenue out of the US into these Chinese companies. But it's something that we're keeping in mind and we're continuing to monitor. And in some other news on Meta, Mark Zuckerberg says that AI agents are not adapting and not progressing as quickly as he and his team have expected. So Meta has publicly uh laid off at least 10% of their global headcount. That's thousands of engineers across every country, and they shifted, reorg, reorganized the rest of the teams to be in more AI native, AI-centric groups. Because the entire theme of the last 18 months, probably even longer, was AI was going to replace every white-collar worker and eventually the blue-collar worker. Right? We no longer need humans to do these tasks because AI can do it better, or AI will be able to do it better than any team of humans can today. And that was a that was more wishful thinking than actual exploit, actual results. When you actually play around with these models and use them in real use cases, you realize their reliability is not there. You still need, from my perspective, a human in the loop. You still need someone on the ground who understands the business, understands the rules, understands the requirements to say, hey, this is not okay input, or this is not okay output, and this is what I need to do to fix it. How do I get it back to a state where I can trust it? How do you monitor for that? A lot of the times, yes, you can kind of build in checks and balances in these automated systems so that you have less likelihood of something going wrong or less likelihood of an automation that breaks for some unknown reason or some known reason that was just not tested for. If it breaks, we can build some type of safeguard and to prevent it from having effects on some of these downstream systems. But That type of system thinking, that type of awareness requires someone who understands the business already. So it's not like something that you can just build from a developer coming in, not knowing anything about your business or your team and saying, hey, do this. You need someone who actually has been in the field in the game for your team and understands those edge cases. And because they can then translate their learning and their wisdom and their experience into software, into a design that can be implemented by AI or implemented with AI. But it's not something that you just go zero to fully automated or a hundred to zero people fully automated. That's just not how things work. So when we are seeing these companies lay off large portions of their team, there's two problems that I see in actually moving from a break, a hard break with a layoff, to actually getting to reliable automation in a gensec workflows. One being you lost the experience. Whatever the reason, they actually understood the business. They understood what needed to be automated and what could not be automated. You got rid of them, and now there's no one who can recreate that source. There's no one who understands the recipe enough to say this is what we need, this is what we don't need, this is what we can replace it with. So that's one pretty significant problem that comes. And the other, maybe I won't even say bigger problem, because it's not as difficult to overcome, but it's pretty difficult to be aware of because there's nothing you could do about it when you're in the thick of it. And so that is when you get rid of half of the team that was needed to do some type of business function, the remaining half now becomes responsible for the hundred percent of work that needs to get done. Now, when we're trying to automate a system, that counts as additional work. That counts as new development. And that new development requires a certain amount of capacity from the team. You can't assume that a team that is doing the work on the ground operating has enough bandwidth and capacity to actually go out and do the research necessary to implement some new technology, to redesign a system, to you know, make the best use of the new tools available to them because they're going to be too busy trying to keep the ship from sinking. They're trying to not let everything fall apart, but they're they don't have enough time. There's not enough bandwidth for them to actually do that and manage that effectively. That's one of the more difficult challenges I see in just mass layoffs without understanding what we're going to do with or mass layoffs with the objective of automation or moving toward more automation, but not really understanding the midterm, short-term consequences of those layoffs and of those changes to the org and morale and actual execution ability. But the thing that I'm seeing is we're moving beyond AI being a novelty, we're moving beyond just a tech boom driven by people saying, hey, AI could do this, or AI is expected to do this in six months, 18 months, whatever it may be. The scale of the investments into AI from the hyperscaler standpoint and how much money they spent on data centers and energy to the businesses and organization level, and how much money they spent on tokens to actually create POCs and to actually develop and operate their agency workflows. They're looking to see what is the actual business value, what is the ROI from these investments. And if that ROI or that investment cannot be tied to a specific business objective or specific business value, then we're going to have a challenge or we're going to have a problem continuing to make the investments at the speed that we're currently making those investments. And so consider at what point does POCs and testing of AI become more expensive to manage than just having a person on the ground to do that work. That's something that we got to keep in mind as we move forward. But if you want to go deeper into any of these topics and explore the opportunities they create for you and your family, join BLI University. Every week we are having high-level conversations and discussing the biggest topics happening behind the scenes with a community of builders that are helping to not only research the changes, but are actually driving the revolution, building software, shipping code, and making things happen. So join us. And we're gonna jump into the QA section for this week. Got a few interesting questions to you know scratch your mind, make you think about you know how to be a better builder and improve your career, improve the things you build in your projects, and just you know, all around execute more efficiently. What does it mean to be diligent? So the definition, if you look in a dictionary of diligent, is having or showing care and conscientiousness, meaning the quality of wishing to do one's work well and thoroughly, and basically having or showing care and conscientiousness in one's work or duties. So that means when you're given some type of responsibility, when you have a job to do, you're not just doing the job to say and check off a box and say, I did the job. You're doing the job to say, I need to do this job as well as I can at the best that I can. That means the quality matters to you. That means that you're paying attention to details to make sure that exactly what you meant is what you're actually delivering. That means your speed matters. That you're not taking too long to deliver something, but you're not taking shortcuts just to move faster to get it out the door because it matters what you provide. And this is actually a rare trait. And I'll say it's rare because a lot of the time people get caught up in other things that may prevent them or make it feel like they are being prevented from being diligent, right? When you're working on a team that has a lot of shifting and conflicting priorities, it is understandable that you start to focus on just shipping something because priorities change and they keep changing and things are just unreliable. Or when you're having to move fast and you you know you skip a step, even though you know it's an important step, but you recognize that hey, this other priority is maybe more important. So it's rare in understanding that hey, we have to be as builders, we have to be very careful about what we are putting out there and the energy we're putting out there and how we're building. Because everything that we build, for the most part, matters to someone. That may not mean you're working on the critical system for an airplane, you're not working on the software for a hospital or medical imaging machine or some other medical machine. You may not be doing that, but the software that you're building, someone is going to rely on, and so you have to understand who that person is, what they expect, and what types of you know mistakes they can actually live with. Some people in some industries can tolerate more mistakes, some workloads really cannot. But if you ever heard of the phrase like how you do anything is how you do everything, that's literally what we're talking about with being diligent. If you're going to do something, if you're going to ship some type of project, if you're going to create a document, if you're going to launch something, whatever it may be, you might as well do it diligently because that represents you. It represents your ability, your ability, your thoughts, your uh your workmanship, like all of that. So keep it in mind. And if you feel like it's difficult for you to be diligent, or you don't know how to be diligent, understand that it is a learned skill. The people that learn to notice the things that matter are the ones that will further improve their ability to be diligent. They start to notice what checklists matter, they start to notice what follow-ups are important to make. They start to notice when to add a test or when to add something versus when not to add it. That's really an experience-based decision making versus assuming that you know some people do just know it. They they're naturals at it, they're more talented naturally. But again, anyone can learn the skill, anyone can learn to recognize what is it, what is important so that they can eventually be diligent in the things that they do and work on. But really, everyone, no matter what you are building, it is worth investing in that skill. It is worth investing in your own learning and development to make sure that you are continuing to improve your efforts, continuing to improve the outputs of your efforts, and that desire to improve, that desire and willingness to work hard enough to get it to be better, that's all diligence is. So I really encourage, especially like early to mid-level, right? Before you get to super senior and you just know the theory behind everything, you can understand the theory behind something because of experience, not just off of something you read. Which reading about it is also helpful sometimes, but do your best to pick a stack and stick to it. Pick a lane and stick to that lane. Because that stack like learn a cloud provider, learn how to use an IDE, learn how to use a specific database, a programming language. Like, once you have that stack understood, then you start being able to make connections between everything in that stack and some other tool. And that conversation with yourself, that learning and that uh onboarding for you and these new tools becomes so much easier because you have something to connect it to. You're not just saying, hey, I'm learning about React, and I'm learning about Angular, and I'm learning about Flutter, I'm learning about whatever this other new framework might be. You're saying, hey, I am building in a web application. I am building a user interface that connects to a back-end application. This user interface is a you know, is deployed in this environment, and this is how my users interact with it. This is what they need to do. Like you understand the functions behind the tool versus the tool being the main thing that you kind of grasp on to. You gotta be able to connect them, and you can't connect them just by having some type of shallow understanding of what it does, or right, just understanding what it does. You don't know what it what it's meant to do. You just understood what you learned about in a tutorial, but you gotta be able to get deep enough to really close those gaps because it makes you a stronger engineer, makes you a stronger person to work with, because now you're not just understanding the happy path for when we use Terraform, you're understanding what happens when Terraform breaks, you're understanding that I cannot use this tool in this way because it's not how it's designed to use. Or you might be able to say, hey, I can use this tool for this way, even though it's not designed for this. It offers some functionality that makes it a great candidate for using it in this way. And again, that is that requires depth, that requires some time to be put into it, some practice to be put into it, and you can get there, but it takes some time. But really, as a developer, as a builder, just understand that when you just focus on the surface area of anything, whether it's an industry or a tool, you're never going to have the wisdom and the experience that you need in that area to actually compete with the people and support the people that work in that area more often and that have studied it, have spent time in it. And that's what we need, that's what we are looking for. As a developer, you are the tool builder to help enable this industry to go faster, to go farther. If you don't understand the tools that you're working with, how will you be able to support them inside of what they're trying to do? How do you make changes that are simple to roll back? So it really does depend on what you're trying to roll back and where the change is. And then that might be different from if you're you know making changes to your infrastructure where you have infrastructure as code where you can actually roll back to a specific state and potentially not roll back to a specific state if that old state is end of life. So you have to consider that type of scenario. And then if there's an application where you know every release has been uh stored inside of a repository and you can always get back to it, that might be easier too.

SPEAKER_01 40:58

But then all right, we had a few technical difficulties, but we back online now. Alright.

SPEAKER_00 41:10

So we're talking about migrating a change for a database or making a database change, which could be migrating your database, it could be updating the schema, it could be uh anything really. It could be well, that's probably the two biggest changes you wouldn't make for a database itself, other than changing the version of the database, but that's pretty much a migration at that point, because then you would create or set up the new database using that newest version, and then move your data from the oldest version to the newer version. But you would need to be able to make sure your application continues if if you don't shut the application down, you have to have your your application set up in a way where it manages that change. It can either read from the old version and write to the new version for a specific amount of time while you're you know getting to the end of that change and everything is being completed. But that type of strategy needs to be put in place whenever you're making any type of change, whether it's for the infrastructure, whether it's the application, whether it's a security uh configuration for your environment that the application is running in. You have to understand what could potentially go wrong. You should be aware of any like points of no return where like if if you run this command, you either have to go all the way to finish it, or you have to know that you have to then start from a backup. You can't like stop midway and think they're going to recreate or rebuild the database if you run a command to delete a table. At that point, there once the delete has happened or you've updated a column, it's gotten to the point where hey, we can't just roll back efficiently. We either have to continue or we have to start over from our backup. That's something you have to consider inside of your planning. You should know what you would do in either scenario. Like, let's say something breaks after the point of no return. Where's the backup? You should know that. You know, how do you actually uh load up the backup so that you get back to that place? Do you know how to do that part of it? If you document all of these processes beforehand, before you need them, your process and your workflow for actually getting it done is going to be much easier than if you try to wing it and then. Then something wrong happens, and you now have to pivot to kind of recover. But some things to keep in mind for any change, you know, document what the change is. You should log exactly what the change is, why we're doing it, and how it was implemented. And you could put that in your change log, you could put that inside of the release notes, like put it somewhere that the rest of the team can either track it and can learn from it in the future. And then make sure you're always having a backup for a database that might be an archive or backup of the database itself, a snapshot of the disk, or for an infrastructure that's code that might be a previous version. For an application that could be a previous build, right? You want to have something that you can go back to if anything wrong happens during that change. And in some businesses, some industries, the uh not even the capacity, but uh the the comfort with changes to such a small degree that uh they don't even shut down the old system before they start uh uh testing the new one. Right? So you might just have to switch over traffic from the or you might not even have switched it over, but basically you could have an entirely hot and ready environment to move your change to, or to make sure move your change back to, right? Let's say you're setting up a new environment to have all of the changes that you wanted, but the old environment still exists. If you haven't switched over the traffic yet, then you can just continue to leave it where it is. If you have switched over the traffic to that new environment, you can always just switch them back with a very simple configuration change. That's something to keep in mind, but you should always have a rollback strategy planned, not as an emergency improvisation. It should be something that you have a planned path to get back to where you want to be because anything else is going to be a stressful situation for you and your team.

SPEAKER_01 46:38

What is SSH?

SPEAKER_00 46:41

So Secure Shell is a network protocol that allows you to connect remotely to any other computer or server that you have set up that connection with. So SSH requires you to set up in well one, it uses in encrypted network connections, and you can use it with a Windows computer or OS, uh, Linux, Mac, and it'll encrypt the communication from your terminal to that remote device. And that encryption does rely on keys, so you have to set up a key beforehand before you can try the SSH into the machine, or even you set up the machine, you should have set up the key so that's available for you to connect to later on. But once you're connected, you can manage files, you can run commands on that device, you can install uh dependencies, software, whatever it may be. You can do everything that you would do with your computer that's in front of you, the keyboard that's in front of you, you can do that with that remote computer. So think about like you wanted to do something on the server, and instead of having to go to the server and you know, plug in your or connect your keyboard to that server that's in front of you, you can get the IP address of that server and connect to it remotely. You provide the key, you provide the user that's connecting, and then you say, Hey, jack me in, log me in, whatever it may be, to that server. And now everything that you would do with that server as if you were in front of it, you're doing from wherever you are in the world. So, from a security standpoint, that's two things to consider. You want to make sure you are managing the keys to make to handle that connection very uh professionally, right? If you're providing a way to connect to this server from anywhere in the world remotely, then you want to make sure that only the right people, only authorized people are able to do that. So you don't want to have your key somewhere in a public repository, you don't want to have the key somewhere being shared over email. You don't you don't want to have too many people having access to the key where you can't actually uh audit who has it, who's using it at the current moment. You have to be very careful with that. And for most environments, you probably won't even have SSH access into any of the production servers. I personally never had SSH access into a like a VM that was running our workloads, but I have had a similar ability to run kubectl execute or exec and open up a shell inside of a pod that was running inside of production environments, but even still, even then, that's like no Spider-Man with great power comes great responsibility. You shouldn't be doing that often. You should not often need to like backdoor into your production server.

SPEAKER_01 50:04

If something is wrong, roll back and then figure it out inside of a lower environment.

SPEAKER_00 50:11

I personally don't think there are too many reasons to actually be able to connect and open up a shell inside of a production odd, whatever it may be. Like even to collect logs, you should have some type of agent running in that environment to pull the logs, and it should be going to some other system that has authentication, that has authorization, uh, that is audited. Any type of direct to server communication is dangerous because it presents an avenue of attack that is more difficult to protect again. But yeah, I would say SSH is still a useful tool to understand and know. It's really just an extension of if you understand Linux commands or uh PowerShell commands. SSH is really just a specific tool that you would use to connect and start running those commands on some remote computer. But all of the same commands that you will run from on Linux, whether it's a cat, whether it's a CD, whether it's an RM, like whether it's a Git install, whatever those things are, you would still be running those commands. It's just now you're running it on a device that you may not be in front of. Let's say if you're setting up a VM inside of a cloud provider. Let's say you set up an EC2 instance in AWS and you want to do some things inside of that instance that you could not potentially do on your local computer. Let's say you're training a model or you are running some type of model and your computer doesn't have the resources capable to run that model, you can SSH into the VM that EC2 instance and start running those commands so that you can practice and test some tool that you wouldn't normally want to run inside of your environment, your own local environment. Essentially, malware analysis you could run. Um you could do some security testing inside of an environment, an environment that you set up for yourself so that you can kind of learn and practice without using your own computers as dummy computers.

SPEAKER_01 52:41

But definitely something to learn about and keep in mind. What is a virtual private cloud?

SPEAKER_00 52:50

So a VPC is like their own private network inside of the AWS environment. That VPC and that network is the equivalent of your organization's data center's network. But it's instead of it being inside of your traditional data center, inside of your environment that your IT team manages, it's somewhere where the physical hardware, that is the cables, the uh firewalls, the gateways, routers, all these things are actually managed, the physical side of them at least, are managed and operated by AWS themselves. You don't have to handle or think about any of that physical uh toil on you and your team. The VPC is a so I get from an implementation detail, every AWS account is going to include a default VPC inside of your AWS regions, like all of them. And it'll create a separate subnet, default subnet, inside of each of those availability zones inside of the region. This is so that everything that you spin up, every instance that instance that you launch inside of that account can actually be connected to. If there is no VPC or no subnet that the EC2 instance or the ECS instance is connected to, then you won't be able to connect to it. It basically just exists as a box somewhere not only in on not on the internet that cannot be accessed anymore. So you want to make sure you have at least some type of network connected to everything that you spin up. I think you have to like, I don't think you can even delete a VPC if there's something connected to it when you create or when you're moving around an AWS environment. But for most projects, like if it most personal projects, you're fine to just use the default VPC. If we're getting into production workloads for clients and for other like industries, then it's more important for you to set up a custom VPC that's more locked down, more secure. You might limit the IP side of ranges available, you might set up more specific and limited routing rules, you might not put an internet-facing gateway on that VPC or on that subnet. Like there's things that you do from a networking standpoint to make sure that the environment that you're deploying your application to is more secure. That's all for your production ready VPC configuration. For the most part, testing personal projects, don't even worry about that. Do remember that most applications and services on AWS, I would say most or some of them, do require you to have a VPC. So at least be aware of what that VPC is, what it does, because it's going to be important for running these other services, and whether or not like a node inside of your ECS cluster or your EKS cluster is able to connect with another node, and whether your control node is going to be in one VPC versus your uh worker nodes being in some other VPC, do you have a way for those VPCs to connect to each other or at the start of VPC peering for those networks to connect to each other? That networking aspect becomes very important when we're thinking about large-scale deployments of systems. I think from a role standpoint, network engineers are probably the most likely to spend a lot of their time setting up networks and VPCs inside of AWS. But it is still important for developers to understand, too, because the VPC represents the network that your server that your application is connecting to. So if you don't understand the limits of that network, then you may not be able to build your application in the way that it needs to be built. You might have to redesign certain things in your application, and you may have to configure your application a certain way in order for it to work with the network that it's attached to. So just remember that designing the network is really like a foundational skill inside of AWS or building secure systems inside of AWS. You may not have to do it by default if you just want to get something up and running because they have those default resources, but it is very important when you're looking to build something and maintain something over the long term to understand how that connection, how that data flow is maintained in many. That's all we have for the QA for this week. Uh, thank you for listening. I hope you got some value. If you have any further questions on anything related to the topics that I've discussed, definitely drop a comment inside of the comments under this video. Uh and we will take a look at it. Quick mindset tip before we jump out of here. I just want to highlight that the default of every system is going to be disorganization, right? There is that uh I don't know if it's a quote, but basically, a system, a closed system is going to trend towards disorganization, not chaos. I think I hear chaos, it's mentioned a lot, but it's not necessarily chaos, it's just more entropy, it's more options available. Things could be anywhere, but whenever things are anywhere and they have no set place, they become more difficult to manage, more difficult to scale. So remember that it takes consistent effort to organize systems, to organize processes and people. And that effort, if you ever slow down and take your eyes off the ball for too long, it's going to result in things just going back to that disorganized state. So for you to make the both, I guess the best advice I can give for you for any type of long-term goals and long-term objectives that you have, is to train yourself to be aware of the state of the system in the environment that you are in. You should be aware when something is moving away from the target state. That doesn't mean you have to jump on it immediately, but that means you have to be aware that something is not the way it's supposed to be. And then once you have that awareness, make sure you have and allocate some time, save some time available and some energy to go update and fix that environment, to clean it up, to go organize it, to do something to make sure that that disorganization doesn't start to grow from what you're currently looking at. You have to be able to catch the issues before they pile up. That could be in your house with just cleaning and making sure your room and your space is clean. That could be inside of your team and making sure that any problems or any you know lack of communication, any type of disagreements, those are being managed effectively and managed as quickly as possible so they don't continue to grow into bigger, more difficult problems that are harder to solve, basically. Then that could be inside of your systems that you build. You're building an application and your code base starts to get cluttered, starts to get messy. You don't document why certain decisions are being made or changes start to get lost and it just tracked willy-nilly. That's another problem that it doesn't scale well after you do that, or you let that problem uh kind of get worse over time. Remember to keep your eye on the ball, remember to stay vigilant to protect against this organization.

SPEAKER_01 1:01:16

And so, quick announcements before we get out of here.

SPEAKER_00 1:01:19

Uh, happy birthday to my cousin Jameer. I want to say, you know, keep up the great work in school with your football. I am very proud of you for the work and the effort that you're putting in in order to improve your reading. And, you know, keep up that good work. You definitely are doing your best, and it is valued. So continue. And enjoy your day. Happy birthday. Enjoy your day. Hope you are feeling proud of yourself, all the work that you're putting in and feeling you know happy that you here that you are living your life, doing your thing, and being your best self. Keep it up. Happy birthday to my cousin Jojo. Uh, one of my favorite cousins. I love you and I love when we get to speak to each other and get with each other. And really, all like a younger me, not a younger me, like you're younger than me, but I really do look up to you in a number of ways. Like as a father, as a husband, you all doing your thing. Very proud of you. I love to see you doing your thing, and your life is definitely appreciated. So keep, you know, keep being you, keep maintaining, keep growing, and keep just doing your thing, my cousin. Happy birthday, enjoy your day. Happy belated birthday to my mom-in-law. I already wish you a happy birthday, but I wanted to make sure I gave you your own special shout out because you deserve it. You are and have, since I've met you and even before I've met you, been a large source of love and support and kindness to your daughter and to an extension me now. And I definitely appreciate that. I appreciate the uh like the sacrifices you make and how hard you work to put on for your family, and it's definitely appreciated. So, happy birthday. I hope you enjoyed your birthday and you are enjoying just you know being happy to be alive and enjoying all of this, your whole year. So, happy birthday again, and I wish you many, many more. And that's what we had. Oh, quick uh announcement, not an announcement, but basically, we're having a BLI university session this week. We're gonna be going over how to run an LLM locally using Olama. That's gonna be on Thursday at 6 p.m. Uh, one of the things to remember with the like running a model locally, I just mentioned earlier today, like these models are getting more expensive to run, but people are becoming more and more reliant on them. Don't get to the point where you are relying on a model that could be taken away. Figure out and learn with us how to run that model yourself locally so that you never have to deal with or worry about you know getting your access cut off. We're gonna be working on that uh in a few days. So stay tuned for the invitations. It'll be live on YouTube and Twitch or whatever. We're gonna be live doing that, sharing that information. So check it out, keep an eye on it. That being said, peace out, my peoples. Enjoy your week. Continue to be great, continue to do your thing, and I will see y'all in the next one. Peace out.