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.
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.
We work in IT – and while we WORK with computers, we do not always FUNCTION like computers where inputs consistently make the same outputs. Our jobs are mostly theory and design and strategy, with some good old fashioned implementation thrown in – and as skilled knowledge workers, we function best when we respect that our mental and emotional resources matter.
If companies truly want to go FAST, occasionally that requires changing something about the culture of the company. Processes get stale or overly complex, people don’t know why things are the way they are, and everyone wonders at the wisdom of asking too many questions.
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?
All companies are IT companies. Except...not. All companies SHOULD be IT companies, if they're trying to keep up with the weight of their customers' ever-increasing demands for speed and agility. Unfortunately...most companies don't know how to get there - or even what "there" looks like, or how they'd describe it.
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.
Zero fluff.