Category: 3-SometimeTechTalk

We kick things off by weighing the merits of two gender-neutral regional pronouns: the familiar y’all and the under appreciated yinz. Now that’s covered...

The global population of developers will hit 45 million by 2030, up from 26.9 million in 2021 (EDC). What platforms will they want to build on?

Did Kubernetes solve all your problems? Did it create new ones?

It seems there’s always an XKCD relevant to our conversation. Today, it’s How standards proliferate.

Maxwell, a solution architect at xMatters, took a winding road to get to where he is. After a computer engineering education, he held jobs as field support engineer, product manager, SRE, and finally his current role as a solutions architect, where he serves as something of an SRE for SREs, helping them solve incident management problems with the help of xMatters. 

When he moved to the SRE role, Maxwell wanted to get back to doing technical work. It was a lateral move within his company, which was migrating an on-prem solution into the cloud. It’s a journey that plenty of companies are making now: breaking an application into microservices, running processes in containers, and using Kubernetes to orchestrate the whole thing. Non-production environments would go down and waste SRE time, making it harder to address problems in the production pipeline. 

At the heart of their issues was the incident response process. They had several bottlenecks that prevented them from delivering value to their customers quickly. Incidents would send emails to the relevant engineers, sometimes 20 on a single email, which made it easy for any one engineer to ignore the problem—someone else has got this. They had a bad silo problem, where escalating to the right person across groups became an issue of its own. And of course, most of this was manual. Their MTTR—mean time to resolve—was lagging. 

Maxwell moved over to xMatters because they managed to solve these problems through clever automation. Their product automates the scheduling and notification process so that the right person knows about the incident as soon as possible. At the core of this process was a different MTTR—mean time to respond. Once an engineer started working to resolve a problem, it was all down to runbooks and skill. But the lag between the initial incident and that start was the real slowdown. 

It’s not just the response from the first SRE on call. It’s the other escalations down the line—to data engineers, for example—that can eat away time. They’ve worked hard to make  escalation configuration easy. It not only handles who's responsible for specific services and metrics, but who’s in the escalation chain from there. When the incident hits, the notifications go out through a series of configured channels; maybe it tries a chat program first, then email, then SMS. 

The on-call process is often a source of dread, but automating the escalation process can take some of the sting out of it. Check out the episode to learn more. 

Maxwell, a solution architect at xMatters, took a winding road to get to where he is. After a computer engineering education, he held jobs as field support engineer, product manager, SRE, and finally his current role as a solutions architect, where he serves as something of an SRE for SREs, helping them solve incident management problems with the help of xMatters. 

When he moved to the SRE role, Maxwell wanted to get back to doing technical work. It was a lateral move within his company, which was migrating an on-prem solution into the cloud. It’s a journey that plenty of companies are making now: breaking an application into microservices, running processes in containers, and using Kubernetes to orchestrate the whole thing. Non-production environments would go down and waste SRE time, making it harder to address problems in the production pipeline. 

At the heart of their issues was the incident response process. They had several bottlenecks that prevented them from delivering value to their customers quickly. Incidents would send emails to the relevant engineers, sometimes 20 on a single email, which made it easy for any one engineer to ignore the problem—someone else has got this. They had a bad silo problem, where escalating to the right person across groups became an issue of its own. And of course, most of this was manual. Their MTTR—mean time to resolve—was lagging. 

Maxwell moved over to xMatters because they managed to solve these problems through clever automation. Their product automates the scheduling and notification process so that the right person knows about the incident as soon as possible. At the core of this process was a different MTTR—mean time to respond. Once an engineer started working to resolve a problem, it was all down to runbooks and skill. But the lag between the initial incident and that start was the real slowdown. 

It’s not just the response from the first SRE on call. It’s the other escalations down the line—to data engineers, for example—that can eat away time. They’ve worked hard to make  escalation configuration easy. It not only handles who's responsible for specific services and metrics, but who’s in the escalation chain from there. When the incident hits, the notifications go out through a series of configured channels; maybe it tries a chat program first, then email, then SMS. 

The on-call process is often a source of dread, but automating the escalation process can take some of the sting out of it. Check out the episode to learn more. 

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

Maxwell, a solution architect at xMatters, took a winding road to get to where he is. After a computer engineering education, he held jobs as field support engineer, product manager, SRE, and finally his current role as a solutions architect, where he serves as something of an SRE for SREs, helping them solve incident management problems with the help of xMatters. 

When he moved to the SRE role, Maxwell wanted to get back to doing technical work. It was a lateral move within his company, which was migrating an on-prem solution into the cloud. It’s a journey that plenty of companies are making now: breaking an application into microservices, running processes in containers, and using Kubernetes to orchestrate the whole thing. Non-production environments would go down and waste SRE time, making it harder to address problems in the production pipeline. 

At the heart of their issues was the incident response process. They had several bottlenecks that prevented them from delivering value to their customers quickly. Incidents would send emails to the relevant engineers, sometimes 20 on a single email, which made it easy for any one engineer to ignore the problem—someone else has got this. They had a bad silo problem, where escalating to the right person across groups became an issue of its own. And of course, most of this was manual. Their MTTR—mean time to resolve—was lagging. 

Maxwell moved over to xMatters because they managed to solve these problems through clever automation. Their product automates the scheduling and notification process so that the right person knows about the incident as soon as possible. At the core of this process was a different MTTR—mean time to respond. Once an engineer started working to resolve a problem, it was all down to runbooks and skill. But the lag between the initial incident and that start was the real slowdown. 

It’s not just the response from the first SRE on call. It’s the other escalations down the line—to data engineers, for example—that can eat away time. They’ve worked hard to make  escalation configuration easy. It not only handles who's responsible for specific services and metrics, but who’s in the escalation chain from there. When the incident hits, the notifications go out through a series of configured channels; maybe it tries a chat program first, then email, then SMS. 

The on-call process is often a source of dread, but automating the escalation process can take some of the sting out of it. Check out the episode to learn more. 

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

Shinji Kim was born in Korea. Her family moved to Canada when she was 13 years old. She likes to hang out with her friends, watch movies and likes to be outdoors, skiing, hiking or doing yoga. She recently tore her ACL, though, which has put a damper on her physical activity. While she studied at the University of Waterloo, she was able to work with many different well known companies - Facebook, Sun Microsystems and Barclays. In 2014, she started her first company called Concord Systems, focusing on distributed stream processing. This was eventually acquired by Akamai, the largest CDN network in the world. We joked about the day it went down, cause it fell like the digital world went dark.

At Akamai, she worked with large enterprises and saw that there was a problem around data discovery, and that it was growing in the middle market, as more companies migrated to the cloud. She decided to build an automated way for users to discovery and understand their data.

This is the creation story of Select Star.

Sponsors

• Courier
• Img.ly
• Routable
• CTO.ai
• Cloudways offers peace of mind and flexibility so you can focus on growing your business instead of dealing with server management. With Cloudways, you get an optimized stack, managed servers, backups, staging environment, integrated Git, pre-configured, Composer, 24/7 support, and a choice of five cloud providers: AWS, DigitalOcean, Linode, Google Cloud, and Vultr. Get up to 2 Month Free Hosting by using code "CODE30" and get $30 free hosting credit.

Links

• Website: https://selectstar.com/
• LinkedIn: https://www.linkedin.com/in/shinjikim/

Our Sponsors:
* Check out Vanta: https://vanta.com/CODESTORY


Support this podcast at — https://redcircle.com/code-story/donations

Advertising Inquiries: https://redcircle.com/brands

Privacy & Opt-Out: https://redcircle.com/privacy

Adrian Tobey lives in Canada. He got started in his tech career right out of high school, working for his father's digital marketing agency. In high school, he was interested in computer science, and developed video games and useful UI for his school. Prior to digital marketing, his father was a jazz musician, and Adrian followed in those footsteps to play the trumpet. For University, he had two options - go to school for computer science or for music... and chose the latter. During school, he was working full time for his Dad's agency, building websites, email campaigns and such. While he was doing this, he built his first product called Form Lift, which is a Wordpress form builder for Infusion Soft.

Around 3 years into school, he failed his first university course - a discrete computer science course around computer runtimes, big O notation, etc. He had invested a ton of money into the his degree already, but he started doing the math, and estimated he wouldn't complete school until 2025 because he was part time.

With that in mind, he dropped out of University school, and thought - what next? He didn't want to do agency work forever. He took a look at how expensive, convoluted and clunky marketing technology tools can be. He vowed to create the ultimate suite of tools, and to do it on Wordpress.

This is the creation story of Groundhogg.

Sponsors

• Courier
• Img.ly
• Routable
• CTO.ai
• Cloudways offers peace of mind and flexibility so you can focus on growing your business instead of dealing with server management. With Cloudways, you get an optimized stack, managed servers, backups, staging environment, integrated Git, pre-configured, Composer, 24/7 support, and a choice of five cloud providers: AWS, DigitalOcean, Linode, Google Cloud, and Vultr. Get up to 2 Month Free Hosting by using code "CODE30" and get $30 free hosting credit.

Links

• Website: https://www.groundhogg.io/
• LinkedIn: https://www.linkedin.com/in/adriantobey

Our Sponsors:
* Check out Vanta: https://vanta.com/CODESTORY


Support this podcast at — https://redcircle.com/code-story/donations

Advertising Inquiries: https://redcircle.com/brands

Privacy & Opt-Out: https://redcircle.com/privacy

Links from the show:

• [RFC] Deprecate dynamic properties - Externals
• The PHP Song 4K (extended version directors cut) - YouTube
• Staples Center becomes Crypto.com Arena in name rights deal - Los Angeles Times
• Explaining Everything StreamlabsOBS allegedly plagiarized
• A Spicy Take on the "Old PHP" Posts : PHP
• https://twitter.com/tuckerschreiber/status/1460836336231931908
• PHP Foundation - Open Collective

This episode of PHPUgly was sponsored by:

• Honeybadger.io - https://www.honeybadger.io/

PHPUgly streams the recording of this podcast live. Typically every Thursday night around 9 PM PT. Come and join us, and subscribe to our Youtube Channel, Twitch, or Periscope. Also, be sure to check out our Patreon Page.

Twitter Account https://twitter.com/phpugly

Host:

• Eric Van Johnson
• John Congdon
• Tom Rideout

Streams:

• Youtube Channel
• Twitch
• Periscope

Powered by Restream

Patreon Page

PHPUgly Anthem by Harry Mack / Harry Mack Youtube Channel

Thanks to all of our Patreon Sponsors:

Honeybadger ** This weeks Sponsor **

ButteryCrumpet
Shawn
David Q
Ken F
Tony L
Frank W
Jeff K
Shelby C
S Ferguson
Boštjan O
Matt L
Dmitri G
Knut E B
Marcus
MikePageDev
Rodrigo C
Billy
Darryl H
Blaž O
Mike W
Holly S
Peter A
Ben R
Luciano N
Elgimbo
Wayne
Kevin Y
Alex B
Clayton S
Kenrick B
R. C. S.
ahinkle
Enno R
Sevi
Maciej P
Jeroen F
Ronny M N
Charlto
F'n Steve
Robert
Thorsten
Emily
Joe F
Andrew W
ulrick ** New Patreon Supporter **

You can learn more about Roll, which describes itself as blockchain infrastructure for social money, here.

If you want to follow them on social, check out @tryrollhq as well as their personal socials: @bradley_miles_ and @sidkal. 

If you are interested in this kind of tech, check out previous conversations on Web3 and our chat with Chris Dixon on blockchain.

Our lifeboat badge winner of the week is Notnooop, who explained how you can :Make An Emoji Enabling App