NDC Oslo - Conference day 1 - part 2
All right, a bit of sleep and a lot of coffee, NDC day 2 is about to kick off so I've got a little bit of time to continue with the recap of day 1.
When feature flags go bad
This talk by Edith Harbaugh (@Edith_H) followed nicely on the one from Sam Newman and continued his story on feature toggles.
Feature toggles are a way to enable (or disable!) features in a deployed system (or application, or service) in a way that is non-disruptive to the usage of the application. This immediately brings us to the first key point about feature toggles: if you can only toggle at deployment time, it's configuration! Feature toggles are meant to be used on a running system without incurring downtime.
A nice example Edith shared with us is one from PagerDuty, they have certain feature flags around features that improve performance. But they disable them before they go to lunch. Why? Well everybody wants to have lunch in peace and quiet right? This shows us that adopting feature toggles allows you to have control over your live systems.
Although we might think of using feature toggles only as a on-or-off scenario, you can use this mechanism to give some users early access to certain features. Or even make sure some people don't get access (like your competitors!). A feature toggle itself is just a toggle, but the strength of this pattern is that it allows you to use a lot of information about a user to flip a toggle at run-time. Imagine only enabling a feature for people who visit NDC for the first time, are taller than 6 ft. and haven't shaved in a week.... Well you get the point.
What's really important when implementing feature toggles is that they should always be short lived. There is nothing more dangerous than a feature toggle that remains and is suddenly flipped. Ask the people at Knight Capital... oh wait, you can't because they went bankrupt1. When you introduce a feature toggle, you introduce technical debt (the old feature). Be sure to remove them as quickly as possible.
AWS Serverless with .Net core
One of the things I like so much about conferences is that you get to meet the people building the frameworks and tools you are using every day. Norm Johanson is part of the team that builds the AWS tooling for the .Net platform.
The focus of this talk was demonstrating how you can use C# and dotnet core to build functions that run on AWS Lambda. Lambda is the serverless computing platform built by Amazon and for a long time it's only been possible to run NodeJS workloads in there. However since November 2016 it is possible to use dotnet core, so now we can leverage C# to build functions and use the tools we love to do it.
The AWS tooling is supported in VS 2017 (via the extension gallery), VS 2015 (as downloadable package from Amazon) and the dotnet core CLI. The beauty is that the Visual Studio extensions use the dotnet core CLI to do all the work. This also makes it super easy to integrate this in CI pipelines, no Visual Studio install needed or custom PowerShelling involved. The extensions also give you project templates (in both VS and dotnet core CLI) that will help you bootstrap a Lambda function project.
In his demo Norm showed that you can easily deploy the functions to AWS from within Visual Studio. However he was quick to point out that this is nice for getting to know Lambda but you should actually leverage tools like CloudFormation to manage your deployments. AWS does provide a number of ready to use templates (or stacks as they call it) which makes setting that up a lot easier.
When building functions with dotnet core it is important to realise that only netcoreapp1.0 is currently supported because Amazon only wants long-term support platforms. The expectation is that when dotnet core 2.0 is released it will become available relatively soon.
To take this even further, it is also possible to run full ASP.Net Core apps in AWS Lambda! Using API gateway to expose the app you can run a webapp (or WebAPI) completely serverless. Be aware though that all static content is now also being processed by your lambdas so you might want to route those calls directly to S3 (pro-tip!)
Check out the video Q&A with Norm about Lambda here
Recap
So, after day 1 we can already say that the session agenda at NDC is full of good stuff! We've gone from cowboys, to authorization, toggled our way through features and merge conflicts to running applications in serverless environments. And this was just day 1!
What's really great is that everybody here is so relaxed, I've met some cool people and have been able to talk to a bunch of the speakers. My cunning plan2 is also starting to work out and I've recorded a bunch of video Q&A's with the speakers. (Which you can find here)