It’s fun to experiment, but you eventually need to get things done. I spent a good chunk of my last weekend working on a side project. I have an idea for a website and I’m going to build it up over the next few months. I have a few goals for this site. Tech-wise, I wanted to build something that was super cheap to host while doing something practical with my cloud skills.
There’s a near infinite number of ways to build a website, but I wanted to use a static generator. Static sites are cheap, fast, easy to make, and easy to secure. Unlike a WordPress site, you don’t need to constantly update it or worry about it getting hacked. Static sites are low maintenance, which is great for people like me who don’t have oodles of free time to click “update”. Drop some assets on some cheap hosting and call it a day.
There are many static site generators to choose from. I wanted to go with a React based static generator. I know and enjoy using React. I wanted an easy path to building any extensions. There are lots of other generators written in different languages, but I wanted something that meshes with my current skills. Trying to learn too many new things at once results in zero progress. The most popular React-based site generator is Gatsby.js. I looked into some of the alternatives (react-static), but Gatsby.js had better support.
After picking my technology, I needed to find a place to host the site. I’ve been working on my Azure skills lately and they recently released a new static web hosting service, so I started there. Besides being what I’m comfortable with, I also like the idea of being able to rope in Azure services if I want to add features to my site.
My goal was to build a CI/CD process using Visual Studio Team Services (VSTS) that would automatically deploy to static hosting from a git repo. This did not end well. Azure Static Hosting is “preview” for a reason. My static settings kept reverting back randomly and the built-in blob storage deploy tasks failed with a blank error message. I’ve had good luck with other Azure services, but this was a total disaster.
I could of gone with an Azure website to host my static files, but I wanted the super cheap static site hosting experience. Instead of banging my head against a wall, I tried out AWS instead. Amazon S3 has been out for a long time and is often used to host static sites. The AWS S3 experience was far more mature than Azure Blob storage. The UI for S3 is far nicer and you can add AWS build tasks to VSTS that actually work. Except for some weirdness with user accounts, it was easy to setup. I had a nice three step build pipeline from my Git repo on VSTS to an S3 static site bucket on AWS. This is coming from someone who has zero experience building things on top of AWS.
Even though my experience on AWS was great, I wanted to try out one more experiment. Netlify is a hosting platform that’s built for static sites. Accounts are free and you can have a static site up and running on Netlify in about five minutes. While they don’t support VSTS, they do support Github and Gitlab. After signing up for a free Gitlab account, I setup a private repo, hooked it up to Netlify, added my custom domain, and was ready to go. Netlify’s built in CI/CD software is easy to use. It only takes a few few minutes to hook up your git repo. Netlify even has branched deploys so you can make a QA environment. Overall, it took less than an hour to setup everything.
In the end, I went with Netlify. While they don’t offer the variety of services AWS and Azure do, they are excellent for hosting static content. If I was building a static app that needed a backend, I probably would go the AWS S3 route. Netlify can talk to Lambda functions, but I’d prefer to stick with one cloud platform per app. I’m sure Azure will improve their static hosting game, but for now, I wouldn’t use it for anything production related.
If you’re building a static website, it’d be hard to do better than using Gatsby.js on Netlify. It’s a killer combo. Easy to work with and free to host. This is going to be my new default for any kind of content site or MVP web application.
Being a developer is committing to a lifetime of learning new skills. Over the past few weeks, I’ve been working on grokking cloud architecture on Azure. Like many devs on the Microsoft stack, I’ve played around with Azure. I built a few resources and watched some demos, but until recently, I hadn’t taken the time to really invest in the skill set. I never felt like I had a good understanding of Azure as a whole. In this post, I’m going to talk about my experiences learning about Azure over the past few weeks.
The toughest part of learning Azure is that it’s huge. “The cloud” is nebulous by definition, and Azure doesn’t disappoint. Azure isn’t a single thing, but collection of many different products and services. This abundance makes it tough to get started.
When thinking about Azure, you can divide the services into a few large buckets.
Here’s a high level overview of what’s in Azure:
In Azure, you can build virtual machines, virtual networks, load balancers, and other virtual appliances. If it exists in a data center, you can probably make one in Azure.
App services host specific kinds of applications without the need to configure servers. You usually run these on top of VMs, but you don’t need to configure them. You just pay for the compute resources. Azure has app services for web applications, apis, mobile apps, and functions.
Azure has several services that support security and identity. This includes several flavors of Active Directory and Key Vault, which stores application secrets. Azure also has several different mechanisms to scan for security issues.
If you have data, Azure can store in a ton of different ways. You have your basic storage accounts, which can hold blobs, queues, files, and json objects. You also have Azure SQL Server and several other hosted SQL databases (including Postgres and MySql). If you need worldwide scale, you can use Cosmos DB. Azure also has a pile of big data tools like HDInsight and Stream Analytics.
Azure has a lot of APIs you can take advantage of in your applications. This includes things like Cognitive Services, Notification Hubs, and Multifactor Authentication. You can leverage these tools to shortcut things you used to have to do yourself.
This is by no means an exhaustive list. Azure updates constantly and new offerings are added all the time.
To help navigate this landscape, I chose to base my studying on the Microsoft Azure certifications. While I still haven’t convinced myself to take the actual exams, the exam outline is a useful map for learning. I’ve always been on the fence about the actual value of developer certifications. Much of what’s covered is stuff that’s easy to look up in the docs and developer certs lack the clout of networking certifications. Software also changes so fast that certs tend to either rapidly expire or are out of date. Azure certifications update every three months, which makes it hard to find solid resources. Regardless of the value of the certifications, the outlines are useful.
Here’s the two certs I looked at
I began by working my way through a 70-532 course on Udemy. I watched all the videos and built plenty of demos while going along with the course. The course claims to prepare you for the exam, but it doesn’t some close to the level of detail you’d need. It’s an OK overview, but the more I learned about Azure, the more I felt like this course was a waste of my time.
After reviewing some other courses from Udemy, I found the platform to be hit-and-miss. Udemy also has a pretty serious piracy problem where pirates will steal courses from other people and host them on Udemy. While the Azure course I saw was decent, I can’t recommend using Udemy as a first rate source for developer content.
Here’s the course I used
After working my way through that course, I searched for other resources. Microsoft offers free Azure training through Pluralsight. It’s been a while since I’ve checked out Pluralsight and they’ve done a lot to improve the platform. The last time I used it, Pluralsight had cranked up their video acquisitions. This was good for variety, but choice overload made it nearly impossible to figure out what course to take. Nothing sucks quite like ten courses that look identical. Fortunately, Pluralsight introduced learning paths. Now, instead of sorting through hundreds of courses, you can sort through a few dozen learning paths. Each path has a handful of courses that go from beginner to advanced. You can also use their handy Pluralsight IQ function to gauge your skill level. It’s like a mini certification test. They’re also free, so check them out if you’re up for a challenge.
Azure Learning Paths
I split my time between several of the Azure related learning paths. They have a 70-532 related path, but they also had paths geared towards solutions architecture and developers. As mentioned before, I’m more interested in gaining useful skills than becoming certified. I don’t feel any obligation to stick to the certification content.
Here’s a few of the courses I looked at:
The 70-532 path has an excellent set of courses by Mike Pfeiffer.
This path dealt with Azure at the architecture level. Simon Allardice’s course gave a nice conceptual framework to hang some of the more detailed concepts on. Simon’s course directed me to Scott Allen course for a more detailed view.
Scott Allen is an excellent presenter and his advanced course in the .NET developer path does not disappoint.
Pluralsight has some great resources and a lot of the Azure content is free, so I recommend you check it out.
Besides watching courses, I built a ton of small demo projects. Like anything else, you can’t just watch a video and expect to know how to do something. You need to get your hands dirty. While watching the videos, I’d follow along with the course by building along. Additionally, I worked my way through the various exam objectives make small demo projects.
When doing demo projects, I recommend you build small. Building small helps you focus on the topic at hand while avoiding getting sunk in non-relevant details. It also gives you references you can go back to later.
Another excellent resource is Microsoft’s own Azure documentation. Our friends at Microsoft poured a lot of love into their documentation and it shows. The Azure docs have lots of reference information combined with specific tutorials. It’s worth having a tab with the Azure docs open at all times.
While I’ve worked diligently these past few weeks, I don’t feel like an Azure ninja yet. I’m going to continue to build my skills and improve. To do that, I’m going to do a few things.
Keep building demos. Practice makes perfect.
Finish the Pluralsight 70-532 course and watch some of the other advanced Azure courses.
Explore some of the services I didn’t get a chance to play with yet. I still haven’t spent much time working with Azure’s data analytics offerings yet.
Continue to subscribe to various Azure resources like BuildAzure.com and the Azure Weekly newsletter. It’s easier to keep up when the information comes to you.
Seek opportunities to get real life experience with Azure. There’s a big difference between an easy looking demo and actually using something in production.
If I had to start over again, I’d do things a little differently. First, I’d start with the Pluralsight learning paths. The Pluralsight content is free and higher quality than the Udemy content. It’s hard to argue with cheaper AND better. Other than that, I’d have spent more time building things in PowerShell and the C# API instead of using the portal. While most demos occur in the Azure portal, you’re missing out on a big part of what makes Azure cool. Azure makes it easy to represent your infrastructure as code.
My current learning process is a cycle between watching videos, building demos, answering questions, and reading docs. When I learn new things, I alternate consumption, recall, and creation. It’s not fancy, but it works.
If you’re interested in learning more about Azure and cloud technologies, head out to the Azure Docs and check out some of the free Azure training. It’s amazing what we can do with a few credits and some knowledge.
Building web applications is hard work. Not only do you have to build the application, you need to figure out where to host it. Ever want to skip all the frustrating server provisioning and focus on your code? If so, then serverless architecture is worth a look. In this article, you will learn how to build setup a serverless Angular app using Azure.
The term “serverless” is somewhat misleading. There are still servers, but you don’t have to care about them.
Serverless architecture runs on managed services that host your code. Server level concerns like figuring out how much memory you need, fault tolerance, and scalability are abstracted away. You don’t need to pick out a VM or service tier. The service scales automatically. You upload your code and go. The service takes care of the rest.
Serverless platforms come in several different flavors including APIs like Firebase and functions as a service (FAAS). FAAS is where you host small bits of code in the cloud. Think micro-services to the nth degree. All of the major cloud providers have some flavor of FAAS. Examples include: Amazon Lambda, Google Cloud Functions, and Azure Functions. You can even host your own FAAS using OpenFAAS, though that kinda defeats the point. (comprehensive list of serverless platforms)
For the purposes of this application, we are going to use Azure Functions for our backend API.
While Angular application are complex to develop, they compile into a handful of static files. There’s no reason you can’t throw these files up on any commodity static host. In this case, we’re going to use Azure Web Sites. While this solution isn’t 100% serverless, (you have to pick a hosting tier) hosting a handful of files on the free tier is close enough for me. To add another layer of performance, we’re also going to use Azure CDN to cache the files so they load quickly.
Here’s what we’re going to do:
We start off by creating a new Azure Function app. Starting from the Azure Portal, click “New” search for “function” and click Function App. This will bring you to the new function app blade. Type in your app name (it has to be unique), add the rest of your info and click Create.
Now we’re going to make a function. Either hit the plus sign or click “New Function”. This brings you to the function template screen before. Functions can be activated by a variety of triggers including DB requests, files, and manual activation. We’re going to use the HTTP Trigger. HTTP triggers are activated by an HTTP request. Select “HttpTrigger – C#”.
You should now have this lovely boilerplate. This code can handle any http request and sends back a response.
Let’s ditch that boilerplate and drop in our API code. This is just going to be a simple GET request. Feel free to pretend we’re calling a database here instead of just returning a list.
If you’d like to test your shiny new function, click the “get function url” link and drop that into Postman. As you can see here, things are working splendidly.
You can also test using the built-in testing utility on the right side of the function window.
Now that we have our backend setup, let’s put together our front end. In this case, we’re going to set up an Angular application built with the Angular CLI. Since this post is about setting up the architecture, I’m not going to go into great detail about the application itself, which can be found in this github repo. If you’re using another front-end library like React or Vue.js, this setup should be mostly the same.
To begin, create an Azure Web App. (New -> Web App). The free tier should be adequate for our needs. We’re just hosting a few files. If you want to use your own custom domain, you’ll need to use a higher tier.
Now we need to get the static files to host. If you’re using Angular CLI (and you should be…), the command to do this is:
ng build --prod --aot
After that command runs, head over to the dist folder of your angular app. It should look something like this:
The next step is to get your static files into the web app. I used FTP, though you can download a publish profile if you want. Drop your static files into the wwwroot folder. At this point, you should be able go to the URL and your app will load.
The next step is to set up a CDN. Since these are just static files, we can use a CDN to serve them. Azure CDN also allow us to serve the site over https without having to pay for a plan that supports SSL. To set one up, go to New, search “CDN”, click “CDN”, and click “Create”.
This brings up the CDN profile blade. Type in your name, select “Standard” for your pricing tier, and select your web site from the dropdown. Then click “Create”. Now you have a CDN for your static files.
Now that we have our web app in place, we need to set up the CORS (cross origin resource sharing) headers on our function. Browsers, by default, prevent your website from accessing APIs that don’t match the url of your web application (CORS error pictured below). This feature helps to prevent Cross Site Request Forgery (CSRF) attacks, but is sometimes kind of annoying. If you want to use your function API from your web application, you’ll need to add a CORS header to your API.
To begin, go back to your function app and go to the “Platform features” tab and click “CORS”.
This brings you to the CORS screen. Add the url/s of your web app. You can use “*”, which is the wildcard route, but you shouldn’t because it’s rather insecure. It’s best to use your web app’s URL here.
At this point, we have a functioning web application, but there’s still one more issue to resolve. Like most SPA applications, Angular supports client side urls that don’t correspond to server-side resources. All of our application code is served from index.html on the root url, but we use the Angular router to map urls to parts of the application. For example, in our sample app, if we navigate from the home page to the Products page it works great, but if we hit refresh we get a 404. (error below) This is because there’s no page on the server for that URL. To fix this we need to add a URL re-write rule to redirect anything that’s not a static asset back to the index page.
To do this, we’re going to create a web.config file with our rewrite rule.
Here’s our rule (finished product):
This rule takes anything that isn’t a file, directory, or an asset (*.html, *.js, *.css) and redirects it to the index page. If you have fonts or images in your application, you should probably add rules for those file extensions as well.
Then, take that web.config file and drop it into the wwwroot folder of our web app. App urls should now redirect appropriately.
If you’d like to build an Angular application and host it for cheap in the cloud, this is a great way to do it. The serverless architecture is great for MVPs, simple applications, and proof of concept applications. It’s an easy way to get code into the world with minimum fuss.
If you’d like additional information or access to the code referenced in this post, check out the links below.