Brewing the Blog
Why I Chose ASP.NET Core and AWS For My Blog
by JamesQMurphy | May 25, 2019
DevOps can mean lots of things to different people. But it almost always involves Continuous Integration and Continuous Delivery (CI/CD) -- the processes necessary to refine a set of source code and take it from a developer workstation into a real production environment. I've been doing it for a while and I always wanted to showcase a complete CI/CD pipeline. I wanted to show everybody the entire process, and not just with pictures. I want to demonstrate a CI/CD pipeline with real tools that you (yes you) could actually go and look at.
Selecting the Right Ingredients
I also considered using Visual Studio Code to do the development work, but I ran into some odd behavior when toying with the ASP.NET 3.0 samples (for instance, the web browser wouldn't automatically start when I hit F5, even though it did for an ASP.NET 2.2 app). So I decided to stick with Visual Studio; specifically, I used Visual Studio 2019 Community Edition.
Clouds in my Cold-Brew
My inbox is littered with e-mails that scream, "Urgent need for DevOps Engineer with Cloud Experience!" 1 Pick up any DevOps job requirement and you'll see that cloud experience is almost always a prerequisite. Most job requirements want to see either Amazon Web Services (AWS) or Microsoft's Azure platform. I had played around with Azure in the past, so I knew I could go that route. In fact, Azure makes it really easy to host an ASP.NET Core application.
But honestly, I wanted to see how the other half lived. I really wanted to use AWS to host the site.
ASP.NET Core on the cheap
But what about cost? I knew that I wasn't going to get something completely free, yet I didn't want to spend more than $20/month. So right away, I knew that I wasn't going to have my own servers, even in a cloud environment. (Servers cost money no matter where you go). That leaves serverless platforms, and both Azure and AWS have solutions for that. With Azure, you can host an ASP.NET Core application using their App Service solution. However, even that gets pricey. The cheapest level that lets you have your own domain with SSL is their Basic level, and at the time of this writing, their cheapest Basic level tier (B1) runs over $50/month.
AWS, on the other hand, offers their AWS Free Tier, which is split into "free for a year" and "always free" lists. Putting aside the goodies on the "free for a year" list, the "always free" list was still intriguing. The two services that caught my eye were DynamoDB (an object database) and Lambda (their serverless compute engine). Both of these services are the "always-free" tier, which offers 25 GB of DynamoDB storage and a whopping 1 million requests per month for Lambda.
What about the parts of AWS that you do have to pay for? With AWS, the nice part is that you pay for what you actually use. First, there's file storage, and that's the popular AWS S3 (Simple Storage Solution). They charge by the GB monthly, and it depends on the AWS region. For me, using the popular US-East-1 region would cost $2.30/month for 10GB of storage. Then there's data transfer. As we'll see later, I made use of AWS Gateway API to expose AWS Lambda and S3 to the outside world. $3.50/month per million hits in, and $0.09 per GB transferred out. Not only can you hook up your own domain, you can use SSL (in fact, with Gateway API, you have to, but I'm not complaining). And if you don't mind using Amazon's certificate for your custom domain, that's free too. Not to sound like an Amazon fan-boy, but this was a fantastic deal. A real ASP.NET Core site, with SSL, for a few dollars a month until I see actual real traffic. Winner: AWS.
In case you were wondering, did I ever look at other hosting sites, like GoDaddy? I didn't, but I didn't have to. Most of those sites offer straight hosting, with no application tier (PHP if you're lucky to get it). Scott Hanselman did manage to get an ASP.NET Core site running on one of these sites, but it was not a sustainable solution. Read about it here.
Source Control -- the obvious choice
The next choice was an easy one: version control. Since I am showing how this site is built, the source code needs to be publicly available. And that, of course, means GitHub. Besides being the obvious choice from a public availability standpoint, there was another factor to consider... continuous integration builds and deployments (CI/CD). Just about every CI build system on the planet can access and integrate with GitHub (they usually support their own repository and offer GitHub as the alternative). And speaking of continuous integration...
The CI/CD Pipeline
This is where the honeymoon ends with AWS. While AWS does offer build tools in their "always free" tier, it's not all that impressive. Sure, you get 100 hours per month of AWS CodeBuild, which isn't too bad, except that the features are somewhat paltry (for example, you can't even get the name of the branch that triggered your build). And you can only have one active AWS CodePipeline per month.
Microsoft's Azure DevOps Services, on the other hand, have superb continuous-integration tools, even if they keep renaming it every other year (it's really just Visual Studio Online, which used to be Visual Studio Team Services, which is really just an online version of Team Foundation Server). I've been working with the redesigned build engine for a few years now, and it keeps getting better. Plus, you get unlimited build minutes and up to ten parallel build pipelines for open-source projects. (Even the more traditional Microsoft-hosted pipeline, although limited to only one free pipeline, gives you 1,800 free hours per month. Yeah, 75 days' worth of build time in each month.) And yes, it can totally deploy to AWS.
Thus, the technology choices are:
- Platform: ASP.NET Core 2.2
- Source Control: GitHub
- Continuous Integration: Microsoft Azure DevOps Pipelines
- Hosting: Amazon Web Services (Lambda, S3, and Gateway API)
In the next post, I'll describe setting up the initial project.
Well it used to be. Nowadays, I filter out messages with the words urgent need in the subject.↩
Not Enough Characters
Comments must be at least three characters long.