Speaking at the PowerShell and DevOps Global Summit 2019

Disclaimer: The views expressed on here are mine alone and not (necessarily) those of my employer (AWS).

In a few weeks I will be attending the PowerShell and DevOps Global Summit 2019, my fourth PowerShell Summit in as many years since joining Amazon in late 2015. The biggest difference this year is I’m attending as a speaker, presenting on two of my favorite topics, Serverless computing with PowerShell in AWS Lambda and how the Kinesis Agent for Microsoft Windows can help make your logs more useful.

The PowerShell language support in AWS Lambda is one of my favorite topics. It’s no secret that I’m a huge fan of Serverless computing and the operational benefits it can provide to engineering teams. In September 2018, when AWS Lambda launched support for PowerShell Core, it opened the doors for the PowerShell community to leverage the benefits of Serverless computing without switching to another language, and in my opinion, it is a big deal for the PowerShell community. AWS Lambda lets you run code without provisioning or managing servers. It is highly available by default, has automatic scaling and charges you only when your code is executed.

The benefits of AWS Lambda have already existed for developers leveraging other runtimes, such as Python, .NET Core or Node.js, however a lot of developers in the PowerShell community are keen to stay with PowerShell where they can, which can make a lot of sense. For example, at one end of the scale are the developers who want to choose the best language for every situation, and at the other end are those who only ever want to learn and develop in a single language. However there’s often an even more important decision that engineering teams need to make, one of operational excellence. At 2am when your on-call gets woken up by the annoying, horrifying sound of their pager, what language do they want to be troubleshooting? The language they’re the most familiar with? Or the language they only just started to learn because “it was the best language for the situation”? Don’t get me wrong, I’m all for engineers learning as many languages as they can as I believe it makes them a stronger engineer, however when you’re building that next production service, language familiarity for the engineering team has to be part of the decision.

One of the reasons I’m such a big fan of leveraging Serverless, is it’s abstractions. With Serverless, engineering teams can go about choosing the best language for them, their service, and their operational excellence. Customers likely don’t care what language a service is developed in, and they likely don’t care about the engineering team being paged at 2am page for a service outage; they just want the service back online as soon as possible. For a lot of administrators, engineers and developers attending the PowerShell and DevOps Global Summit, PowerShell is likely going to be one of the best operational decisions.

To circle back, having the PowerShell Core language support available in AWS Lambda is a game changer. It opens the door to all the capabilities of AWS and Serverless for PowerShell developers.

Switching focus a little to the Kinesis Agent for Microsoft Windows. I think this agent is one of the best ways for Windows focused engineering teams to start using their logs to deliver service improvements. The plugins included in the default installation allow you to stream your logs and performance counters to services such as Amazon Kinesis or Amazon CloudWatch. Once your data is streamed to these services, you can do almost anything you can think of… stream them into Amazon Elasticsearch, dump them to S3 for both archival and SQL-like queries with Amazon Athena or process them in near-realtime with PowerShell in AWS Lambda. Think about that last one for a second… you can process your logs in a centralized location, with a service that scales automatically, with code you develop, to do almost anything you want. That is a very powerful capability.

Centralizing your logs is a key requirement as you move towards disposable systems. It’s great that when you’re woken up in the middle of the night you can forget about everything and simply terminate the EC2 Instance, allowing it to rebuild and get your service back to an operational state. The downside is that without centralized logs you’ll also lose the data required to help perform a root cause analysis so you can prevent the issue from re-occurring. The Kinesis Agent for Microsoft Windows can help get you out of that situation, while also allowing you to take action from your logs and leveraging them in ways you may never have thought possible.

So there you have it, a little insight into why I wanted to present on these two topics, and why I’m excited to share some knowledge about these services and their capabilities. It’s likely to be a very different experience for me at this years PowerShell and DevOps Global Summit, but it’s one that I’m definitely looking forward to. It will be great to catch up with the community members I’ve gotten to know over the years, and to meet those I haven’t. See you all there in a few short weeks!