Presentations
Network monitoring is key to understanding your infrastructure, whether that's your home network or a thousand-seat corporate environment. The Zeek network monitor helps you turn the packets in your network into streams of actionable logs, organized around protocols and themes that matter to you. In this talk I'll give an overview of Zeek, its architecture and capabilities, and the broader Zeek project.
To Kubernetes or not to Kubernetes, that is the question. While it is frequently used in large and complex situations, many prospective users feel it is therefore too large or complex for their needs. If you're just starting a new project, or even maybe a new startup, should you use Kubernetes? I say yes! Newer tools like K3s which allow building minimalist environments have made it much easier to run in a "I just want some containers" mode. This opens the door to starting on a small Kubernetes setup and being able to slowly grow it over time as your requirements and complexity increase.
Distributed systems are made of many components, including authentication, persistence, stateless services, load balancers, and stateful coordination. Coordinating services are essential to system operation, performing tasks such as maintaining configuration state, ensuring service availability, and storing metadata. Raft is a consensus algorithm, and Apache Zookeeper is a centralized service for distributed synchronization and group services. This talk shares a generic example of stateful coordination service moving from Zookeeper to Raft.
It was 2004 when I started writing what then became Jenkins at Sun Microsystems. In hindsight, this was a part of the beginning of what later evolved into "developer productivity".
That evolution took 20 years, and is still in the making. I saw this up close, first at an OSS project (Jenkins), then at a vendor (CloudBees), and now at a different company (Launchable).
I'd like to share what I saw in this journey, how developer productivity evolved, and where it's going. I'd like to show you different teams I've come across, who are at different stages.
At VitalSource, we paired with Pythian to design a high-availability system using Orchestrator, consul, and ProxySQL that was specific to our environment.
Stop recovering backups to setup replicas. There's no need to manually configure replication users or channels. Done with using third party software to achieve high availability. Avoid spending time to automate these steps just to achieve high availability. There's a better, standardized way to meet your business continuity requirements. MySQL has several solutions that make it easy to setup various database architectures and achieve high availability. With just a few commands these architectures can be setup, from provisioning databases to setup replication and automatic failove
Network Time Foundation: the NTP, LinuxPTP, SyncE, Khronos, and General Timestamp API Projects. The NTP, PTP/SyncE, Time Source, and GTSAPI Consortiums. Any other related topics you might care to chat about!
Students can come by at any time. They will have opportunities to learn about:
Prosthesis Design: Learn how to build a simple arm extender using a kit that they can take home.
Paper Circuits: Use colorful paper, copper tape, LEDs, sensors, and batteries to make your own light-up creation.
Disassembly Academy: Take apart hard drives, computers, appliances to find out how they work.
Fax Machine Activity: Learn how images are represented in computers.
Snap circuits and Turing Tumble: Follow instructions to build multiple projects using either Snap Circuits or Turing Tumble.
Observability Trends: Pipelines or Platforms? How can we reduce MTTR?
Being On-Call in software is not as clearly defined as other industries. The start-up nature of things has led to companies implementing emergency Call in myriad ways, because there are advantages to picking what works for your small org with little-to-few IT/Ops staff. Blameless was such a company once upon a time, with SRE making up most of a single monolithic rotation for anything that went wrong. To keep up with scaling the operation, we worked many months to introspect how we could repair our painful rotation and implement continuous improvement, while making On-Call less painful.