6:00 Networking | Food | Drink
6:30 Welcome + Announcements
• 6:30 - 7:00pm: Thomas Hunter, @tlhunter (https://twitter.com/tlhunter), Software Engineer at OpenTable (https://www.opentable.com/start/home)
HTTP API Design Part 1
In this talk we'll take a deep look at HTTP, explore the different HTTP Methods, learn how to represent our data using collection and resource endpoints, and abstract our business logic so all operations can be represented as CRUD operations. We'll also look at different HTTP Status codes as well as request and response headers.
• 7:00 - 7:30pm: Waldemar Quevedo, @wallyqs (https://twitter.com/wallyqs?lang=en), Senior Software Engineer at Apcera (https://www.apcera.com/)
Simplified messaging for microservices with the NATS project
The NATS Server hit its v1.0 milestone last month and there is still a lot in the horizon, specially with the NATS Streaming project which enables at-least-once delivery guarantees gaining increasing popularity. The NATS project from its foundations has had simplicity and performance in mind, and in this talk we'll share about the evolution of the project, its community and how it can help you have a lean microservices architecture.
• 7:30 - 7:45pm: Anthony Romano, @coreos (https://twitter.com/coreos?lang=en), software engineer at CoreOS (https://coreos.com/)
zetcd: Serving ZooKeeper requests with etcd3
A reliable distributed system can have no single point of failure. Since fault tolerance is often regarded as difficult to engineer, usually some general off-the-shelf consensus system does the work of reliably managing data and coordinating processes. These consensus systems typically have similar key-value store semantics but each has a custom API.
At CoreOS we designed and implemented a powerful multi-versioned key-value store for etcd3, the latest major version of our open source etcd distributed data store. Since its initial release in 2013, etcd has become a cornerstone of distributed services for networking, service discovery, configuration management, and load balancing. However, a great deal of critical infrastructure which conceptually could use etcd is locked into other APIs, Apache ZooKeeper being the most popular. Porting these applications to an etcd backend ranges from easy to impractical.
Being too impatient for native backend support, etcd's zetcd proxy instead emulates ZooKeeper. The zetcd proxy is a stateless ZooKeeper frontend; it serves a ZooKeeper client port backed by etcd, letting unmodified ZooKeeper applications run on top of etcd. This talk outlines how zetcd translates ZooKeeper operations to etcd requests and describes how zetcd checks its emulation matches an authentic ZooKeeper cluster.
Email [masked] if you have a suggestion for a topic/talk or if your company would like to sponsor a SF Microservices Meetup!!