Screaming in the Cloud - Teaching a Stanford Cloud Course with Aditya Saligrama

Episode Date: May 23, 2024

On this week’s episode of Screaming in the Cloud, Corey  is joined by Stanford computer science student Aditya Saligrama, who recently taught a Stanford course on cloud infrastructure. Aditya shares his unique perspective on various topics, including how higher education approaches teaching computer science in a rapidly evolving landscape, why he chose cloud security to begin with instead of tacking it on at the end, and what his plans are for the rest of school and beyond. Corey and Aditya lament the lack of real-world skills taught by universities. Aditya shares with the audience just how much work goes into being an effective undergraduate-level teacher while being an undergraduate student himself. Show Highlights: (00:00) - Introduction(01:57) - Exploring CS40: cloud infrastructure and scalable application deployment(03:46) - The evolution of computer science education(05:09) - Bridging the gap between academia and industry(09:05) - Aditya's journey into security and cloud infrastructure(13:09) - The Stanford security clinic: red teaming for startups(14:09) - Internship insights and cloudflare's upcoming role(16:06) - The challenge of cloud account management for students(17:59) - Improving cloud education and accessibility(22:10) - The technical and educational challenges of CS40(29:29) - Final thoughts and where to find AdityaAbout Aditya Saligrama:Aditya Saligrama is an undergraduate and graduate student at Stanford University studying computer science, focusing on systems and security. In the Winter of 2024, Aditya taught CS 40 (Cloud Infrastructure and Scalable Application Deployment) at Stanford, the first university course ever to teach the fundamentals of deploying apps on the cloud hands-on using infrastructure as code. Aditya also leads the Applied Cyber student group at Stanford, winning first place in a national cyber defense competition in 2023 and second place in a global penetration testing competition in 2024, and advises early-stage startups on their security needs and posture through the Stanford Security Clinic. Aditya enjoys hiking, photography, and ping pong in his free time.Links referenced:Aditya’s Twitter: @saligrama_aAditya’s Website: https://saligrama.io* Sponsor Prowler: https://prowler.com

We just wanted to use AWS because that's what we were most familiar with, and that seems to be the industry standard in some sense, the most popular platform, and the one that actually has assurances of, yes, this product will stay around in the next five, 10 years. Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is Aditya Saligramma, who is many things simultaneously an undergraduate and graduate student at Stanford, which I was not aware that that was something that you could do, and the instructor of a class, CS40. Aditya, thank you for joining me.

Great to be on the show. Prowler works wherever you do. It's an open source powerhouse for AWS, Azure, GCP, and Kubernetes. From security assessments to compliance audits, Prowler delivers with no hidden corners, just transparent, customizable security. Trusted by engineers and loved by developers, Prowler lets you start securing your cloud with just a few clicks

with beautiful, customizable dashboards and visualizations. No unnecessary forms, no fuss, because honestly, who has time for that? Visit prowler.com to get your first security scan in minutes. So let's start at a very high level at the start of it.

How are you simultaneously a grad student and an undergraduate student? It feels like someone needs to open the box, observe you, collapse the waveform, and then for observing something, CloudWatch charges a $700 charge, which is neither here nor there. What are you exactly? So it's a great Jekyll and Hyde story. It really depends on which bureaucratic function of Stanford University you ask. But the long story short is that Stanford offers a croterminal master's program for most programs. And so I am simultaneously in undergraduate and graduate students studying computer science. About junior year, I applied

for the master's. And I've actually been taking classes towards that master's since sophomore year. Typically, most people will remain on undergrad status until the end of their senior year. But to make matters even more confusing, I switched to graduate tuition status midway through my senior year, which I'm currently in. So it actually really depends on who you ask at Stanford, what I really am. And just to confuse this even further, you're the instructor of a class, CS40. So you're basically simultaneously undergrad, graduate, and faculty in some sense. And then it's just, wow. It's so basic.

Raise your hand if you're here for the rest of the question. Your hand goes up at that point. So what is CS40? And I should be honest here. I'm roughly aware of it, given that apparently you were so out of ideas that you invited me to come in and basically more or less subject my sense of humor, such as it is, to a room full of undergraduate students, which was a fantastic experience. My stars, they ask good questions. But what is the class? So CS40, the title is called Cloud Infrastructure and Scalable Application Deployment. And the idea

of the class is basically teach students how to take existing web applications, or maybe ones they develop and deploy them to the cloud. The motivation for this was, so I've kind of been working with the Stanford entrepreneurial community for a while. A lot of students here have startups or want to found startups and through sort of that process of working with them like and actually especially finding security vulnerabilities and reporting them or sort of hosting them and like helping them find their own vulnerabilities you wind up actually using that as a window into their deployment topology and you know over time you kind of come to realize that

the you know tech stack choices that they make are not necessarily optimal, you kind of come to realize that the, you know, tech stack choices that they make are not necessarily optimal for the kind of product they're building. And also kind of subjects them to difficulty in migration later on. And so this class is kind of just motivated based on how do you take, you know, people who want to build a startup or really people who want any, you know, technical software engineering career and sort of teach them the basic cloud skills that they need to do that. And so basically this involves like teaching, like, what are the resources available on the cloud that are offered by cloud providers? And then how do you systematically using infrastructure as code deploy things? I'm just marveling at how enlightened that entire approach is, just because back when I went

through the start of a computer science program 20 some odd years ago, it was a very different universe. Like, what language are we going to learn to write code in? Pascal. Great. Who uses that for things? Absolutely nobody. Great. What is version control and how might I use it? Like, no, no, no. We're going to teach you to implement sorting algorithms. Cool. When am I going to do this in the real world? Oh, you'd be insane to do it. You just import the sorting library. It's just like things like this that are important. Don't get me wrong. They teach the fundamentals of how computer languages work, but it feels very akin to my experience going through the school system where we spent years and years and years beating English literature to death to try and extract meaning. There's no way the author originally intended it to have in the classics.

But they never bothered to do things like, oh, so here are taxes and here's how you file them. Here's the baseline stuff that you need to exist as an adult in the world. And the argument was always on some level that, well, you have to understand that how to actually do things is much more of a vocational study, and we are not that. Stanford is one of the preeminent universities in the world, is basically evident by the fact that it's name-checked everywhere you go. It is clear that Stanford is not what someone would call a vocational, a vo-tech type of school. How did, how does approaching it from this perspective happen at a university? Totally. So I think what you said about the fundamentals and how you're

taught, you know, 20 some odd years ago is I think still actually a perennial complaint. If you go on r slash CS majors on Reddit any given day, you'll actually see the same exact complaint these days as well. You'll primarily see people worried about the job market and lead code, but you'll also see people worried about how their CS program doesn't teach meaningful practical skills. An example that blew up on Twitter last month actually was somebody talking about going to a hackathon and realizing that they didn't know anything at all required to make an app in a hackathon. And in particular, I think they complained about, I don't know how to set up a database on RDS. And I don't know what an environment variable is.

So I think this is really a common complaint at most ES programs at most universities. And Stanford, of course, being Stanford, is a generally foundational program. I actually think still it does a lot better than most universities when it comes to teaching actual practical skills within the context of foundations. For example, our parallel computing class teaches you how to use CUDA to program on NVIDIA GPUs, for example. And so I think teaching the foundations in that sense is a great thing. You don't want to teach the latest fad of the day. And you want to teach skills

that sort of meaningfully transfer with regards to whatever the latest tech stack and paradigm is, and sort of teach students how to think about what the latest is. And yet, I still think that, you know, there's a place for teaching people how to actually apply those fundamentals, which is kind of what I focus on here. Stanford, the program is really geared towards, you know, making people come out as,

you know, good, solid engineers, especially if you take some of the more practically oriented tracks within the CS major. But I think there's a little bit of a gap still when it comes to how do I actually use these ideas within the context of industry, or even within the context of academic research. I mean, cloud specifically, if you're a new lab at Stanford, you're probably using the cloud to get your GPUs to do compute for ML research while waiting for your own hardware to arrive. Well, yes, unless you happen to have like a sack of gold bars in your backyard

that you could dig up and wind up using to pay for them. This pattern emerges, I wish I could say this pattern stops at the college level, but it doesn't. So often, even today, you'll see software engineering interviews where the entirety of the interview is based on algorithmic exploration and, let's be honest, trivia. And then, great, so now I've got the job. What do I do?

Oh, you're going to move this pixel a little bit over on the web page, and that's about it. It's a, like, I'll never forget the, I guess, hazing experiences I had the two times I went through the Google interviews, where they'll sit there and they'll beat you up on these deep dive things as if they're trying to prove that they're smarter. So what would you do in this scenario? Like, well, I would Google it. Ah, assume that Google is down. How would you fix it? It's, well, hypothetically, if I'm working there, and there was actually an outage where google.com wasn't working, I wouldn't be allowed within 100 miles of the problem because you're going to have some of the literal best in the world getting it back the hell up immediately.

And it turns out they don't really like those real-world answers nearly as much as you think they would. And that is the challenge we run into, but we find that it biases in many ways for folks who, A, have a formal education in the space, and B, have had so recently enough that it's still top of mind. I can't recite off the top of my head things that I picked up in school 20 years ago.

I have to do a deep dive series of refreshes on that. And let me face it, interviews are not exactly stress-free situations. So it's nice to see that there's at least an emphasis in some ways on preparing students for the reality of what they would encounter. Something else that you've been doing for a while is getting fairly deep into the security space. You got first place in a

national cyber defense competition last year and second place in a global pen testing competition this year. And it's, oh, wow, someone who actually starts off in security rather than trying to bolt it out at the end, like the entire rest of the industry, particularly Microsoft, seem to be doing. Yeah, I think my actually approach into cloud infrastructure came sort of as a natural evolution of my work in security. Actually, my start into the security space, believe it or not, was finding a vuln in an app used by the majority of Stanford students. This is an app called Biz, which is functionally Yik Yak. It's basically an app that's like, Imagine loading up your app and it looks like Reddit where people are posting various things.

You can upload down with them. But you can post and change your pseudonym per post such that nobody's supposed to know who you are based on a post. And you can't theoretically tie posts together. So this kind of anonymity gives people free reign to post the most deranged things on the app, things that people don't want their real name associated with. And of course, they're using Firebase and didn't have any security rules in their Firebase. So that was more or less the first of all I found.

I reported it. They made some attempt at fixing it. I think they may have fixed it. And then they sent me a lawsuit threat demanding that we sign an NDA within five days over Thanksgiving break. Otherwise, they would sue us or press criminal charges after 20 years in prison.

Yeah, going after Stanford students for that, that's going to win friends and influence people. The fact that you're telling me this story, I assume you did not sign the NDA. Yeah, so these are my classmates, actually. These are people in my year who then dropped out to work full time on this story. I assume you did not sign the NDA. Yeah, so these are my classmates, actually. These are people in my year who then dropped out to work full-time on this app. And we were, you know, thanks to, you know, the connections that Stanford can get you, we were actually able to get in touch with the EFF, who, you know, represented us pro bono, sent back a letter that kind of dismissed

any merit from those claims. And it was also kind of told the attorney, you can't condition, you know, pressing criminal charges on the resolution of an NDA or not. That's like against California Attorney Code. That is called extortion. Yeah. So our lawyers at EFF were able to send that letter back and that kind of put an end to that legal situation. But it only took about, it took another year to actually have that situation come to light publicly. There's a lot of that that happens in the corporate world as well. But I think one of the things that surprises people once they encounter that for the first time is that almost anyone can send a mean letter. And for a little bit of money, you can have an attorney put it on their letterhead for you. That doesn't necessarily

give it merit. There's currently an ongoing cease and desist threat, for example, of someone who, some group who wound up putting up an F the LAPD t-shirt out there. It looks like the Lakers logo, and you'd think the Lakers would have an argument here, but no, it's the LAPD. One of their foundations says that they own the trademark to that and sent a cease and desist. And the entirety of the legal response that an IP lawyer wrote was back was, dear sir, lol, no. Sincerely, the end. It's great.

It's like, that is not how this works. That's not how any of this works. But yeah, why bother to give the other side's lawyers a continuing legal education? Like, no, no, no. You can do your own job at some point. Now, the counterpoint is, since anyone can sue anyone for anything, it's, okay, I know that I'm right. Do I have 100 grand in legal fees lying around to prove the point? Yeah, we were very lucky that we were actually able to get the EFF to help out pro bono. I think without that, it would have been a very, very different story

here. And maybe like my current career within the security space would have not actually happened that way. But with sort of motivated from that experience, I kind of decided to just keep pursuing that. Stanford is a great place to learn about security because everybody starts a startup at some point and the various different types of tech stacks and vulnerability you see are a great fodder to learn about finding vulnerabilities.

So, you know, learned a lot that way and sort of at some point formalized my efforts. And so I run this thing called the Stanford Security Clinic now, where we every week intake a startup and, you know, do some threat modeling with them and then like spend two hours actually trying to retrain their app and report all the vulnerabilities within the context of this two-hour session. But yeah, so that was kind of my initial work. And at some point, I took on some security-focused

internships and software engineering internships at security-focused companies, which is where I learned initially about using the cloud. I think, especially when you intern at startups and sort of scale-ups, medium-sized tech companies, you're kind of expected to own some part of the deployment process or at least touch their cloud deployment in some way. And especially at smaller startups where you might even be responsible for deploying the one API you wrote entirely. That is kind of how I learned those skills and became more interested in this space. Tired of big black boxes when it comes to

cloud security? I mean, I used to work at a big black rock and decided I was tired of having a traditional job, so now I do this instead. But with Prowler, you're not just using a tool, you're joining a movement. A movement that stands for open, flexible, and transparent cloud security across AWS, Azure, GCP, and Kubernetes. Thank you. opaque, complicated security solutions, it's time to try Prowler. No gatekeepers, just open security.

Dive deeper at prowler.com. You have an internship coming up, I believe next month, that is very aligned with this. You're going to be at Cloudflare, where at some point, great, okay, where do you go next? Working at one of the cloud providers for a bit

to see how that side works. They're, let's be clear, also very most, they are most definitely a security company, whether you want to think of them in that context or not. And they're also very much a cloud provider. That is what they do. And frankly, not to wind up starting a war with some of my listeners, but I'm sure I will be, they treat their employees better than most of the other cloud providers that I'm aware of, especially lately. So yeah, that is not a bad direction to go in at all. Totally. I'm very excited for my internship. Matthew Prince, the CEO and founder of Cloudflare

has been on this show twice now. And every time I feel like I come away having learned something I didn't expect to by the end of the conversation. Every time I deal with folks over at Cloudflare, I do come away impressed by their technical acumen. For sure. And he's actually doing a talk again at Stanford next week. So I'll definitely be going to that. I think that there's a lot of neat things that get dragged into Stanford's orbit. Like me. I've never given a lecture to a technical class in that sense.

I mean, I've done LAMP stack courses at boot camps and nonprofits in the space. Sure. But the actual bona fide university, the only thing I've done similar to that has been a friend of mine, Anna Wisniewski, is a corporate crisis comms instructor at the University of Washington. And I've generally come in once a semester or so to serve as a cautionary tale of, hi, I put the crisis in crisis comms.

But that's a very different thing. With CS40, I got to basically shoot my mouth off for an hour, give or take, real rarity that, and talk about the fun aspects of cloud billing. Because my big question when I heard what you were doing was, oh, okay, so you're setting up cloud accounts for a bunch of students. Great. Are they putting their credit cards into this thing? Because that sounds like just child abuse with extra steps. How are you? How do you go down that path? And I'm curious to know, how did you wind up structuring the cloud account structures for these folks? Because I didn't hear any stories about any of these students having to sell the house and mortgage the dog in order to be able to afford the cloud bill,

because oops, that pesky managed net gateway snuck in again. And actually, I think one of the nice things about teaching your own courses, you can put whatever you want in the lecture slides. So you had your tweet screenshot about, I think, the transmission of a sperm through a NAT gateway in one of the lecture slides. Yes, yeah, the bandwidth calculation, because a sperm contains something like, what, 37 and a half megabytes of data. The typical ejaculation has X sperm in it. Great. So if you were to ejaculate through a NAT gateway, it would cost something like, what was it? Thousands of dollars. I forget the exact order of magnitude, but disturbingly expensive. Significant. Yeah. It would be significant money. Yes. Not to mention,

I'm certain that would lead to criminal charges and probably inclusion on a registry somewhere. Yes. But the accounts are restructured. So students would just essentially make their own accounts. And then we actually built this tool to distribute the credits we'd gotten. So actually our primary advisor for the courses was Mike Abbott, who kind of knows everyone up and down the valley. And so he was actually able to get us in touch

with some people at AWS who were able to give us $200 of credit per student course. So AWS gave us this big Excel spreadsheet of a bunch of codes for $200 each. And of course, we didn't want to email these codes out because of the inherent unreliability of email. So we actually built this tool actually based on Cloudflare's DevStack pages in KV that, you know, you log into with your Stanford email and it'll fetch your code from the KV and give that to you.

So like students would enter their like $200 credit code in their AWS account and have $200 to play with for the duration of the course. That is such an insightful way of doing it. I would also, to be clear, it's not completely lost on me that, oh yeah, we got codes for our students to use because we know someone who's hyper-connected and knows people at AWS super well. The fact that that's what it takes to get credits like that, to learn their platform,

is still ridiculous to me. I think Apple got it right many decades ago by giving significant deep discounts to educational institutions. Because what do people want to use in the workplace? Well, I don't know, professor, maybe the thing that they used in school and are already conversant with. And I'm stunned that the cloud providers are not individually falling all over themselves

backwards to wind up, oh, you're a student at this. Tell you what, up to some ridiculously high limit, everything you do here is free. But there's no mechanism for that. None of the providers do it. And I guess I understand why, but it just feels like it is short-term thinking rather than trying to figure out, okay, when these people go and they build

what are potentially the next S&P Global 500 components, what cloud provider are they going to pick? Well, they're going to look like a bunch of random students in many cases doing something in their part-time or in a garage somewhere? Well, they're going to look like a bunch of random students in many cases doing something in their part time or in a garage somewhere. The provider they're going to be on is the one they start on in most cases. The crazy thing here is that actually AWS used to have a credit distribution program for education until about a year, year and a half ago.

And somehow in the last year or so, they've gutted it. So that's kind of why we had to sort of back channel our way for these credits. It used to be the case that you can just fill out some form if you're a class and get credits that way. That doesn't exist anymore. We've seen this happen at Stanford, where the vast majority of classes that gave credits to students in 2022 and before would hand out AWS credits. When I took parallel computing in fall 2022, I got, I think, $50 to $100 of AWS credits to play with that because I needed to buy GPU EC2 instances. These days, it's all GCP. Most of the classes that need cloud credits are now distributing credits from GCP because I think

they have actually retained their educational program. We just wanted to use AWS because that's what we were most familiar with. And that seems to be the kind of industry standard in some sense, the most popular platform. And the one that actually has sort of assurances of, yes, this product will stay around in the next five, 10 years. There is some value to that, to be sure. One question I do have for you, though, is I was not much of an academic. I failed out of college pretty early on after getting expelled from two boarding schools. But it turns out that I do, in fact, have an eighth grade education and no one can take that away from me. But it's a so when I remember going

through academia, maybe this is just how it works. It was a constant source of learning new things. And I feel like, oh, there's a new concept I haven't been exposed to before. And that was the good kind of learning. But then you have a different kind of learning that I think of as bad developer experience or bad user experience. And AWS and all providers are generally crawling with this stuff. And it manifests in such a way

that when you encounter it, your response is not immediately an instinctive, this product sucks. It's a, oh, I'm dumb. I don't quite understand what it's getting at and how. And that's insidious. And it makes you feel less than. And that's why I've started my crusade of against, you know, you're not, it doesn't, it isn't going to kill you as a company to invest a little bit more in making your documentation understandable. How about every week you want to bring it in someone for a focus group and just tell them

to do a task that you think is really easy, but they've never used your tool before? Oh, they struggle with it and go in weird directions? How about that? Because I find myself doing that all the time. And my instinctive reaction intrinsically is, oh, I must be a moron. Why don't people remind me of this more often? And then it's, no, I'm not. There are times that I'm profoundly dumb, but I am rarely the dumbest person in the

world when it comes to a target customer model. I'm not, there are times that I'm profoundly dumb, but I am rarely the dumbest person in the world when it comes to a target customer model. So yeah, this is just bad and they need to fix this. How do you find students who do not have a basis of experience to compare that to, how do you make sure that they don't internalize that dealing with cloud providers is going to be,

is going to, no, no, this is some really sharp edges and it's not you. I think students saw some of these sharp edges firsthand in their deployments. So the big focus of CS40 was using infrastructure as code tools to deploy applications to the cloud. And the one we use primarily for CS40 is CDK, because this year we didn't really want to spend the time on having students learn new language syntax, so we used CDK and Python. Of course, CDK being a leaky abstraction around CloudFormation means that CDK also inherits all of CloudFormation's bad ideas

about state management, a.k.a. if you're deploying to ECS, if you're deploying some container image to ECS and then mess that up, CloudFormation actually assumes that a container deploy that fails is its fault. And so it keeps trying to restart and drain the container, I think, five times before it finally fails. That means if you mess up a typo in an environment variable and your Python process within the container now doesn't know how to connect to Aurora, then it's just going to crash. And then, you know, CloudFormation is going to attempt to start and drain and start and drain and start and drain and start and drain the container five times. It takes about an hour

until it finally fails. And if you're not, if you don't know exactly how to debug that, you're just kind of sitting there for an hour hour looking at something that looks like a slow success only for it to finally fail. And that was something I had to like really help out with Office Hours. Oh God, I have a, I have a, oh not open source, but a freely available project, Last Toot in AWS.com. It's a threading Mastodon client.

And it's deployed to every AWS region that has the necessary resources to support it. But how do I do a deployment to every region? Well, I do a matrix job in GitHub Actions because it's great. And I wound up having to use, I have a state machine that winds up building the individual deployers, one per region, in Lambda functions, just as a container for the build process. And the dangerous part is, though, is that this is done within the CDK, which of course means it's using CloudFormation.

And Lambdas have a 15-minute hard limit on how long they can run for, which means that what can you get done in 15 minutes? Well, usually a lot, but not if you're CloudFormation. Oh, good Lord. I'm still putting my boots on after getting out of bed at that time. It is quick. It is not. And I didn't used to have this big of a problem with it until I recently started doing some work with Terraform. And it's like, wait, it's done already? How is this even

possible? It's like, well, we actually thought that instead of biasing for putting the eventual and eventual consistency, we just go ahead and do the thing you want to do. Like that makes perfect sense. So yeah, that, that was a, that was a painful challenge, especially when you've like this slow iterative deployment, because you don't know what a linter is in my case. And every time you uh, our final lecture was entitled everything we forgot to tell you. And in that lecture, I included a, uh, photo from a couple of days before of me nearly eating shit on a bike and,

uh, entitled it POV cloud formation state management. I like that. I have to ask. It's a, it seems like it's a bit out there as a question, but everyone, uh, everyone sets out to build these things

that are gorgeous and ideal and wonderful. And the engineering trap is, oh, we're going to stop and fix it and get rid of all the technical debt. It's like, how about you find product market fit first? Because lots of companies have died because they didn't have a business model. Very few have died

because their code quality was terrible. When you make money, it turns out you can afford to invest in improving the code. but if you go the other way around, it doesn't work. So my question for you is, how cursed is the infrastructure that you doubtless had to build to manage the class? This is extremely cursed. And in particular, I think the most cursed part of this was the autograder. You know, one of the unique things about CS40, again, is the fact that we were using infrastructure as code for the deploys. I don't think any other university courses do that. And that meant like, how do you actually

autograde infrastructure as code? Because I'm not looking at 50 students worth of CDK and trying to hand grade that. That sounds like an exercise in extreme frustration. You didn't do the my old CS professor thing of making them print it out hard copy and hand it in. And it's like, great, but why don't, why can't they just submit it digitally? It's like, because I couldn't abuse my TAs if they did that. Duh, they have to all type it in by hand. That builds character. Yeah. And so the other interesting technical challenge here was like, how do you actually cram working with CDK into an auto-gitter. And sort of the platform that most CS classes, including us, we use is Gradescope. Gradescope has this awful feature slash bug

that by default, all of the code executing in a Gradescope container runs as root, often in the same process, and the student code often runs in the same process as the grading process, which means, especially when Gradescope expects its results to be in a same process as the grading process, which means, especially when Gradescope expects its results to be in a file called results.json, if you're student code, you can just sort of overwrite results.json and then crash the autograder and now you have whatever

score you want. So that was another fact we kind of had to deal with. This was a blog post I wrote last year. And I was like, I can't be the guy who's known around campus for hacking Gradescope and then assign a vulnerable autograder. So what we decided to do, and the other limitation of Gradescope that we had to deal with was the fact that the autograder actually doesn't support environment variables, which means you can't auth to an AWS account, which you need for doing CDK synth. So instead, what we do was we take the student's CDK Python submission, we shift that to a Lambda that I wrote on AWS, and

that Lambda has read only access to the account, and then do the CDK synth within that, which means that the student code is not executing in the context of actually shipping the result to the automator, send the big CDK, send the big Cloud actually shipping the result to the automator, send the big CDK, send the big UI CloudFormation JSON back to Gradescope and then run some

open policy agent static checks on that to make sure that things were configured as assigned in the handout, one. But two, we also wanted to make sure that the website was actually live, the website that students website was actually live, the website that students deploy was actually live, which means we actually crammed an entire Selenium and Chrome instance into this Grayscope AutoGit or Docker container, had

that navigate to the student website, take a screenshot of it, and then compare it to a pre-computed perceptual hash of what the website is expected to look like. I do something very similar myself with some things with browserless or with Playwright. It's a great approach. Yeah, I actually just spent the last two days working on an auto-gator for the computer

network security class that I'm seeing. We're currently have a, we have this like web security assignment out that's like based on like XSS attacks, some SQL injection, but primarily XSS and what are the effects that you can achieve with XSS, which means, of course, you need a browser to degrade that. And so now, again, I had to go back and cram Selenium and Firefox or Playwright and Firefox into a Docker container. I am interested to see what you start doing professionally once you are done with apparently like three degrees at once, because why not?

You're just going to go through and collect them all. What's next for you? Obviously you have an internship, which is doubtless going to change your perspective on a great many things. Have you done internships before? Yeah, so I've interned previously at Verkada, Lacework, Optics, and Alchemist.

So all kind of scale up, scale companies and all cloud native. So Cloudflare would be interesting in that it's like the first like larger company I'll be working at, even though it's like not that big in comparison to say like Amazon or Google or so. I'm still at a point where I view any company as being huge if they have more than 200 employees,

which is not really a great framework for thinking about it. So you already have learned the most valuable lessons, I think, of internships, which is, wait, these companies, this company I'm at is incredibly dysfunctional because spoiler, that's every company out there. It feels like many of these places succeed

in spite of themselves, not because of them. But so much of it is also built on just workplace norms and figuring out what is something that normal people do in a workplace versus something normal people at this company do in the workplace versus nope, Steven's just really weird and we can't wait for the day that he's fired. Having been Steven many times, I certainly understand that perspective. For sure. So after Cloudflare, I'll be around again at Stanford to complete my master's and planning to teach CS40 again. We actually have this sort of five-page document worth of notes

for things to change next year. And top of that is changing CED data terraform because we want better safe management. So definitely excited to teach again next year. And then beyond that, not super sure. Currently looking at maybe joining startups after I graduate,

given that sort of, I think the skills that I have versus most CS graduates involve like setting up new projects from scratch, dealing with my own ops and troubleshooting those failures, and of course, deploying cloud infrastructure and security. And I think sort of wanting to exercise those skills in the future, I think startups lend themselves well to that. And sort of being able to be generalist focusing somewhat on infrastructure and security would be nice. I think your career is going to be fascinating. And I feel like I should just go ahead and book a couple more of these episodes with you now, just because I don't know what you're going to

be doing in a year and a half, but I guarantee it's going to be a great story to tell. I really want to thank you for taking the time to speak with me about what you're up to. And of course, inviting me to inflict my sense of humor on your students. If people want to learn more and follow what are doubtless going to be your continuing adventures, where's the best place for them to find you? The Twitter handle is sologramma underscore A. I post some stuff there. I have a blog at sologramma.io slash blog. And hopefully you can put that in the doc description as well. Primarily those are where I'm posting.

So excellent. We will, of course, put links to that in the show notes. Thank you so much for taking the time to speak with me. I really appreciate it. Perfect. Thank you so much.

Aditya Salagrama is several kinds of student as well as the instructor of CS40 and soon to be CloudFlare intern. Wow, that's a lot. That's a lot to put on a business card. I am Corey Quinn, and this is Screaming in the Cloud. If you enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment in about 10 years, because I figure that's how long it'll

take you to do anything since you presumably work on the CloudFormation team.