JoshSmith
Josh has been in in IT for 15 years, as a developer, lead dev, tech lead, architect, and enterprise architect. He's worked on big teams, small teams, and been on a team of one. In the process of all of this, he's learned a ton, and he loves to mentor and share that information.
He also loves strategy – laying out plans and figuring out dependencies, which order to do things in. Included in this is a deep love of the complicated business + people + culture + tech (especially tech that makes people's lives easier) of IT strategy.
There is pain inherent in development - monoliths, confusing deployment processes, conflict between dev/ops/business.
The hardest parts of technology are people and what they do - so, _culture_ and _process_. In the center of that is how to determine the right amount of oversight when implementing technology or the processes around that technology. That "right amount of oversight" is typically referred to as "governance."
Want to bring in [new cool thing X] or [necessary technology change Y] to your company, because you know there's a need for it? GOOD IDEA! Except...now what? If your company is more than about 3 people, how do you explain, enable, and encourage the adoption of this change, especially if it will require some work on everyone’s part?
Containers enable rapid development and rapid software delivery - and with that increase in speed comes a need to shift how people think about and tackle security. Running those containers is part of this consideration - the platform and container orchestration has to figure out and handle all of the moving parts.
Serverless! Functions as a service! DIGITAL TRANSFORMATION! ...just kidding. One of the ideas in IT that's been gathering buzz for a while is "serverless." Or sometimes "functions as a service," used interchangeably. And...okay, but what does that actually _mean_? And...how does it help what you're trying to accomplish in your organization?
A long time ago, in a land far far away, there were monoliths. These fabled artifacts brought consistency and stability to the land - but there was a cost in speed, agility, time, and development pain. Whether Java EE, .NET, or something else, the big ol' integrated plexi-purpose binaries or yore (and also now...) have grown into problems that hurt developers, architects, and the execution of business goals.
We have systems that can tell us in some amount what's wrong with them, but the sheer volume of data, and the sheer volume of systems, make it so that we can't do anything useful with (all of!) that information.
There is pain inherent in development - monoliths, confusing deployment processes, conflict between dev/ops/security/business... IT is complicated, and hard to do well, and the pace of change expected by customers makes it all even MORE difficult.
Zero fluff.