Morning everyone, really looking forward to the BoF session today and I will be your BoF session host.

Not going to lie .. hearing about the great work that Adidas have done around multi-cloud adoption .. platform management and engineering and SRE re-assured me that there are a great set of practioners who learn from what has worked for other organisations and adtopt that within the domains of the business. Having done those for a couple of global institutions .. i know how hard and painful that can be. Happy to share experiences and thoughts for anyone interested!

Looking forward to the BoF session @ 1425 BST. Just to address a privacy issue - the session will be held under the "Chatham House Rule" i.e. you can discuss the insights and conclusions you get from the session, but you can't attribute them to a person or company. Sound good?

<!here> there are 72 people in the channel - who is planning to attend the BoF in 15 mins? Thumbs up for yes!

Join Zoom Meeting https://devopsgroup.zoom.us/j/9432149052?pwd=ZFE5V3Z4aGdOemZZQ2VHY1QrYllSZz09 Meeting ID: <tel:9432149052|943 214 9052> Password: Adapt21! One tap mobile <tel:+441314601196,,9432149052#,,,,0#,,735423#|+441314601196,,9432149052#,,,,0#,,735423#> United Kingdom <tel:+442034815237,,9432149052#,,,,0#,,735423#|+442034815237,,9432149052#,,,,0#,,735423#> United Kingdom Dial by your location <tel:+441314601196|+44 131 460 1196> United Kingdom <tel:+442034815237|+44 203 481 5237> United Kingdom <tel:+442034815240|+44 203 481 5240> United Kingdom <tel:+442080806591|+44 208 080 6591> United Kingdom <tel:+442080806592|+44 208 080 6592> United Kingdom <tel:+443300885830|+44 330 088 5830> United Kingdom <tel:08000315717|0 800 031 5717> United Kingdom Toll-free <tel:08002605801|0 800 260 5801> United Kingdom Toll-free <tel:+13462487799|+1 346 248 7799> US (Houston) <tel:+14086380968|+1 408 638 0968> US (San Jose) <tel:+16468769923|+1 646 876 9923> US (New York) <tel:+16699006833|+1 669 900 6833> US (San Jose) <tel:+12532158782|+1 253 215 8782> US (Tacoma) <tel:+13017158592|+1 301 715 8592> US (Germantown) <tel:+13126266799|+1 312 626 6799> US (Chicago) <tel:8778535257|877 853 5257> US Toll-free <tel:8884754499|888 475 4499> US Toll-free Meeting ID: <tel:9432149052|943 214 9052> Password: 735423 Find your local number: https://devopsgroup.zoom.us/u/chZ6yF0IK

We were planning to use Slack but due to limits we'll have to use Zoom, so please jump on the call above!

Jamboard to share your questions, insights, thoughts etc - Jamboard - https://jamboard.google.com/d/10D9mwYtVfFFL_zC7sNH1v8wTKhRqot_M-JYzUJEAw5A/edit?usp=sharing

https://snafucatchers.github.io/

Platform Team Model

this was from the Adidas presentation.

Ja\mboard - https://jamboard.google.com/d/10D9mwYtVfFFL_zC7sNH1v8wTKhRqot_M-JYzUJEAw5A/viewer?f=1

Thank you everyone, that call was so useful for me. Sorry if I hogged the focus a bit, I have a lot to learn!

It was fun! thanks everyone.

@tal 1425 BST tomorrow to talk next-gen-ops!

I'll be there!

@corey - @tal said you might have some views on next-gen-ops so welcome to the channel 🙂

Steve defined it as "how is ops evolving with cloud, devops, SRE"

Sure! Thanks for the tag.

@tal How is it evolving aspirationally, or cynically? 🙂

I'm more interested in aspirationally.

(but cynically would be more fun)

I guess my point re SRE in particular "SRE is what you get when you ask a software engineering to design an ops function"... why did a software engineer get asked to re-design an ops function in the first place? What weren't we doing, as a community, that needed someone else to redefine how we do our jobs? Hence my belief we need an "Ops Manifesto" to articulate what are our core principles, what does ops & operability mean in the 21st Century? So a bit of tilting at windmills probably!

"why did a software engineer get asked to re-design an ops function in the first place?" Because the engineering practices didn't exist in Ops just like they don't exist in Data. Thus you need folks that have experience of engineering systems to get that advancement.

The challenge is Ops has different challenges as does Data and those requirements need to also be brought to the table.

If you try and disrupt banking and have the advisers come from banking, you aren't going to disrupt much.

I’d argue that engineering practices did exist in ops, but that the fundamental nature of ops changed as more things became software drive (thus software engineers getting involved)

For a long time “I’m an ops person” was a translation of “I can’t write code.” It certainly was for me.

That conveyed; when you’re a software engineer you see the world in terms of code. Now that we’re in a Time of Cloud every ops person has to write code.

Curiously I still see myself as “I don’t write code” but I churn out an awful lot of Python for that to still be true.

I agree with @jyee in that I think it's incorrect to say that "engineering" only arrived in Ops with the arrival of software engineers. Yes, it makes sense to learn from software engineers how to write software better since as @corey says software is a key part of the role in today's world.

But it wasn't just "teaching ops how to code". It was to redefine the Ops paradigm as part of Devops. It just feels to me that Ops hasn't had a seat at the table to redefine our own discipline in a modern world.

But it wasn't just "teaching ops how to code". It was to redefine the Ops paradigm as part of Devops. It just feels to me that Ops hasn't had a seat at the table to redefine our own discipline in a modern world.

We’re all still Sysadmins. Calling ourselves that is shorthand for “please underpay me” but the core of the role is and continues to be “keep the app/workload running.” Now that we’re using cloud providers the skillset has shifted somewhat and requires different attributes than it once did.

The challenge culturally and systemically is that Ops has long been the Department of No in some respects for well-intentioned reasons. “No, cloud is bad” was the traditional ops response in many places, so service teams routed around them.

And let’s not kid ourselves. In modern cloud architectures, where is the boundary between dev and ops?

And let’s not kid ourselves. In modern cloud architectures, where is the boundary between dev and ops?

S/sysadmin/devops engineer on your CV is a 20% pay bump 😂

Skip the devops and jump straight to SRE!

Skip the devops and jump straight to SRE!

With regard the engineering comments there are always exceptions and thus I'm looking more at the masses. The engineering I'm referring to is more about the application of software to what is being done. Source control, testing, peer review, it goes beyond infrastructure as code. what I see now is where there is an "Ops team supporting" they need to adopt the deliver mechanism adopted by the application/service and thus need to be more developers than ever. What i see missing is strong enforcement of what good looks like from an operational perspective if teams aren't going to support it themselves. We see systems being delivered all the time that are a nightmare to support, which in todays world is a shocking. Ops teams whether networking, security, data, are shocking about providing the requirements/patterns for teams to follow to enable support, or are a massive blockers to due really poor adoption of DevOps process.

With regard the engineering comments there are always exceptions and thus I'm looking more at the masses. The engineering I'm referring to is more about the application of software to what is being done. Source control, testing, peer review, it goes beyond infrastructure as code. what I see now is where there is an "Ops team supporting" they need to adopt the deliver mechanism adopted by the application/service and thus need to be more developers than ever. What i see missing is strong enforcement of what good looks like from an operational perspective if teams aren't going to support it themselves. We see systems being delivered all the time that are a nightmare to support, which in todays world is a shocking. Ops teams whether networking, security, data, are shocking about providing the requirements/patterns for teams to follow to enable support, or are a massive blockers to due really poor adoption of DevOps process.

I’m not as sold. “Do the DevOps better and your problem goes away” is a great sales pitch for the DevOps, but it’s not… actionable, in a lot of shops.

I’m not as sold. “Do the DevOps better and your problem goes away” is a great sales pitch for the DevOps, but it’s not… actionable, in a lot of shops.

Definitely not

for me its the responsibility thing that needs to be addressed

If you have an Ops approach, but the responsibility is defined wrong then your Ops will be a dumping ground

What is Ops?

What is Ops?

Is it the specialists that aren't "Devs"

@simon exactly "what is Ops?" that's the $64K question. And my frustration is that Ops currently seems to be defined by "what's left over" rather than us proactively redefining what Ops/CloudOps/OpsDev/AgileOps whatever you want to label should mean in the 21st Century.

I like the definition that Ops is the people using our tools to run the business. Dev is everyone supplying those tools. 🙂