AWS re:Invent 2022 - Build, test, and deploy your .NET applications on AWS (XNT302)

Aug 16, 2023

AWS re:Invent 2022 - Build, test, and deploy your .NET applications on AWS (XNT302)

A benefit of moving to the cloud is the opportunity to accelerate development and deployment processes, streamlining and automating release processes. In this session, learn how to use .NET with AWS DevOps services, as well as other popular third-party DevOps tools, CI/CD best practices, and test automation strategies. Leave this session with the knowledge you need to build, test, and deploy .NET code on AWS.

Learn more about AWS re:Invent at https://go.aws/3ikK4dD.

Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4

ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.

AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

#reInvent2022 #AWSreInvent2022 #AWSEvents

Content

0.21 -> - Hello, and welcome everyone.

2.55 -> We appreciate you, all of you taking time and

4.74 -> joining us today for XNT302:

9.24 -> build, test, and deploy your .NET applications on AWS.

13.32 -> For those of you who are trying watch this later on demand,

15.69 -> we want to welcome you as well.

17.52 -> I'm Jagadeesh Chitikesi, I'm a senior

19.32 -> Microsoft specialist architect at AWS.

22.53 -> Also joined by my colleague Dror Helper,

24.66 -> who will be presenting later in the presentation.

26.58 -> He's a, he's a fellow senior Microsoft specialist

29.04 -> solutions architect on AWS as well.

31.59 -> We work with customers like you to help them

33.72 -> migrate and modernize .NET applications on AWS.

37.328 -> Right, let's get started.

41.748 -> I wanna walk everyone through a,

42.943 -> a fairly typical scenario that we see in

45.12 -> greenfield projects, right?

46.68 -> So these are brand new, start from scratch projects.

49.95 -> So you usually don't have the constraints,

52.02 -> the business constraints or the constraints post

54.06 -> for the existing code, typic-that you generally see

57.63 -> in a brownfield or an existing project, right?

59.263 -> So as .NET developers, it's very exciting.

61.74 -> You don't get a lot of chances to work on, on such projects.

66.36 -> The biggest advantage when you're doing that,

68.55 -> when you're working with a greenfield project,

70.2 -> you have a well-defined scope as a starting point.

73.71 -> Now you take that scope and then you build your

75.6 -> rockstar team of .NET developers, software architects,

79.14 -> project managers, HI team,

81.06 -> and you start taking a crack at the project,

83.13 -> right, or the product.

84 -> You start developing all the features incrementally

87.06 -> until you reach the finish line.

91.38 -> And then assuming you did all the right things,

93.96 -> you hit the day of the launch,

95.31 -> it's time to show the world what you built

97.23 -> or also pray that nothing breaks, right?

99.99 -> It happens.

103.44 -> The next thing is far from guaranteed,

105.75 -> but assuming that you had the right product idea

109.92 -> and you've executed really well,

113.04 -> you will end up seeing that your customers

115.38 -> actually like your project.

117.57 -> That's a happy ending, but it's not

118.453 -> the end of the story, right? Is it?

120.9 -> So I've worked in IT for over 20 years.

123.33 -> I can confidently say that's not,

124.98 -> that's not the end of the story, right?

127.32 -> So as customers adopt your product more,

130.54 -> they, they would have feedback, they would,

133.26 -> they would tell you the good, the bad,

135.09 -> the ugly of the project, right?

137.07 -> So if you are customer-obsessed like we are at Amazon,

140.25 -> what you want to do is gather all of that feedback,

142.68 -> document it, analyze it, and then

145.59 -> let that dictate your product roadmap.

148.17 -> So use that to build your product backlog.

152.85 -> But now you're not operating off of a

155.52 -> well-defined scope anymore, right?

157.44 -> So you have multiple priorities

158.85 -> for your development team, right?

161.07 -> You still have a list of features

162.3 -> that you want to develop, right?

164.07 -> So you still, there are bugs being reported

167.61 -> by the customers that, that needs to be fixed.

170.67 -> As with any project you constantly work on

173.37 -> application performance, security enhancements.

176.82 -> Also, remember this is we're talking in,

178.413 -> in a context, context of .NET world.

180.09 -> So there's a new version of .NET

181.86 -> that's released by Microsoft every year,

184.14 -> and then it's not uncommon for a lot of our customers

187.02 -> to spend or to allocate some dev cycles to make sure that

189.713 -> they're refactoring their .NET applications

191.85 -> to the latest version every year.

192.96 -> So that's, that takes some time as well.

198.12 -> So if you're not prepared enough

201.12 -> with this change in focus and priorities,

205.2 -> it's natural that you see a decline

206.94 -> in your team's productivity, right?

208.65 -> So not enough features being developed,

211.74 -> code quality might go down, could freeze Windows,

215.1 -> increase before release, missed deadlines.

217.65 -> Eventually, your developers may feel the burnout,

222.03 -> which may eventually lead to one thing

223.77 -> that no one wants, right?

225.15 -> Unhappy customers.

228.6 -> - [Dror] Right, and the solution is to add more developers

231.87 -> because that's the simplest thing we can do, right?

234.45 -> - [Audience Member] Yes.

236.344 -> - It's, it's,

237.42 -> it's very natural for a lot of project managers that,

240.09 -> especially also customers that I work with,

241.8 -> to think that adding more developers would solve the issue,

244.92 -> definitely not the first thing that you may want to try,

247.56 -> right?

248.393 -> So I want to bring up something, that,

253.41 -> quotation from a book from Fred Brooks,

255.817 -> "The Mythical Man-Month" from 1975.

258.88 -> Now, you wouldn't expect a 47-year-old book

261.36 -> to still be relevant to this day,

262.68 -> but a lot of things that Fred Brooks said and practiced

266.25 -> in his career are still resonated with a lot of

269.07 -> software creators and designers today, right?

271.53 -> So Fred Brooks notes that adding manpower

274.17 -> to a late software project makes it later, right?

276.6 -> So imagine a team of 10 is tasked to

279.247 -> deliver a software project in an year.

282.24 -> Would a team of 20 be able to deliver it

284.04 -> within half an year?

285.63 -> I mean, this,

286.463 -> this probably works for projects that scale linearly,

288.99 -> but it wouldn't apply for software development, right?

291.42 -> So I mean, don't get me wrong,

294.39 -> there are plenty of situations where adding more developers

297.24 -> to your team is the right solution, is the right way to go,

300.15 -> but your, your focus should always be

303.27 -> trying to achieve more with less

305.55 -> with the modern tools and processes, right?

308.19 -> So more innovation, more speed, more security,

311.22 -> more agility with less cost, less resources, less time,

315.04 -> less errors, and so on.

319.53 -> So it's easy for me to say, right? (laughs)

323.01 -> But yeah, it's, it's easier said than done.

325.05 -> No doubt there's a little bit of work involved, right?

328.59 -> But there could be other things,

330.27 -> but we fundamentally believe that if we take

332.94 -> all the undifferentiated work from your team, right,

335.58 -> and focus on activities that provide value

338.64 -> to your end customer, combine that with the fact that

342.06 -> there's a, there's a, there's a mechanism

343.89 -> to provide faster feedback loop to your developers, right?

348.03 -> So when things break and you know, let's accept it,

351.18 -> things break all the time.

352.44 -> So just know, make sure the, the right,

354.979 -> with the right metrics and data goes to the developers

357.87 -> to make sure that they, they could go in,

359.88 -> fix things quickly.

361.83 -> So fundamentally we believe if we,

363.24 -> if we are able to achieve these two things,

365.16 -> it'll improve your, your time to market

367.11 -> and also your core quality ultimately.

371.04 -> So this is where CICD comes in.

372.93 -> I do not want to define CICD.

375.42 -> I'm more than sure that all of you know what CICD is.

378.69 -> So yeah, these kind of practices

380.79 -> help your developers to commit more frequently,

384.54 -> catch errors more quickly,

386.25 -> deploy to production more frequently,

388.74 -> and also adopt automation at different stages, right?

391.11 -> So there are different stages in, in the process.

395.58 -> The focus of this presentation is going to be on

398.04 -> source build test, test and deploy.

400.32 -> As, as you all know,

401.16 -> there are other stages like security that is,

403.02 -> that are supremely important,

404.73 -> but the focus of this presentation is, is just gonna be on,

408.12 -> on the stage, on the stages that you see on the screen.

412.38 -> So the rest of this presentation,

413.61 -> what we are going to do is share best practices

415.8 -> along with the right tooling that you could use at,

418.04 -> at these stages to, to improve your team's productivity.

422.19 -> Also, remember this is, this is not a one-time thing.

424.83 -> You probably all of you saw the infinity symbol

426.49 -> that, that CICD uses.

428.82 -> So you you are expected to use these stages or you know,

433.26 -> follow this process throughout your development life cycle.

439.44 -> So but first I want to,

440.85 -> I want to show some market research, right?

442.95 -> So what, what are some of the high-performing companies

445.68 -> from around the world are able to achieve

447.6 -> by basically using these practices?

451.92 -> It'll also tell you why you should invest your time

454.05 -> and your, your team's time into this.

455.55 -> So first one is these companies are able to bring down

459.03 -> the deployment frequency to basically on-demand, right?

461.73 -> So which could translate to multiple

463.77 -> production deployments a day.

466.5 -> Also, you know, you don't have to schedule like,

468.81 -> midnight releases where operations and developers

471.36 -> come together and then just hope

473.25 -> they get to go back home by 1:00 AM, right?

477.48 -> The lead time for changes,

478.77 -> which is a metric that that's calculated by

481.59 -> looking at the time from a code committed to

484.32 -> code successfully deployed to production

486.21 -> is less than one hour.

489.06 -> Time to restore service that is undergoing an

491.7 -> unplanned outage is again, less than an hour,

496.92 -> a production deployment that ended up in service degradation

500.67 -> is less than 15%.

502.53 -> So it's incredible, isn't it?

503.85 -> So what some of these high-performing companies

505.71 -> are able to achieve using, using these CICD practices.

510.9 -> Right, so let's look at some of the practices

512.7 -> at each of these stages

514.41 -> that that'll help you get there, right?

516.06 -> So, also remember it's a combination of using

519.03 -> the best practices and also the right tooling

521.1 -> that applies for your team.

523.26 -> So let's start with the .NET code.

525.27 -> What can you do at your .NET code?

526.71 -> There, there are several things like traditionally

528.39 -> developers not used to committing code frequently,

530.76 -> they would wait days, weeks,

532.38 -> until they finish working on a feature.

534.6 -> Get, get into the habit of

535.8 -> committing code more frequently, right?

537.57 -> So it also helps in identifying issues early.

541.14 -> How good code do we structure in place?

542.82 -> Now there could be developers that are very positive about

545.34 -> their code and may not take feedback in the right way,

548.07 -> but this is proven to help your teams get better over time.

552.54 -> Learn from each other.

554.441 -> Run unit tests before you commit your code,

556.68 -> have gated check-ins before you try to merge your code,

561.12 -> not affect every other developers on the team.

563.73 -> Also have right notifications for visibility,

565.77 -> so everybody on the team knows what's going on.

569.13 -> It's also important to use the right tooling, right?

571.29 -> So there are tools and SDKs AWS provides,

574.41 -> even you're developing .NET code against AWS services.

578.07 -> So we have toolkits that plug into your ID directly.

582.3 -> You're seeing familiar ideas, Visual Studio,

584.34 -> Visual Studio Code, and JetBrains Rider.

586.74 -> These toolkits help you develop, interact with your

590.13 -> AWS account without having to leave your IDs.

592.68 -> We also provide programmable SDKs,

595.05 -> software development kits,

596.67 -> that help you program against AWS services, right?

599.76 -> So this, this helps you.

601.71 -> They, they abstract away a lot of lines of code

605.13 -> when you're interacting with AWS services

606.99 -> and they're available for both .NET

609.06 -> as well as the older .NET framework.

613.17 -> Once you have your code,

614.37 -> you want to push it somewhere to collaborate

616.105 -> with your wider team.

617.28 -> So that's where AWS CodeCommit comes in.

619.17 -> It's a, it's a managed source control repo that helps you,

623.635 -> you know, provide managed good depositories, push your code,

627.21 -> collaborate with a wider team.

629.436 -> It's also important when you're talking about code

632.22 -> to be able to use reusable constructs in your code.

634.83 -> So these are typically nugget packages that you want to

637.44 -> build, publish, either internally or if you have,

641.31 -> if you have customers who use nugget packages

643.59 -> that you build, can also push them externally.

646.35 -> So AWS CodeArtifact is a completely managed service

649.875 -> and secure service there that help you deploy

652.92 -> and publish your nugget packages of your .NET code.

657.21 -> So to talk about build and deploy,

658.86 -> I want to hand it over to Dror, but also just curious,

661.47 -> why do we want to talk about build and deploy together

663.9 -> and talk about test later?

665.64 -> - Right, because build and deploy are

667.53 -> tightly coupled together,

668.97 -> you can't have one without the other.

670.77 -> This is the backbone of your entire development lifecycle

675.39 -> and with the proper build and deploys in place,

678.738 -> automatic build and deploy,

680.22 -> you can reduce the overhead for your developers,

682.89 -> they can focus on writing code and not on

685.44 -> packaging systems and deploying to multiple environments

688.5 -> and you also get that time shorter.

690.6 -> And in order to have an effective build and deploy process,

694.59 -> you need to follow three rules.

696.42 -> First of which is, every commit triggers a build.

699.96 -> You don't want a daily build,

701.07 -> you don't want to wait till four tomorrow morning

702.9 -> to find out if what you just wrote works.

705.9 -> You want it to be built and deployed and then pushed.

709.14 -> And if something bad happens, that's perfectly fine.

711.75 -> You want to know immediately and then you want to fix it

715.03 -> as soon as possible because you don't want to wait

718.08 -> to find out that you have a problem

720.45 -> and more people committed more and more code,

722.37 -> and as time progressed they lose trust in your build system.

726.42 -> So you want to fix everything as soon as possible.

729.48 -> It will increase your team's confidence and make the build

731.68 -> more effective and also show that you care about your

734.7 -> coworkers and don't waste their time.

737.31 -> And finally, you want to frequently commit

739.92 -> as much as you can.

740.753 -> Whenever you have new feature added

744.21 -> or a part of a feature added,

745.8 -> and you haven't broken anything, or that's fine,

748.56 -> why not commit it?

749.49 -> Why not say build, merge it back into your code.

751.89 -> Don't wait to the end of the month for

753.33 -> even the end of the day because then

755.46 -> you'll have very painful merges and if you have a problem,

759.69 -> it's harder to track it down

761.4 -> with a lot of changes on top of it.

764.19 -> Now in .NET with build and deploy,

766.35 -> it depends on two major things:

768.48 -> what .NET random are we using and what we want to deploy?

772.17 -> Two, what's our target?

774 -> So with .NET framework, which is still being used,

777.06 -> we are running on Windows,

778.35 -> which means that we need to build our everything

781.05 -> and run our tests on a, build it on a Windows machine.

784.44 -> And while with .NET or .NET core reviews and older version,

789.03 -> then we can use the multi-platform lecturing run

792.18 -> on a Linux machine because probably you are already using

795.18 -> Docker there and you want to build it on a Linux machine.

798.6 -> Deployment in AWS with for .NET can come in

801.93 -> many shapes and sizes.

803.85 -> You can deploy to virtual machines.

806.25 -> Those virtual machines can run on EC2,

808.2 -> elastic computing cloud, virtual machines that can run

811.86 -> your .NET code or you can use AWS Elastic Beanstalk,

815.73 -> which is a solution, a minute solution

818.37 -> that help you operate, deploy,

820.08 -> and run website on top of AWS.

823.68 -> So you don't need to worry about running IIS

825.81 -> and using Word Deploy.

827.56 -> Or you can go containers because

829.11 -> that's what everybody does, right?

831.24 -> And with containers we have ECS, Elastic Container Service,

834.9 -> and EKS, Elastic Kubernetes Service,

837.18 -> where we can host our Dockerized application,

839.88 -> or you can use AWS App Runner that enable you to

843.162 -> run and deploy and scale containers where,

846.6 -> without needing any prior infrastructure or

850.17 -> container docker knowledge.

852.48 -> And the last option is, right? Lambda.

855.87 -> We can go full serverless,

857.08 -> run a code without worrying about

858.75 -> the underlying infrastructure,

860.61 -> get automatic scaling without needing to worry about it.

864.36 -> Depending on our .NET random of choice,

867.33 -> or not choice, forced,

870.09 -> we can get to choose some of them

872.34 -> because if we using the Window-based .NET framework

875.37 -> then we can use either virtual machines

877.71 -> or Windows containers running on top of ECS and EKS

880.95 -> that has Windows container support.

883.212 -> Windows containers, if you don't know,

884.994 -> are similar to Linux containers.

887.67 -> They are bigger, take more time to load,

889.65 -> but you still get deployment benefits,

891.96 -> scaling benefits, and orchestration benefits out of them.

895.74 -> But if you use .NET, the new version,

899.25 -> you know, 5, 6, 7, or even prior 3.1,

903.72 -> then you can use every single of those options

906.87 -> and it's up to you to decide according to

908.91 -> your project needs, your preferences,

911.25 -> and your underlying architecture.

914.58 -> Okay, so what does a build deploy look like?

919.83 -> A very common scenario we tend to see

921.54 -> with .NET shops is deploying to IIS.

924.352 -> We have an application, a web application,

925.95 -> a service runs on top of IIS.

928.32 -> So the deployment power pipeline should look

930.48 -> something like this.

932.73 -> We pull everything out of the source control

935.79 -> triggered by a code change, then ran nugget restore,

939.99 -> and build depending on which .NET we have,

944.1 -> and run our tests, we'll get there,

946.98 -> and then we package and deploy.

949.05 -> And those two depends on our target.

951.54 -> If for example, want to deploy to IIS

953.783 -> running on top of EC2 systems,

956.73 -> then package and deploy are probably publishing your website

960.12 -> either directly to IIS or publishing to a package

963.72 -> and then using web deploy to publish it to your website.

967.53 -> On the other hand,

968.363 -> if using Elastic Beanstalk slightly different,

970.92 -> we create a zip file and use AWS API nodule

974.16 -> to upload it to Elastic Beanstalk.

977.88 -> The second most common case is using

980.82 -> a containerized application,

982.17 -> either Windows or Linux containers.

984.18 -> And it starts the same because in the end of the day

986.28 -> it's .NET code.

987.54 -> You still have need to compile it

989.49 -> and build it and run tests,

991.26 -> but then we get to build Docker,

993.69 -> we get a Docker image out of it

996.09 -> and probably want to scan it for non-vulnerabilities.

998.91 -> There are tools that you can install on your build agent

1001.55 -> or run a service third-party.

1003.86 -> You can also upload it to ECR,

1006.29 -> where it can be scanned as well.

1008.09 -> ECR is Elastic Container Registry.

1012.05 -> That's where we store the Docker images and then we need to

1014.99 -> update our cluster in order to use the new container image.

1020.244 -> Now 99% of the workload will fall under those two categories

1025.1 -> and probably the rest will be Lambda.

1027.02 -> So we always have very similar build pipelines

1030.29 -> when we handle .NET, at least it has some variety,

1034.13 -> but usually those steps.

1037.19 -> Which bring us to the tools,

1039.35 -> because unfortunately we can't run build on PowerPoint

1043.37 -> and we have several options in AWS.

1045.86 -> First of all, we have the native AWS tools supporting .NET,

1049.334 -> code pipeline, code build, code deploy.

1051.95 -> All of those are fully managed.

1053.36 -> You don't need to worry about build agent infrastructure

1056.78 -> and you can run your workloads on top of them.

1060.17 -> Or if you're already using a build tool such as

1062.42 -> Jenkins or TeamCity or any other third-party application,

1065.84 -> you can host it on AWS.

1068.45 -> And finally, we can also use third-party services

1072.68 -> outside of AWS, Circle CI, GitLab,,

1076.04 -> according to what your organization currently using

1078.59 -> and deploy to AWS using different methods.

1082.25 -> - [Jagadeesh] It's great to have a lot of choice,

1083.587 -> but it also brings a challenge, obvious challenge about,

1086.18 -> how do you go about choosing the right tool for it?

1088.027 -> - Right. So how do you choose?

1089.51 -> There's so many options.

1092 -> First of all, according to what all you already have

1094.25 -> and what you prefer to use, obviously.

1096.77 -> But once you do choose a tool, especially with .NET,

1099.53 -> you have to make sure that you,

1101.09 -> you get at least the following capabilities.

1103.971 -> If you talking .NET and most of our .NET clients

1107.06 -> are on both .NET framework .NET call,

1108.74 -> it means we need multiple environments.

1110.81 -> With Windows, within Linux, probably several flavors.

1114.2 -> So we want a build tool that can handle running

1117.05 -> both on Windows and on Linux that can build .NET

1120.56 -> and use our tools of choice.

1123.56 -> And obviously if we need Docker as well.

1126.11 -> We want it to, our build pipeline to be in code.

1130.88 -> All modern tool have the ability to save the description

1133.82 -> of your build pipeline in a file or files

1136.073 -> that you can later on save in your source control

1139.01 -> alongside with your project.

1140.99 -> You want to do that because you want to be able to

1143.36 -> deploy your project from a month ago

1145.31 -> from time to time and build tend to change over time

1149.24 -> and you don't want to configure everything

1151.61 -> on your build tool.

1152.443 -> You want everything to come with your code.

1154.43 -> So you get versioning and you get it side by side.

1158.48 -> And, and also you want visibility, traceability,

1163.25 -> because everybody's optimistic in projects.

1166.31 -> But the reason we have a build tool is because

1168.5 -> it will fail from time to time.

1170.18 -> We want to be able to immediately know what the problem is.

1172.88 -> We want to know information about our build

1175.58 -> and what's the root cause of any failure.

1178.37 -> So whatever tool you use,

1179.99 -> make sure it can understand failures

1183.05 -> in .NET build tool and unit tests.

1186.38 -> If using N unit, X unit, MS test,

1188.33 -> those things need to show in your build tool.

1191.39 -> And finally, when you want statistics,

1194.15 -> those statistics will help you fully understand

1197.69 -> the state of your build compared to last week, last month,

1202.01 -> do we have more tests, less tests?

1203.51 -> Does the build takes more or less time?

1205.7 -> What is the average time running the build

1207.95 -> and does my coverage goes up and down over time?

1211.772 -> It's a nice to have thing,

1213.41 -> but it will be, your team will benefit from it.

1218.51 -> Yeah, so here is CodePipeline.

1223.16 -> If you've never seen CodePipeline,

1224.48 -> it's a orchestration tool that we use

1226.82 -> in order to run other AWS services like CodeBuild,

1229.04 -> CodeDeploy or even AWS Lambda.

1232.07 -> And CodePipeline is split into different stages,

1236 -> and in this case you can see it all starts with source.

1239.48 -> Just like in the build pipeline,

1241.64 -> we have your build and then update pipeline

1243.68 -> because the code pipeline itself is stored

1246.23 -> in my source control with my project.

1248.57 -> Whenever I change,

1249.8 -> it's the definition of what, what build should be.

1252.98 -> I want it to immediately, automatically be updated here.

1256.22 -> I don't want to go to the AWS console to update it.

1261.29 -> Later on here, I build two services,

1263.78 -> that's two Docker images and deploy to dev.

1267.83 -> And first I run my unit test to make sure

1270.38 -> that everything's okay,

1271.94 -> and create my infrastructure and deploy it to AWS.

1277.52 -> And this is basically two services kind of project,

1281.351 -> and it's simple as that, but it's not good enough, right?

1286.19 -> We said traceability and statistics.

1288.59 -> So with CodePipeline that fully understand the .NET tooling,

1292.76 -> we can look at what happened throughout the different runs.

1298.82 -> Well you can see how many runs we had,

1302.39 -> what's my failure rate, what number,

1304.22 -> how many reports I have, how many tests,

1306.721 -> and I can go and see the latest builds

1309.41 -> and if one of them failed, like here,

1311.42 -> I can go in and in this case,

1313.04 -> 41 tests just failed on me.

1315.59 -> So I wanted to test that and I can go into a single test

1319.61 -> and see what was the problem.

1322.43 -> Now that's AWS native tooling, which is nice,

1326.57 -> but you can also host your own, right,

1330.68 -> we can use Jenkins, TeamCity or any other

1333.23 -> build pipeline tool on AWS.

1335.36 -> But because we use AWS build tool does not mean

1339.44 -> that we don't gain anything out of running in AWS

1342.68 -> because there are a lot of benefit of running

1344.96 -> a third party application on AWS in the end of the day.

1348.2 -> Usually we have a build controller,

1350 -> this is where we control the different builds,

1351.98 -> see the statistical information,

1354.17 -> and then we have a bunch of agents that run the build.

1357.59 -> Now with AWS virtual machines,

1359.9 -> I can create a virtual machine,

1361.4 -> set up my environment on that virtual machine,

1363.68 -> create an image out of it,

1365.42 -> and then multiply the image by how many agents I want

1368.57 -> and I get a consistent duplicated environment

1371.69 -> to run all my builds on AWS.

1374.36 -> And yeah, since it's .NET, probably need Windows machines

1377.57 -> as well, so two groups.

1379.55 -> And that's nice, but usually if I'm already running in,

1382.94 -> I'm going to use AWS services,

1384.92 -> I might need to deploy to Elastic Beanstalk

1388.4 -> or I want to get information out of Secret Manager,

1391.67 -> for example, my database connection string.

1395.48 -> So I'll use roles that enable me to get those

1399.38 -> virtual machines' ability to connect to other services

1402.74 -> without needing to pass, password around, or secret keys.

1407.21 -> And that's nice, that saves me a lot of time,

1410.18 -> this structure but that's not good enough, right?

1412.91 -> It's not highly available.

1414.44 -> I don't want my developers to wait in case of an outage

1418.092 -> or if I don't have enough build machines

1420.44 -> to get them up and running.

1422.33 -> So I probably want to deploy another group

1424.46 -> in another availability zone and have all of those

1427.67 -> in auto-scaling group because there's no point with build

1430.852 -> to keep a few hundred machines running,

1433.783 -> staying around idling, waiting for a build to happen.

1437.45 -> I want a scaling group with a bunch of roles in order

1440.15 -> to make sure that I have just the right amount

1441.8 -> of machines up and running so that if I have a huge load,

1445.25 -> use CPU, a lot of builds, I'll add more virtual machines.

1448.97 -> If I have a little load, maybe it's a weekend,

1450.77 -> maybe go all the way down to zero

1452.87 -> and that way I get a fully elastic,

1455.09 -> very efficient and cost-effective solution

1458.27 -> with the same tools just running on AWS.

1461.42 -> And that's just one architecture.

1463.01 -> I can go full containers on it because AWS Fargate,

1466.79 -> which enabled me to run containers in a serverless manner,

1469.94 -> fits perfectly with builds that goes,

1472.88 -> run for few minutes, and goes away.

1474.89 -> And I don't need to run those machine and keep them around.

1477.86 -> Although you might want to keep a few machines

1480.74 -> for things that take longer to start.

1483.23 -> For example, Windows containers,

1485.24 -> and then you have those groups according to what you need.

1490.76 -> And in the end of the day your developers,

1494 -> they just see Jenkins or whatever tools and you see the,

1501.137 -> the build pipeline that deploys in to ECS in this case,

1504.53 -> and you can see the state and they don't, don't care.

1507.14 -> They get everything up and running

1509.51 -> whenever they need to start a build,

1510.98 -> they'll get it automatically.

1512.15 -> They don't need to wait because you have a

1514.28 -> finite number of machines and everybody's happy, right?

1520.49 -> And that's bring us to testing.

1523.88 -> And testing is the secret ingredient that will make sure

1526.76 -> that your build, actually you benefit from it,

1530.33 -> it actually works.

1531.44 -> You don't need to go back and fix things all the time,

1535.37 -> because with testing the first thing you get

1538.61 -> is very quick feedback.

1540.978 -> You run the build and you immediately know the state

1545 -> and the quality and the health of your project.

1547.34 -> If a test fails, you have a problem.

1548.81 -> A test doesn't fail awfully,

1550.43 -> it means everything is okay.

1552.47 -> And by using tests we get this quick feedback

1556.22 -> and then we can quickly fix it

1558.08 -> instead of waiting for someone to tell us

1559.76 -> that there's a problem, a customer or a tester.

1562.91 -> And we get the regression immunity

1564.59 -> because I don't want to break yesterday's code

1567.23 -> by writing new features today.

1568.97 -> I want to be able to continue progressing forward

1571.67 -> and not moving backward.

1573.26 -> Now it seems a bit counterintuitive,

1576.14 -> but tests will enable you to move faster.

1581 -> It's counterintuitive because when you think about that

1583.34 -> simple addition, if you have only code,

1585.89 -> it takes less time to write than code plus tests.

1588.62 -> But if you just write code, there'll come a time,

1591.98 -> probably more often than not, that someone will come to you,

1595.04 -> tell you to stop working on the latest feature

1596.936 -> and fix a bug, and you need to go back, stop what you did,

1600.8 -> go back, developer's life that, and then go back again.

1605.81 -> And you keep on moving back and forth

1607.368 -> and you waste time essentially.

1609.23 -> You want to be able to move forward and

1610.91 -> you need automatic tests that run as part of your build

1613.67 -> in order to achieve that effect.

1617.06 -> And testing, it's not complex,

1620.12 -> but it does require some experience using it.

1625.58 -> But for, let's say we have a Lambda function.

1629.36 -> A Lambda function is a simple, in this case,

1632.87 -> written in C sharp, this is only the partial code.

1635.81 -> You don't see the actual functionality,

1637.49 -> the function's written in the bottom

1639.29 -> and I didn't write the code, it does not really matter.

1642.41 -> And that Lambda function will be triggered

1644.87 -> when a new file is saved on S3.

1648.08 -> And when a new file save is saved on S3,

1650.36 -> the Lambda function will wake up, magically read that file,

1653.96 -> process it, and save the result in a database,

1656.33 -> in this case DynamoDB.

1658.73 -> And that Lambda function, I want to test it,

1662.24 -> but I don't want other things like S3 and DynamoDB

1667.04 -> in my test because that way they won't be,

1669.5 -> my test won't be predictable, require external dependencies,

1673.52 -> and I don't think that you have a single account for

1675.95 -> each and every developer to run these tests

1678.2 -> and you don't want to do that either way

1679.67 -> because we want to focus on the logic.

1682.25 -> And the way to focus on the logic is to get away

1685.34 -> and throw away all the external dependencies.

1687.95 -> So the first thing we need to do is create

1689.84 -> dependency injection, essentially a constructor that

1692.84 -> get all of the dependencies I don't want,

1695.3 -> in this case clients to call S3 and DynamoDB,

1699.08 -> so I can replace them in my test.

1702.47 -> And the way to do it is I have a Lambda function,

1706.88 -> it's being triggered by S3.

1708.53 -> I don't want to trigger it by S3.

1710.193 -> I don't want to need to upload the file to AWS

1712.34 -> in order to see the Lambda function working.

1714.8 -> So I'll replace that with the test

1717.23 -> because a Lambda function is just a function,

1718.94 -> just code, write new, and run the function and you're done.

1723.05 -> And the second thing I want to do is get away with the dyna,

1726.437 -> the DynamoDB that I don't want to set up and run,

1730.01 -> and replace it with a fake DynamoDB.

1732.29 -> Now the trick of doing that's very simple

1734.549 -> because I'm not replacing DynamoDB,

1736.76 -> I'm just replacing a class that is called DynamoDB client.

1740.15 -> And the way to do it is to use a mocking framework that will

1742.43 -> inherit that class and then replace it with a class that

1745.7 -> does absolutely nothing by overriding all the methods

1748.76 -> and giving them no implementation whatsoever

1751.79 -> unless I tell it otherwise.

1754.58 -> And the test will look something like this.

1755.96 -> This is a very simple trivial test.

1758.619 -> The first test I will probably write,

1760.64 -> and in this case I'm testing that if I get an event from S3

1764.207 -> and I have problem because the event did not have the

1766.22 -> information I need,

1767.45 -> I shouldn't write anything in my database.

1770.45 -> And it starts by creating two fake objects,

1773.54 -> a fake Dyna, S3 client and a fake DynamoDB client.

1778.19 -> I'm using a fake it easy, open-source

1780.64 -> mocking framework for .NET.

1783.14 -> And once I have those two fake objects,

1785.54 -> they do absolutely nothing and I said,

1787.28 -> I tell them to do that in the context of the test,

1790.22 -> then I can initialize my Lambda function essentially,

1793.25 -> write new, and then call the method

1795.92 -> and in then I can check that no one has

1798.38 -> called the method on the DynamoDB client that saves

1801.23 -> something in the database.

1803.45 -> Now this is a trivial test,

1805.1 -> but by writing a lot of those tests, or a few,

1807.68 -> not a lot in this case, a few maybe 10, 12 tests,

1814.04 -> I can test all of the logic,

1815.84 -> all of the things inside the Lambda to

1818.6 -> make sure it does exactly what they want, right?

1822.41 -> - [Jagadeesh] Great. So let's see.

1824.81 -> So that was a very straightforward but yet

1827.48 -> very useful case of how, how would you,

1829.91 -> you would test a serverless function like Lambda, right?

1831.83 -> But how, how about testing a, an applic,

1835.55 -> an ASW .NET application that has a little bit more

1837.8 -> layers to it, like an interior application for example,

1840.64 -> it has a bunch of external dependencies or different layers

1844.1 -> within the components that talk to each other.

1845.9 -> So how do you handle those situations?

1847.88 -> - [Dror] Right.

1849.2 -> So yeah, real applications have multiple layers,

1853.16 -> probably some more than others.

1855.44 -> And we have external dependencies, we have databases,

1858.05 -> we have queues, we have other third-party services,

1861.56 -> other services if you write microservice architecture.

1865.52 -> And in that case you probably need more than just unit test,

1868.64 -> your unit test will test your business logic

1871.37 -> and that's the test pyramid if you ever saw it,

1874.43 -> we'll start with unit test, just with the Lambda function.

1877.46 -> Take bits of my logic and test them using code with code,

1881.33 -> the unit testing framework, mocking framework,

1883.37 -> just test internally and don't run any external dependency.

1887.69 -> But that's a problem because I still need to check

1890.48 -> that my queries to my database actually behave

1893.54 -> like I expect them to.

1895.04 -> I still need to check that things that go outside the scope

1899.09 -> of my code work exactly as I wanted and fake them

1902.33 -> is not always a good idea.

1903.92 -> So I need something else.

1905.06 -> Integration tests essentially start whatever resource,

1909.11 -> whatever third party application,

1910.55 -> whatever external dependency for real,

1913.7 -> and run your code against it.

1915.5 -> Now if you already using .NET latest version,

1918.96 -> then you probably have Docker.

1920.87 -> So if you have a database that easily set up,

1923.12 -> you can probably set it up inside Docker,

1925.25 -> run your test, and then scrape it out.

1927.44 -> You can run Docker form code and do that.

1930.89 -> And then we go to service level tests.

1933.29 -> The whole service, the whole mono application,

1935.39 -> end to end, probably without external dependencies,

1938.18 -> other services or AWS services

1941.3 -> to check that all my application

1942.966 -> work top to bottom with a few key scenarios.

1947.09 -> And then I need to fake things but probably

1950.78 -> can't use a mocking framework

1952.1 -> because with service level tests,

1953.6 -> I can't run the service outside the scope of my test,

1956.63 -> I will execute it as a different thread,

1958.4 -> a different process,

1959.93 -> and then I can use different ways to fake things

1962.81 -> outside of my service.

1964.16 -> If it's external services, I can use the same idea

1966.53 -> like mocking framework with services.

1968.42 -> There are projects called mock server that will create an,

1972.5 -> a server, HTTP server that I can command,

1974.72 -> tell it when you get

1976.22 -> get 1, 2, 3, 4 htp, whatever, return this result.

1981.56 -> And I can fake a whole service.

1984.2 -> I can also run the, the real dependency

1986.36 -> if I don't have any choice.

1987.92 -> And there's also local AWS services that you can run.

1991.84 -> They're not really local,

1993.92 -> but they mimic the real behavior of the real AWS service.

1997.28 -> For example, DynamoDB has DynamoDB Local

2000.43 -> that can run either from your code,

2002.41 -> outside of your code, or inside the Docker image,

2004.93 -> get a thing that understand and return results

2008.23 -> like real DynamoDB that you can work against.

2011.59 -> And there's open source projects for many AWS services

2015.269 -> specifically for those kind of tests.

2018.07 -> Also a few commercial ones as well.

2021.04 -> And finally, there's end-to-end tests.

2023.11 -> Now end-to-end tests usually look like the best way to start

2026.59 -> because it tests my whole application top to bottom.

2029.08 -> It's the perfect test, it does the right thing.

2031.87 -> The problem is that maintaining those is very hard.

2034.69 -> You need to set up your system,

2035.98 -> it will take a while and if something changes

2038.62 -> and something break,

2040 -> you need to go into a very lengthy debug session

2044.14 -> to try to understand what went wrong there.

2046.39 -> That's why it's a pyramid.

2047.95 -> It's a pyramid because the higher I go,

2050.53 -> the less tests I have.

2053.08 -> Unit test, you have a few hundred, a few thousand.

2056.08 -> Then in order of magnitude less,

2057.73 -> integration tests only in the places it makes sense

2060.833 -> to really test the integration, not in every single point.

2063.88 -> Service level tests, a few kits and hours,

2065.74 -> end-to-end tests only the important ones

2068.14 -> because the higher you go,

2069.52 -> the more time it will take to run the test.

2071.74 -> And we wanted quick feedback.

2073.69 -> I want to know in five minutes or less,

2075.73 -> if my project is healthy,

2077.59 -> I don't want to run end-to-end test.

2079.36 -> Each of them taking 15 minutes,

2081.58 -> four of those will take an hour.

2083.14 -> That's not something I'm I can do

2085.09 -> and they will break more than unit test and

2086.123 -> are harder to maintain.

2088.45 -> Now depending on a project,

2090.01 -> you might not need all of those kinds.

2093.4 -> We just saw Lambda function unit test probably

2095.68 -> will cover 90% of what you need, maybe a hundred.

2100.06 -> But the bigger the server you have,

2102.46 -> the more processing you do it,

2103.69 -> the more integration you have,

2105.25 -> those different layers might look different.

2109.21 -> And that is usually the testing strategy

2112.36 -> or a good place to start or at least have in your head

2115 -> when you start to think about how to test your things.

2118.09 -> Now we covered build, we covered source build,

2121.93 -> deploy and testing.

2124.15 -> So that's the end of the session. Thank you for coming.

2126.46 -> Right, done? (laughs)

2128.371 -> - So I wish but we did miss an important part of the,

2133.03 -> the whole build pipeline.

2134.86 -> Any, any guesses what that is?

2139.33 -> Right, so infrastructure as code.

2142.96 -> So a quick show of hands,

2144.13 -> how many of you are aware of infrastructure as code

2146.507 -> or use it as part of your...

2148.501 -> Oh, quite, quite a few.

2150.4 -> Oh, most of you, which is great.

2153.04 -> I love it.

2154.66 -> So yeah, just, just for those who are not

2156.43 -> familiar with infrastructure as code,

2157.96 -> so you have your application, now you have,

2160 -> you need resources to run your application.

2161.6 -> There are other resources in the cloud

2163.84 -> that your application might use, like blobs, destroy blobs,

2167.65 -> maybe like an S3 Secrets Manager,

2170.5 -> where you show your sensitive information,

2172.75 -> IAM entities for users and roles.

2175.09 -> So there are a bunch of other resources that go with it.

2177.07 -> So one way of deploying this is basically

2179.47 -> going into AWS console and creating this environment

2182.92 -> every time you want to create,

2184.69 -> and clicking through buttons and spinning up resources

2186.94 -> and waiting for it and making sure,

2189.04 -> or just praying that every time I do it,

2190.93 -> I follow the steps and that I'm creating them consistently.

2193.54 -> That's not what you want to do though.

2195.16 -> That's where infrastructure as code comes into the picture.

2197.77 -> It's a crucial, crucial piece of your DevOps methodology.

2202.66 -> Right, so basically what it is is modeling

2207.22 -> all of the infrastructure on infrastructure that you need

2209.53 -> to run your applications using code.

2211.54 -> That's as simple as that.

2213.46 -> By doing so, you gain a very specific set of benefits

2218.44 -> that directly relate into your team's productivity.

2221.35 -> So that's what we are talking about, right?

2222.76 -> How do, how do we improve productivity?

2224.805 -> And the, the benefits basically are around

2228.34 -> you gain the ability to deploy

2230.38 -> your environments consistently,

2231.94 -> so you can build and tear down

2233.68 -> cloud environments as frequently as you want.

2236.32 -> And the results are going to be consistently the same,

2238.54 -> right, because you're running,

2239.56 -> you're creating these environments through code,

2243.16 -> you are treating infrastructure as code basically.

2245.44 -> So you are, you know,

2247.12 -> committing this code into a source control.

2249.37 -> You are code reviewing your infrastructure as code with the

2252.73 -> same rigor as you would code review your application code.

2255.82 -> So it would result in, you know,

2257.71 -> less issues when you eventually go to deploy it.

2262.27 -> You're also making this part of your DevOps pipeline.

2264.73 -> So you, you using automated provision through DevOps, right?

2267.82 -> So you gain speed and finally you gain visibility

2271.39 -> because it's part of your code repo.

2273.22 -> So you know, there are things you could,

2275.41 -> you could go back and always check how your infrastructure

2278.38 -> evolve over time, right?

2279.97 -> So how it evolved, how it looked like previously.

2282.91 -> So those, those are your benefits.

2287.35 -> We, we said it's always the,

2288.67 -> the using the, the good practices

2290.497 -> and also the right tooling.

2292 -> So let's look at the tooling that we have available, right?

2294.19 -> First I want to talk about the cloud native AWS,

2296.5 -> cloud native tooling that's available for you.

2299.62 -> AWS CloudFormation is a service that lets you

2302.11 -> define and deploy your infrastructure

2304.27 -> using declarative statements like JSON or yaml.

2309.64 -> There is AWS Serverless Application Model, AWS SAM,

2312.88 -> this is basically an extension of AWS CloudFormation,

2316.18 -> but it's specifically useful

2317.89 -> if you're developing serverless applications.

2320.23 -> For example, it's, it's very common

2322.33 -> to host a .NET web API on AWS Lambda fronted by

2326.89 -> something like Amazon API Gateway that lets you manage

2329.83 -> API set scale and you know, it's using like,

2333.13 -> no sequel serverless database like Amazon DynamoDB, right?

2336.58 -> So that's a pretty typical use case.

2338.62 -> But this use case also is built a hundred percent

2341.74 -> using AWS serverless services.

2344.17 -> So you, when you use SAM, it lets you define the

2348.04 -> entire stack using only a few lines of code.

2350.05 -> It has other benefits too.

2351.61 -> Like it lets you test debug,

2353.65 -> monitor your Lambda functions locally

2355.63 -> by providing you with a, with an environment

2358.03 -> that's, that lets you do it.

2361.87 -> Then there's AWS Cloud Formation Kit.

2363.64 -> So this is also one of my favorite

2365.11 -> because I have a developer background, right?

2366.94 -> So it lets you model your infrastructure as code,

2369.76 -> but it lets you use familiar programming languages,

2372.28 -> higher level programming languages like C sharp,

2374.8 -> right, in this context.

2376.51 -> It also has a bunch of other benefits.

2378.37 -> I'm going to dig into it a little bit deeper in,

2380.56 -> in in a second,

2382.06 -> but I want to talk about the options you have

2384.61 -> outside of AWS, right?

2385.69 -> Terraform is a very popular IaC solution

2388.18 -> and a lot of my customers that I talk to

2390.64 -> use use Terraform as a infrastructure as code solution,

2394.21 -> which is perfectly fine because AWS prov,

2397.357 -> AWS has a provider in Terraform that you could use

2401.68 -> to model your infrastructure.

2402.61 -> So these are self-contained tested modules

2405.561 -> to model AWS infrastructure using hashicorp language

2409.03 -> in, in Terraform.

2410.481 -> So the AWS provider has over a billion downloads

2413.14 -> and it has 2000 active contributors.

2415.84 -> So it's, it's pretty evolved.

2418.21 -> The other option, Pulumi,

2419.8 -> it's very similar to AWS Cloud Development Kit in,

2422.213 -> in that it lets you model the infrastructure using

2424.87 -> higher-level programming languages, right?

2428.44 -> And you, there's a similar AWS provider for Pulumi

2430.9 -> that you could leverage if you have existing investments

2433.12 -> in Pulumi or if your team is comfortable

2434.98 -> developing in Pulumi,

2436.348 -> you could continue using it and use the AWS provider for it.

2439.33 -> With so many tools, again,

2440.26 -> the question is how do you choose, right?

2442.12 -> So if you're part of the operations team and you love

2444.288 -> the simplicity of and and the, and the,

2446.767 -> and the flexibility of using JSON or yaml,

2449.62 -> those would be your go-tos,

2450.79 -> use AWS CloudFormation or Terraform.

2453.68 -> If you're part of the development team and a develop

2456.64 -> actively developing serverless applications or you,

2460.053 -> you are developing, you want to model the infrastructure

2463.87 -> using a familiar programming language.

2465.37 -> So those are your options, use AWS SAM,

2467.347 -> AWS Cloud Development Kit or Pulumi.

2472.302 -> All right so let's dig a little deeper into AWS CDK.

2476.8 -> Again this is one of my favorite because of the

2479.83 -> reasons that you're gonna see,

2481.75 -> you can model infrastructure using C sharp.

2483.55 -> So you do not have to learn new language if you're not

2486.31 -> comfortable coding in anything else.

2488.05 -> As a .NET developer, I was one of those,

2490.51 -> you can continue, continue to leverage C sharp,

2494.29 -> you don't have to contact switch,

2496.6 -> you can continue using Visual Studio,

2498.67 -> don't have to leave it.

2499.934 -> You also get to use all,

2501.88 -> all the native VisualStudio features like

2503.65 -> IntelliSense, Inline Documentation.

2506.11 -> When you use it, it provides you smart defaults.

2509.59 -> We're going to look at it in a second.

2510.82 -> So every resource that you spin up in cloud

2513.22 -> has tens of properties that are attached to it.

2516.31 -> If it lets you, it doesn't force you

2518.77 -> to select each of those properties

2520.36 -> for you to spin up a resource, right?

2521.887 -> So you, you, you, it provides smart defaults, obviously has,

2526.373 -> you have the right to override some of those smart defaults.

2529.42 -> You can also create reusable constructs that you could,

2532.45 -> you know, distribute within your company to make sure that

2535.472 -> environments that are using particular resources are

2538.36 -> consistently being deployed in a particular way.

2542.68 -> And the another big benefit is you get

2545.35 -> compiled time error detection.

2546.7 -> So you don't have to wait until you deploy it

2548.62 -> to find out that something is broken.

2551.41 -> Also remember the, you know,

2552.7 -> C sharp is only one of the languages

2554.38 -> that is supported by CDK, right?

2556.24 -> So there are, if, if a lot of companies,

2559.09 -> a lot of customers that I work with, it's usual,

2561.46 -> it's common to have polyglot environments

2563.41 -> where there are teams working with different languages

2565.81 -> that they're comfortable with.

2567.25 -> So remember there it also supports JavaScript type script,

2570.52 -> Python, Go, and a bunch of other languages.

2572.53 -> They're, you know, so you could use this

2575.02 -> interchangeably with any language of your choice.

2579.1 -> So now, now you model your infrastructure as code, right?

2581.59 -> So, but if you have to deploy that infrastructure as code

2585.31 -> every single time you want to build a different alignment,

2587.5 -> it's, it's beating the purpose, right?

2589.6 -> So what you want to do is make it

2591.28 -> part of your build pipeline. So build it on demand.

2593.65 -> So if you want to update your environment, so you,

2595.75 -> all you need to do is make an update to the code,

2598.78 -> push it to your SCM,

2600.07 -> and then make sure your build pipeline kicks in

2602.08 -> and updates those, your environments, right?

2604.613 -> So, and the way you do it is make it part of your code.

2608.47 -> And the build step is optional.

2610.18 -> So AWS CDK is a service that gets synthesized

2614.62 -> once you write your CDK projects to cloud formation.

2617.832 -> So that's an optional step.

2619.27 -> So if you're using CDK,

2620.38 -> you would build your CDK to CloudFormation.

2622.21 -> If you're using CloudFormation,

2623.41 -> you would directly deploy it using AWS CloudFormation.

2627.61 -> Right, so let's see some of that in action.

2634.9 -> So what I have here is a simple CDK application, right?

2639.66 -> So there are three con,

2640.99 -> there are three definitions I want to walk through.

2642.91 -> So this is a CDK application.

2645.04 -> It's basically a container of one or more stacks, right?

2648.58 -> So let's define a stack.

2649.66 -> So I have a single stack in my CDK app,

2653.2 -> it's called IaC Demo Stack.

2654.52 -> So demo, stack is a unit of deployment in CDK.

2657.55 -> So it contains all the resources that get deployed

2660.49 -> or updated as a single unit.

2662.71 -> So within each stack, what I have is one or more constructs.

2666.34 -> So construct is a, is a cloud component that makes up

2670.06 -> a bunch of components, a bunch of constructs

2672.91 -> who would make up your stack, right?

2674.86 -> So this simple CDK application,

2676.45 -> in fact this is an application that ships as a template

2679.03 -> with CDK CLI, right?

2681.04 -> Is creating a Amazon SQS queue,

2686.02 -> which is a managed queue service on Amazon.

2689.59 -> It's like three lines of code.

2691.66 -> It provides tens of smart defaults, right?

2694.39 -> So, and and it also lets me override the smart defaults.

2698.59 -> In this case I wanna change the visibility time out

2700.54 -> to 150 seconds.

2702.28 -> So I'm also able to create an SNS topic,

2704.56 -> which is basically a managed pops up on Amazon,

2708.43 -> you know, with a single line of code.

2710.62 -> And then another line that basically is adding a

2712.69 -> subscription of the queue to the top.

2715.581 -> I wanna show you how easy it is to add new code.

2718.36 -> So, and also take leverage the

2720.31 -> Inline Documentation and IntelliSense

2722.62 -> that comes with VisualStudio.

2724.06 -> What I want to do is create a user,

2728.56 -> IAM user in this case, right?

2731.11 -> So as you can see,

2733.15 -> I get to use the IntelliSense and Inline Documentation,

2744.25 -> want to name my user,

2745.69 -> this is the ID that's being used within the construct.

2749.14 -> Simple like that, under the line of code

2751.87 -> basically say I want to give my SNS topic

2756.73 -> grant public permissions for the user, right?

2760.36 -> That's simple.

2761.86 -> Two lines of code, you created an IAM user and also

2764.59 -> gave permissions for that user to go publish messages

2767.8 -> to your SNS topic.

2770.68 -> Now what you want to do naturally next is

2773.32 -> CDK gets synthesized to CloudFormation.

2775.75 -> And the way you would do it is use CDK CLI.

2779.232 -> Like in this case I would go and do CDK synth

2782.11 -> in the project directory.

2783.13 -> I don't want to do that now

2784.27 -> because it's going to take a couple of minutes.

2786.22 -> I've pre-synthesized that into CloudFormation, right?

2791.02 -> So before my modifications,

2793.12 -> now you can see that 23 lines of CDK code

2797.53 -> actually translate,

2798.79 -> translates the 315 codes of, 315 lines of JSON code.

2802.81 -> So you kind of understand the,

2804.61 -> the verbosity that's provided by CDK.

2813.764 -> All right, so what, again, like we said,

2815.74 -> having having just coding your,

2818.92 -> your infrastructure using C sharp is not good enough, right?

2821.29 -> So you need a build pipeline that'll take the changes

2824.2 -> that you update your code and then

2826.51 -> go deploy them to your cloud environments.

2828.61 -> So have a simple code pipeline here, right?

2831.13 -> So CodePipeline again is orchestrating

2833.26 -> all of those stages in my CI pipeline.

2835.9 -> So I have three stages in my CodePipeline.

2838.27 -> One is my infrastructure code, the CDK project,

2841.15 -> which is in a AWS code commit get repo.

2845.483 -> I have an AWS code build, which is my build stage.

2848.47 -> So it's going to take the CDK project,

2850.45 -> it synthesizes it to CloudFormation

2852.76 -> and hands it over to the next stage,

2854.56 -> which is my deployment of infrastructure,

2856.42 -> which is basically taking that and then

2859.03 -> deploying it using AWS CloudFormation service.

2862.33 -> So every time I make a change to my code,

2867.25 -> in this case I did update my, my stack,

2869.65 -> I added new user and changed some permissions,

2873.07 -> save my code, git status, add simplicity,

2881.86 -> let's just add everything.

2892.57 -> Yeah, I just commit my infrastructure code.

2898.24 -> And then push my changes to the origin.

2900.73 -> Also, while this gets pushed out,

2902.53 -> I wanted to walk through how AWS Core CodeBuild works.

2905.77 -> So it's a managed build service, right?

2907.21 -> So it looks at a specific file in your Docker repo.

2913.6 -> The name of the file should be buildspec.yml.

2916.75 -> And it looks for instructions on how to build your code.

2919.15 -> So especially around two command CDK synth

2922.323 -> is what is taking your applic C sharp code

2924.94 -> and building it into CloudFormation.

2927.076 -> It's also spitting out the the CloudFormation template

2929.56 -> that the next stage uses to deploy infrastructure.

2933.73 -> Right, let's go back and see if my changes

2936.25 -> that I pushed to kicked my pipeline.

2938.02 -> So there it is.

2942.34 -> Yeah. So there it is.

2943.54 -> It kicked off my pipeline and it's currently building,

2946.54 -> it's going to deploy my changes to CloudFormation.

2948.55 -> So it should be as simple as that, right?

2950.98 -> Hopefully that makes sense.

2954.07 -> - [Dror] Yes, no.

2955.276 -> Which bring us to the end of the story because

2958.69 -> we show you all the pieces, but let's see it all together.

2962.097 -> Here we have a project.

2964.84 -> This project might look similar to some of you.

2968.77 -> Those are two services deployed on AWS ECS.

2972.97 -> And if you, and it's .NET six

2976.66 -> and here we have the source for the inventory service,

2979.9 -> a plain old, ASP .NET service

2984.31 -> and nearby or side by side we have the tests,

2987.7 -> we have unit tests, a bunch of unit tests here.

2990.34 -> And we also have service level tests here.

2993.85 -> Integration was not something we needed here,

2997.24 -> no end to end test.

2999.1 -> And we have two services as I said, and that's nice,

3003.36 -> but that's not the important part.

3007.26 -> The important part is that I have the infrastructure

3009.39 -> side by side with those services.

3010.74 -> Now according to your team, your project, your company,

3014.22 -> you might have different services in the same repository

3016.68 -> in monorepo, or different repositories per service.

3019.816 -> Those rules still apply.

3021.69 -> You want the infrastructure relating to your service here.

3025.44 -> You might have a common infrastructure somewhere else,

3028.56 -> but everything that has something to do with those services

3031.53 -> need to come with them.

3032.7 -> Cause tomorrow when I change the infrastructure, right?

3035.22 -> Another service or change something about

3037.29 -> how my services should work,

3038.76 -> I want to do that in the same solution.

3041.25 -> And yeah, the infrastructure make a CDK

3043.95 -> because we like C sharp and we can see

3048.24 -> I'm creating a VPC networking.

3051.21 -> If you ever started a VPC in AWS

3053.19 -> you know that it's not two lines of code.

3056.13 -> And again, CDK has a lot of nice defaults.

3058.02 -> I just care about two AZs.

3059.25 -> I'll get public and private subnets and nat gateways

3062.79 -> and all everything I need.

3064.32 -> If I want something else, I need to define it.

3066.36 -> But the default is pretty good for me.

3068.91 -> And this line is a ECS cluster.

3072.21 -> Again, four lines of code and next I'm building

3075.999 -> those two services, FargateService, it's called inventory.

3081.36 -> You can find the code over there.

3083.73 -> And all my infrastructure now comes along with my code

3087.9 -> and it can be with Terraform and any other

3089.61 -> infrastructure as code.

3091.399 -> But this being a development session,

3094.53 -> which I wanted to show you code,

3096.3 -> but that's not the end of it because CodeBuild and

3100.134 -> CodePipeline are also AWS services,

3103.38 -> which means I can write them using CDK.

3107.94 -> I can write my old pipeline in C sharp with CDK

3111.63 -> and deploy that.

3112.463 -> In fact, the pipeline I showed you

3114.33 -> in the beginning of the session,

3116.13 -> this is exactly how you define it.

3119.46 -> It's not as simple as a VPC and EC2,

3123.87 -> but it's not as complex.

3125.34 -> I have a pipeline.

3126.42 -> It would build its own definition from scratch.

3129.9 -> That's what we see here.

3130.98 -> It's .NET code building CDK in .NET code,

3133.89 -> which is kind of reclusive.

3135.81 -> And then we go and define a few tests in the testing stage

3141.72 -> and our services and we're done.

3144.69 -> And we get all the niceness of CICD pipeline

3149.82 -> baked into our code.

3152.13 -> So everything should come together

3154.14 -> and everything should sit side by side.

3156.15 -> And that's the way that we can really move forward faster

3159.36 -> because if I need to change anything in my code,

3161.55 -> the build pipeline, my infrastructure or my services,

3165.84 -> I can do it in the same place, deploy it,

3168.21 -> and immediately see it deployed and executed in the cloud.

3173.4 -> And that is essentially how you do it and how you can

3177.39 -> move faster with all of those practices

3181.32 -> and all of those tools and do more with less developers.

3188.22 -> Thank you for attending this session.

3190.26 -> By the way, we have a lot of other .NET related session.

3193.11 -> If you're interested, look it up in the application.

3195.78 -> And please don't forget to give us feedback.

3198.251 -> We do have time for one or two questions.

3200.94 -> If you have any question right now or you can see us

3204.81 -> in the hall, we'll be sticking around

3206.771 -> to answer any question you have on this topic or others.

Source: https://www.youtube.com/watch?v=YQ8crEndIUY