BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Meetup//Meetup Calendar 1.0//EN
CALSCALE:GREGORIAN
METHOD:PUBLISH
NAME:Portland Java User Group (PDX JUG)
X-WR-CALNAME:Portland Java User Group (PDX JUG)
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:event_315504800@meetup.com
SEQUENCE:1
DTSTAMP:20260715T121539Z
DTSTART;TZID=America/Los_Angeles:20260728T173000
DTEND;TZID=America/Los_Angeles:20260728T193000
SUMMARY:AI-Driven Autoscaling: Adding Pods Before the Spike\, Not After
DESCRIPTION:Portland Java User Group (PDX JUG)\nIf you run services on Kub
 ernetes\, you've met the Horizontal Pod Autoscaler and its one big idea: w
 atch CPU\, add pods when it climbs\, drop them when it falls. That sounds 
 fine until you're watching latency spike while CPU sits at a comfortable 2
 5 percent. CPU is rarely the thing that's hurting you. On a JVM service th
 e real pressure is usually heap\, GC pauses\, a saturated thread pool\, or
  a pod that came up 20 seconds ago and still can't serve a request because
  it's warming up. HPA sees none of that\, so it reacts late\, overshoots\,
  and then churns pods up and down while your p95 suffers and your bill doe
 sn't budge.\n\nThis talk is what came out of trying to do better: replacin
 g threshold rules with an autoscaler that learns from real traffic history
  instead of guessing from one metric. I'll cover why reactive scaling figh
 ts you\, what it means to treat scaling as a prediction problem (add capac
 ity at 8:55 for the 9 AM Monday rush\, not at 9:05 once the queue is alrea
 dy backed up)\, and the results we saw: latency down roughly 23 percent\, 
 about a fifth off the cost\, and oscillations cut from fifteen an hour to 
 three. I'll also be straight about the painful parts. A learned scaler nee
 ds weeks of traffic before it's any good\, it will confidently make the wr
 ong call the first time it meets a Black Friday\, and you want firm guardr
 ails plus a boring fallback to plain HPA for when it misbehaves.\n\nAudien
 ce will leave knowing when this is worth the effort\, when it really isn't
 \, and a few ideas for making even a stock autoscaler smarter about the si
 gnals it watches.\n\n**Speaker**\nShalini Sudarsan is a DevOps Engineering
  Leader at KinderCare Learning Companies\, USA. designing reliable\, secur
 e\, and cost-optimized data and AI platforms. A Forbes Technology Council 
 Member\, Fellow of IETE and Women in Engineering (WIE) Oregon section\, sh
 e drives enterprise AI adoption with a governed operating model that speed
 s time-to-market while lowering risk and spend. Shalini’s expertise span
 s BI strategy\, data platform architecture\, MLOps\, observability\, and v
 alue realization. She is known for translating complex engineering into me
 asurable business outcomes. Shalini brings deep technical rigor and busine
 ss expertise in the areas of DevOps and Reliability Engineering.A committe
 d advocate for advancing technology\, Shalini regularly presents at intern
 ational conferences and contributes to IEEE and ACM as a technical reviewe
 r.
URL;VALUE=URI:https://www.meetup.com/pdxjug/events/315504800/
STATUS:CONFIRMED
CREATED:20260701T204438Z
LAST-MODIFIED:20260701T204438Z
CLASS:PUBLIC
END:VEVENT
X-ORIGINAL-URL:https://www.meetup.com/pdxjug/events/ical/
X-WR-CALNAME:Portland Java User Group (PDX JUG)
END:VCALENDAR