I don't think I've ever seen a conference open this way. Everybody gathered on the exhibition floor around a stage in the center with a massive screen hanging above it with a countdown timer. When the timer ran out we could hear the intro of the Dire Straits song "Money for nothing", what followed was a very NDC special version of the song! The lyrics were changed to introduce the speakers, really cool!

Once the song was done and the intro video of the NDC organizers was finished it was time for...

The Keynote

And then there was a cowboy on the stage... A what?? Yes, a cowboy. Well he sure looked like one but it was time for Dylan Beattie to kick off NDC Oslo.

What better way to start than asking if there are any questions? Not that he forgot the rest of his presentation and skipped to the end but rather to set the stage (ha ha, pun intended) for what he was going to talk about.

Because if we don't ask questions, we never start figuring anything out and we grind to a halt. Dylan talked a lot about the what drives us as human beings (and us as developers even more) to go forth and find out "hey, can I eat that?"

From there he took us through the process of trying to answer a question. For example, "What is the capital of Norway?" Depending on the context you're asking it in, it can either be Oslo, a ridiculously large number or the letter 'N'.

In the process of answering questions us humans have, along the way, invented some pretty amazing stuff. From fire, books and calculus to boats, rockets and GPS. Toss in the World Wide Web and if you look really close, it was all done in support of answering questions. (To which we all know the ultimate answer is 42)

Dylan had one final piece of advice for us: "Use flatscreens". In the style of Baz Lurhmann's "Wear sunscreen" he told us to go forth, ask why a lot and enjoy NDC Oslo!

Implementing authentication and authorization

In this session by Dominick Baier & Brock Allen the focus was more on authorization than authentication. It turns out that authentication is a relatively simple problem in this space, sure getting it right is a challenge but there are only so many variations.

The trick however is how to do authorization.

From their experiences (and to be honest my own as well), authorization is a very application specific problem, and although there are some reusable mechanisms there are always enough things that make that approach not work.

What happens a lot is that tokens generated by identity providers get abused to store permissions and claims. This leads to very large tokens and put the responsibility of working out what claim means what with the identity provider instead of the application (and it's business domain). For example Delete may mean something completely different in service A than service B, but now you can't differentiate other than to push more permissions in the token.

Instead we should be looking at mapping identity to permissions in the context of the service and it's business domain. That means that this mapping should happen not in the identity provider but in an authorization provider. That provider can be a completely separate service (even centralised for many services) or even an in-memory one that lives inside of the context of the service itself.

Key is that mapping identity to permissions is a domain specific problem and should be solved there.

Serverless: Reality or BS

Serverless systems are one of the main themes here at NDC, and this talk tries to shed some light on the different architectural styles and platforms to build serverless systems. Lynn Langit is an independent cloud architect who has experience building these systems on the well known platforms of Amazon, Google, and Microsoft.

Serverless systems started when AWS Lambda was introduced, or rather when S3 became available. The simplest form of serverless is a static site running from an S3 bucket! Let that sink in for a minute. Because AWS was the first provider to jump in this space they currently have the platform that is furthest ahead compared to Google or Azure. However both of them are catching up rapidly and in case of Azure with some nice features like Logic Functions.

Of course there are some caveats to building serverless platforms. The success largely depends on the type of workload you have. An example is the Australian census. Built as a government IT project, it was way too expensive, delivered too late and when it went live it crashed because millions of people tried to use it at the same time. Two students rebuilt it as part of a hackathon project using AWS lambda and simulated the load. It cost three days and $500 to build and run!

So if you have peak load or run processes on a schedule, serverless computing can help you a long way. Instead of paying for servers sitting idle, you pay for actual usage and don't worry about managing servers (with the additional cost that is involved there)

Also you should be worrying about vendor lock-in. These vendors are good at giving you freebies to get you on board, but once there and you are using many of their services it can become really hard to switch providers. Plan accordingly for this when designing your serverless architecture. Have an exit strategy and consider whether using micro or nano instances would also be a possibility.

Feature branches and toggles

This talk by Sam Newman is about whether you should use feature branches or practice trunk-based development with feature toggles. Hint: it's the latter.

Some good examples of the pain of merging lead us to the research done by the people behind "The state of DevOps" reports. They concluded that practicing trunk-based development leads to faster feature delivery, less problems with integrating changes from many developers and generally better software.

A good contrast was made about using pull requests in open source projects. These projects deal with untrusted committers that submit changes and with the pull request mechanism you as maintainer get much better tools to manage that. However most teams consist of developers who are trusted committers, they're your team mates! Therefore it makes more sense to not use PRs but instead make sure that everybody commits small changes frequently and thereby reduce the pain of integration.

---

Stay tuned for the rest of day 1, soon to follow!