Glenn F. Henriksen
Cloud wizard, CTO and teacher
Stavanger, Norway
Glenn F. Henriksen is a mentor and developer from Norway. As the co-founder and CTO of Justify, he gets to build new legal tools for everyone to use, helping to create better communication and less conflict in relationships. He's continuously exploring new tools, processes and technologies, and improving how he and his fellow developers work with code, tasks and projects. He has been a Microsoft Development MVP, a part of the Microsoft Regional Director program and is an ASP.NET Insider and an Azure Advisor. In the past 20+ years he has co-owned two companies, worked as a consultant, manager, support tech, network admin, developer, architect, technical lead and more, but his favorite things are still swapping code for food and building stuff that makes a difference in people’s lives.
Links
Area of Expertise
Topics
Building that glorious monolith. And carving it too.
To microservice or not to microservice, is that really the question? I'd argue that the best way to start a project is by building a monolith. It will give you better results, faster, than running down the microservice path right off the bat. But we've all heard the horror stories from the big ball of mud monolith that slows all development to a crawl. It doesn't have to be that way. There are some well-established patterns and practices that help us build glorious monoliths, where the code is not a big ball of mud or stale and sticky spagetti.
I'll talk about how we've used techniques like Domain Driven Design, eventing, and API design for keeping our monolith ordered and easy to navigate. Keeping the complexity manageable and our development speed fast.
And we'll show you how to carve out the pieces you need, when you need it, to another service - with a minimum of work.
Rise of the machine! Moving from manual to automated.
When your app moves from the prototype stage to production and grows in new and mysterious ways you often find yourself with a lot of parts that must be manually moved every now and again.
For us, that moment was when we wanted to deploy our pull requests into a stand-alone testing environment. This was easy when we had a single application and no dependencies, or we could overwrite the existing dev or test environment.
But now we had multiple services, dependencies between them, identity services, a database or two and cross-services deployments. And we wanted multiple PRs deployed in parallell. Let's just say that things became slightly more complicated...
We are using Azure Web Apps and Azure Functions for a hands-off-PaaS setup. For us, the answer was not "Let's just move everything to Kubernetes" since that would just be an entirely different complexity. Surely, there had to be a way to automate this that didn't require massive amounts of work, an enormous Rube Goldberg machine or a complete re-architecture.
I'm going to take you through the various steps we took to automate the entire process. How we used Infrastructure as Code to manage deployments, GitHub Actions and Azure Functions to trigger work, how we coordinated cross-repo pull requests, handled DNS updates, notified team members and more. And how we kept all this secure. No matter the setup you have, there should be some tips and tricks for you to take home to your own automation.
Awesome Azure Authentication Adventures
You have some web applications and some services deploying to Azure, and you want all the communication to be authenticated and secure. Both from your users and between the different services and from the service to the databases. And without passing usernames and passwords in connection strings and application settings.
Turns out, Azure Active Directory is great at this, but it's not always easy to get it right. We'll go through user authentication, forwarding credentials, asking for consent, securing your APIs, service to service communication, managed identities and database authentication. All of it! How does it work and how can you get secure right away.
Keep your nose out of it. Denying yourself access to production
In today's world of personal data, privacy concerns, malware and just plain bad luck, having access to a production system and production data is simply a Bad Idea. And not just for yourself, but every one. The developers, the database admin, the operations team - none of them should have access to production.
So how can we do that, and at the same time maintain our high rate of releases, our agility and our sanity?
Glenn will go though some principles to follow and also show you in practice how you can create your environment, lock it down and update it, all without human intervention. He will also show you how you can monitor the environment for unauthorized changes. How you can have "emergency hatches" for when you really need access, but in a controlled fashion. Examples will be for Microsoft Azure, but the principles are universal.
In short, if you want to keep your production environment and production data at an arms length, but still so what you need when you need it, this is your session.
That just happened! A look at event-based serverless computing
Distributed applications are now the norm. Distributed across services, servers, across data centers, and across clouds. On different platforms and by different teams.
How do we connect all of these? It turns out that events are a good tool for this. Instead of tight coupling directly between your services, opt for a loose and flexible event based architecture. We'll also connect this further up the stack to functions and lambdas and see how "serverless" computing can be a powerful companion to events, enabling us to create powerful applications very quickly and with a minimum of ceremony. If you want to rapidly build a robust and scalable event-based backend, this session is for you. Glenn will teach you the concepts you need and show you how to put them into practice.
Living on the Edge - putting a bit of the cloud in very small boxes
Internet of Things - this overloaded term that can mean almost anything and nothing at the same time. But still, we're no longer confined to just PCs and servers anymore. There's lots and lots of new devices and opportunities. And your code and run on all of these things.
Azure IoT Edge is a service that enables you to easily deploy your own code to thousands of devices, move intelligence from the cloud and down to the device, including machine learning and analytics. All of this on devices smaller than a Raspberry PI. Having this power at the edge, locally, enables many common IoT scenarios.
We'll look at not only what you can do, but how you can do it. Coming home, you'll have a clear understanding of how IoT Edge can help you and where you can get started.
Why should you care about edge computing?
Recent technologies are enabling a host of new scenarios for doing data collection and analytics much closer to the source, at the "edge" so to speak.
How can using Artificial Intelligence in a cheap device the size of a matchbox change the way you do things? What kind of scenarios does this open up for business owners, enabling new opportunities for you and your company? What are the actual benefits for connecting the cloud and the edge in this way?
I'll give you some examples and demonstrate how Edge Computing can enable new scenarios and new business.
Developing privacy
In this day and age, privacy is important to our customers, and it should be important to you as well! In some cases, you're legally obligated to ensure your user's privacy and to protect their information, but it's increasingly becoming The Right Thing To Do (tm) as well. So how do we do it? Which traps lie in these waters? How do we, as developers, build solutions that protect our users from the start and all the way into the core of our applications. We'll go through patterns and techniques you can directly apply in your work, we'll talk about questions you should be asking your business and help you make privacy a feature of your system and not an afterthought. Without making your life needlessly difficult.
Why your company needs an internal API and what you should do about it
A problem for many companies is that their information and processes is locked down in various software systems. Integrations are hard, often duplicated and multiplied by the number of systems. Changing core systems directly is slow, costly and hard. The complexity increases exponentially and slows the rate of innovation.
Creating a company service platform on top of these core systems can allow for a simpler and faster way of innovating and experimenting. How do we ascend to this Nirvana? By good old-fashioned development. By doing the hard work only once and building services that exposes more and more parts of the internal systems and processes. I’ll show you the why and the how, enabling you to create a robust, scalable and secure service platform for your business.
Where do you want to go tomorrow?
Are you in the place you want to be? Are you moving into unknown territory or thinking about stepping up, but you don't really know how?
We'll talk about the different roles a developer can, and probably will, have in a lifetime, how to handle them, how to prevent some of them and how to get to the ones you want faster. In short, how to manage your career like a proper project and not just wing it all the time.
I'll claim to have picked up some insight in a few different roles, warn you against some of my stupid mistakes and share some experiences I've seen others have. All in all you should get some inspiration and tools to help you decide where to go and how to get there.