Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1A8pJF6.
Armon Dadgar presents Consul, a distributed control plane for the datacenter. Armon demonstrates how Consul can be used to build, configure, monitor, and orchestrate distributed systems. Filmed at qconsf.com.
Armon Dadgar has a passion for distributed systems and their application to real world problems. He is currently the CTO of HashiCorp, where he brings distributed systems into the world of DevOps tooling.
Consul: Microservice Enabling Microservices and Reactive ProgrammingRick Hightower
Consul is a service discovery system that provides a microservice style interface to services, service topology and service health.
With service discovery you can look up services which are organized in the topology of your datacenters. Consul uses client agents and RAFT to provide a consistent view of services. Consul provides a consistent view of configuration as well also using RAFT. Consul provides a microservice interface to a replicated view of your service topology and its configuration. Consul can monitor and change services topology based on health of individual nodes.
Consul provides scalable distributed health checks. Consul only does minimal datacenter to datacenter communication so each datacenter has its own Consul cluster. Consul provides a domain model for managing topology of datacenters, server nodes, and services running on server nodes along with their configuration and current health status.
Consul is like combining the features of a DNS server plus Consistent Key/Value Store like etcd plus features of ZooKeeper for service discovery, and health monitoring like Nagios but all rolled up into a consistent system. Essentially, Consul is all the bits you need to have a coherent domain service model available to provide service discovery, health and replicated config, service topology and health status. Consul also provides a nice REST interface and Web UI to see your service topology and distributed service config.
Consul organizes your services in a Catalog called the Service Catalog and then provides a DNS and REST/HTTP/JSON interface to it.
To use Consul you start up an agent process. The Consul agent process is a long running daemon on every member of Consul cluster. The agent process can be run in server mode or client mode. Consul agent clients would run on every physical server or OS virtual machine (if that makes more sense). Client runs on server hosting services. The clients use gossip and RPC calls to stay in sync with Consul.
A client, consul agent running in client mode, forwards request to a server, consul agent running in server mode. Clients are mostly stateless. The client does LAN gossip to the server nodes to communicate changes.
A server, consul agent running in server mode, is like a client agent but with more tasks. The consul servers use the RAFT quorum mechanism to see who is the leader. The consul servers maintain cluster state like the Service Catalog. The leader manages a consistent view of config key/value pairs, and service health and topology. Consul servers also handle WAN gossip to other datacenters. Consul server nodes forwards queries to leader, and forward queries to other datacenters.
A Datacenter is fairly obvious. It is anything that allows for fast communication between nodes, with as few or no hops, little or no routing, and in short: high speed communication. This could be an Amazon EC2 availability zone, a networking environment like a subnet, or any private, low latency, high
This talk will guide you through the first steps to understand Consul and do some cool stuff with it.
You also have a live Vagrant demo available in github at https://github.com/lynxman/consul-first-steps
Infrastructure development using ConsulGrid Dynamics
In his talk, Volodymyr Tselm, DevOps Engineer at Grid Dynamics, tells about Consul, service discovery and DNS, fast-deploy development environment using Consul.
Lightning talk about Consul showing the main features and explaining the basis of its acrchitecture. The code of the demo can be found on my github. https://github.com/toff63/consul-cluster
Service discovery in a microservice architecture using consulJos Dirksen
Presentation I gave at Nextbuild 2016. Gives an overview of how Consul can be used in microservice architecture. Accompanying examples and demo can be found here: https://github.com/josdirksen/next-build-consul
A systematic overview of Consul's different network models, how they work, what kind of use cases they serve, and how prepared queries can help provide glue to keep service discovery simple across all.
Consul: Microservice Enabling Microservices and Reactive ProgrammingRick Hightower
Consul is a service discovery system that provides a microservice style interface to services, service topology and service health.
With service discovery you can look up services which are organized in the topology of your datacenters. Consul uses client agents and RAFT to provide a consistent view of services. Consul provides a consistent view of configuration as well also using RAFT. Consul provides a microservice interface to a replicated view of your service topology and its configuration. Consul can monitor and change services topology based on health of individual nodes.
Consul provides scalable distributed health checks. Consul only does minimal datacenter to datacenter communication so each datacenter has its own Consul cluster. Consul provides a domain model for managing topology of datacenters, server nodes, and services running on server nodes along with their configuration and current health status.
Consul is like combining the features of a DNS server plus Consistent Key/Value Store like etcd plus features of ZooKeeper for service discovery, and health monitoring like Nagios but all rolled up into a consistent system. Essentially, Consul is all the bits you need to have a coherent domain service model available to provide service discovery, health and replicated config, service topology and health status. Consul also provides a nice REST interface and Web UI to see your service topology and distributed service config.
Consul organizes your services in a Catalog called the Service Catalog and then provides a DNS and REST/HTTP/JSON interface to it.
To use Consul you start up an agent process. The Consul agent process is a long running daemon on every member of Consul cluster. The agent process can be run in server mode or client mode. Consul agent clients would run on every physical server or OS virtual machine (if that makes more sense). Client runs on server hosting services. The clients use gossip and RPC calls to stay in sync with Consul.
A client, consul agent running in client mode, forwards request to a server, consul agent running in server mode. Clients are mostly stateless. The client does LAN gossip to the server nodes to communicate changes.
A server, consul agent running in server mode, is like a client agent but with more tasks. The consul servers use the RAFT quorum mechanism to see who is the leader. The consul servers maintain cluster state like the Service Catalog. The leader manages a consistent view of config key/value pairs, and service health and topology. Consul servers also handle WAN gossip to other datacenters. Consul server nodes forwards queries to leader, and forward queries to other datacenters.
A Datacenter is fairly obvious. It is anything that allows for fast communication between nodes, with as few or no hops, little or no routing, and in short: high speed communication. This could be an Amazon EC2 availability zone, a networking environment like a subnet, or any private, low latency, high
This talk will guide you through the first steps to understand Consul and do some cool stuff with it.
You also have a live Vagrant demo available in github at https://github.com/lynxman/consul-first-steps
Infrastructure development using ConsulGrid Dynamics
In his talk, Volodymyr Tselm, DevOps Engineer at Grid Dynamics, tells about Consul, service discovery and DNS, fast-deploy development environment using Consul.
Lightning talk about Consul showing the main features and explaining the basis of its acrchitecture. The code of the demo can be found on my github. https://github.com/toff63/consul-cluster
Service discovery in a microservice architecture using consulJos Dirksen
Presentation I gave at Nextbuild 2016. Gives an overview of how Consul can be used in microservice architecture. Accompanying examples and demo can be found here: https://github.com/josdirksen/next-build-consul
A systematic overview of Consul's different network models, how they work, what kind of use cases they serve, and how prepared queries can help provide glue to keep service discovery simple across all.
Docker Service Registration and Discoverym_richardson
This talk covers some basic concepts of Service Registry and Discovery with Docker. Consul, Registrator and consul-template are discussed.
It was presented at the Sydney Docker meetup in April 2015
Altitude SF 2017: Nomad and next-gen application architecturesFastly
Armon Dadgar offers an overview of Nomad, an application scheduler designed for both long-running services and batch jobs. Along the way, Armon explores the benefits of using schedulers for empowering developers and increasing resource utilization and how schedulers enable new next-generation application architectures.
PostgreSQL High-Availability and Geographic Locality using consulSean Chittenden
Virtual IPs or floating IPs have long been the workhorse mechanism for providing high-availability for database systems, however floating IP addresses have several limitations that make it problematic in modern data centers and cloud environments, notably that it requires all members be in the same Layer-2 domain. consul is a strongly consistent way of providing high-availability services in Layer-3 environments and provides fail-over across different geographic regions. In this talk we will discuss the benefits, setup, and use of consul for fail-over of PostgreSQL, both in a local data center scenario and a geographic redundancy scenario where databases are split across multiple data centers.
Altitude SF 2017: Advanced VCL: Shielding and ClusteringFastly
Shielding and clustering are two techniques that help in various ways, including increasing cache hit ratio and allowing for more effective storage. If used incorrectly, however, both can make your life more difficult. In this session, Fastly Engineer Rogier “Doc” Mulhuijzen will discuss how to deal with these prickly yet critical techniques, ultimately changing the way you think about writing VCL.
Container monitoring for resource and application metrics with cAdvisor. Shipping monitoring information with the container so it is monitored irrespective of the host it runs on.
Intro to monitoring in distributed systems, cAdvisor, heapster, kubedash, kubernetes
Orchestrating Docker with Terraform and Consul by Mitchell Hashimoto Docker, Inc.
Terraform is a tool for building and safely iterating on infrastructure, while Consul provides service discovery, monitoring and orchestration. In this talk we discuss using Terraform and Consul together to build a Docker-based Service Oriented Architecture at scale. We use Consul to provide the runtime control plane for the datacenter, and Terraform is used to modify the underlying infrastructure to allow for elastic scalability.
WebSocket MicroService vs. REST MicroserviceRick Hightower
Comparing the speed of RPC calls over WebScoket Microservices versus REST based microservices. Using wrk, QBit, and examples in Java we show how much faster WebSocket is for doing RPC service calls.
With the increasing maturity of OpenStack Neutron, and increasing support for a large number of services , we'll examine how SDNs can leverage the container technology for supporting "as a Service" components.
So you want to auto scale your services, and use service oriented architecture, eh?
Want to reduce the cost of managing your clusters, and discover them dynamically?
In this talk we shall see how consul helps you do that very efficiently, demonstrate spinning up several interconnected services, and show how we can achieve seamless discovery, HA, and fault tolerance.
Heart of the SwarmKit: Store, Topology & Object ModelDocker, Inc.
Heart of the SwarmKit: Store, Topology & Object Model by Aaron, Andrea, Stephen D (Docker)
Swarmkit repo - https://github.com/docker/swarmkit
Liveblogging: http://canopy.mirage.io/Liveblog/SwarmKitDDS2016
Service Discovery using etcd, Consul and KubernetesSreenivas Makam
Overview of Service Discovery and Service Discovery using etcd, Consul, Kubernetes and Docker. Presented at Open source meetup, Bangalore(http://www.meetup.com/Bangalore-Open-Source-Meetup/events/229763724/)
Docker Service Registration and Discoverym_richardson
This talk covers some basic concepts of Service Registry and Discovery with Docker. Consul, Registrator and consul-template are discussed.
It was presented at the Sydney Docker meetup in April 2015
Altitude SF 2017: Nomad and next-gen application architecturesFastly
Armon Dadgar offers an overview of Nomad, an application scheduler designed for both long-running services and batch jobs. Along the way, Armon explores the benefits of using schedulers for empowering developers and increasing resource utilization and how schedulers enable new next-generation application architectures.
PostgreSQL High-Availability and Geographic Locality using consulSean Chittenden
Virtual IPs or floating IPs have long been the workhorse mechanism for providing high-availability for database systems, however floating IP addresses have several limitations that make it problematic in modern data centers and cloud environments, notably that it requires all members be in the same Layer-2 domain. consul is a strongly consistent way of providing high-availability services in Layer-3 environments and provides fail-over across different geographic regions. In this talk we will discuss the benefits, setup, and use of consul for fail-over of PostgreSQL, both in a local data center scenario and a geographic redundancy scenario where databases are split across multiple data centers.
Altitude SF 2017: Advanced VCL: Shielding and ClusteringFastly
Shielding and clustering are two techniques that help in various ways, including increasing cache hit ratio and allowing for more effective storage. If used incorrectly, however, both can make your life more difficult. In this session, Fastly Engineer Rogier “Doc” Mulhuijzen will discuss how to deal with these prickly yet critical techniques, ultimately changing the way you think about writing VCL.
Container monitoring for resource and application metrics with cAdvisor. Shipping monitoring information with the container so it is monitored irrespective of the host it runs on.
Intro to monitoring in distributed systems, cAdvisor, heapster, kubedash, kubernetes
Orchestrating Docker with Terraform and Consul by Mitchell Hashimoto Docker, Inc.
Terraform is a tool for building and safely iterating on infrastructure, while Consul provides service discovery, monitoring and orchestration. In this talk we discuss using Terraform and Consul together to build a Docker-based Service Oriented Architecture at scale. We use Consul to provide the runtime control plane for the datacenter, and Terraform is used to modify the underlying infrastructure to allow for elastic scalability.
WebSocket MicroService vs. REST MicroserviceRick Hightower
Comparing the speed of RPC calls over WebScoket Microservices versus REST based microservices. Using wrk, QBit, and examples in Java we show how much faster WebSocket is for doing RPC service calls.
With the increasing maturity of OpenStack Neutron, and increasing support for a large number of services , we'll examine how SDNs can leverage the container technology for supporting "as a Service" components.
So you want to auto scale your services, and use service oriented architecture, eh?
Want to reduce the cost of managing your clusters, and discover them dynamically?
In this talk we shall see how consul helps you do that very efficiently, demonstrate spinning up several interconnected services, and show how we can achieve seamless discovery, HA, and fault tolerance.
Heart of the SwarmKit: Store, Topology & Object ModelDocker, Inc.
Heart of the SwarmKit: Store, Topology & Object Model by Aaron, Andrea, Stephen D (Docker)
Swarmkit repo - https://github.com/docker/swarmkit
Liveblogging: http://canopy.mirage.io/Liveblog/SwarmKitDDS2016
Service Discovery using etcd, Consul and KubernetesSreenivas Makam
Overview of Service Discovery and Service Discovery using etcd, Consul, Kubernetes and Docker. Presented at Open source meetup, Bangalore(http://www.meetup.com/Bangalore-Open-Source-Meetup/events/229763724/)
Covers overview of CoreOS and current status of CoreOS projects. Presented at Open source meetup, Bangalore(http://www.meetup.com/Bangalore-Open-Source-Meetup/events/229763724/)
Orchestration tool roundup kubernetes vs. docker vs. heat vs. terra form vs...Nati Shalom
Video recording: https://www.youtube.com/watch?v=tGlIgUeoGz8
It’s no news that containers represent a portable unit of deployment, and OpenStack has proven an ideal environment for running container workloads. However, where it usually becomes more complex is that many times an application is often built out of multiple containers. What’s more, setting up a cluster of container images can be fairly cumbersome because you need to make one container aware of another and expose intimate details that are required for them to communicate which is not trivial especially if they’re not on the same host.
These scenarios have instigated the demand for some kind of orchestrator. The list of container orchestrators is growing fairly fast. This session will compare the different orchestation projects out there - from Heat to Kubernetes to TOSCA - and help you choose the right tool for the job.
Session link from teh summit: https://openstacksummitmay2015vancouver.sched.org/event/abd484e0dedcb9774edda1548ad47518#.VV5eh5NViko
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы:
- что сегодня помогает закладывать нужные оси вариативности в архитектуру?
- как отделить и подружить разработку, внедрение и сопровождение?
- как замотивировать людей быть эффективными, использовать удобные инструменты?
- как дать людям свободу в их выборе и разделять ответственность за полученный результат?
а также в программе:
- Docker
- микросервисы
- закон трёх букв
The Reality of Managing Microservices in Your CD PipelineDevOps.com
As we shift from monolithic software development practices to microservices, our well-designed CD pipeline will need to change. Microservices are small functions, deployed independently and linked via APIs at run-time. While these differences seem minor, they actually have a large impact on your overall CD structure. Think hundreds of workflows, small of any builds and the loss of a monolithic 'application.'
Join Tracy Ragan, CEO of DeployHub and Brendan O'Leary, Developer Evangelist at GitLab, to learn more.
It's never too early to start the conversation.
This talk was done in Feb 2020. Sergey and I co-presented at CTO Forum on Microservices and Service Mesh (how they relate, requirements, goals, best practices and how DevOps and Agile has had convergence in the set of features for Service Mesh and gateways around observability, feature flags, etc.)
Early Draft: Service Mesh allows developers to focus on business logic while the crosscutting network data layer code is handled by the Service Mesh. This is a boon because this code can be tricky to implement and hard to test all of the edge cases. Service Mesh takes this a few steps further than AOP or Servlet Filters or custom language-specific frameworks because it works regardless of the underlying programming language being used which is great for polyglot development shops. Thus standardizing how these layers work, while allowing teams to pick the best tools or languages for the job at hand. Kubernetes and Istio Service Mesh automate best practices for DevSecOps needs like: failover, scale-out, scalability, health checks, circuit breakers, rate limiters, metrics, observability, avoiding cascading failure, disaster recovery, and traffic routing; supporting CI/CD and microservices architecture.
Istio’s ability to automate and maintaining zero trust networks is its most important feature. In the age of high-profile data breaches, security is paramount. Companies want to avoid major brand issues that impact the bottom line and shrink market capitalization in an instant. Istio allows a standard way to do mTLS and auto certificate rotation which helps prevent a breach and limits the blast radius if a breach occurs. Istio also takes the concern of mTLS from microservices deployments and makes it easy to use taking the burden off of application developers.
The Business Value of PaaS Automation - Kieron Sambrook-Smith - Presentation ...eZ Systems
Kieron Sambrook-Smith, Chief Commercial Officer at Platform.sh spoke at eZ Conference 2017 in London about the business value of Platform as a Service (PaaS) Automation.
He covers the many aspects of the advantages of using a PaaS. The business value you can expect to reap will range from hosting cost savings, better workflow and team productivity, new project delivery concepts, and greater competitive advantage. Discover a more advanced implementation of your service offering.
“ The Microservices architecture has many appealing qualities, but the road towards it has painful traps for the unwary. This book will help you figure out if this path is for you, and how to avoid those traps on your journey.”
—Martin Fowler Chief Scientist, ThoughtWorks
Starting Your DevOps Journey – Practical Tips for OpsDynatrace
To watch, please see:
https://info.dynatrace.com/apm_wc_getting_started_with_devops_na_registration.html
Starting Your DevOps Journey: Practical Tips for Ops
In this webinar, Andreas Grabner, Chief DevOps Activist at Dynatrace, shares practical tips that all IT groups from Dev to Ops can use to start their DevOps journey quickly. With experience from hundreds of DevOps deployments, Andi provides insights it would take your team months or years to learn firsthand.
- Learn how everyone on your Ops team can use APM to better understand and monitor SLAs, Performance and End User Impact of their applications.
- Foster better collaboration between Ops and architects by extending basic system monitoring to monolith and microservices architectures.
- Shift-left your testing and QA by working with metrics that you and the architects agreed on up front, resulting in early relevant feedback and faster code deployments.
- Hear why changing the cultural mindset from “fear of change” to “Continuous Innovation and Optimization” is critical for success.
Andi is joined by guest speaker, Brian Chandler, Systems Engineer at Raymond James, who shares commonly used Ops dashboards that increase collaboration across IT teams and pro-actively break down silos!
Today, there are several trends that are forcing application architectures to evolve. Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile devices. Applications must be highly scalable, highly available and run on cloud environments. Organizations often want to frequently roll out updates, even multiple times a day. Consequently, it’s no longer adequate to develop simple, monolithic web applications that serve up HTML to desktop browsers.
This site describes a new, alternative architecture: microservices. Applications with a microservice architecture consist of a set of narrowly focused, independently deployable services. Read on to find out more about this approach and its associated trade-offs. A good starting point is the Monolithic Architecture pattern.
Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux.[5] Docker uses resource isolation features of the Linux kernel such as cgroups and kernel namespaces to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines.
Microservices - Hitchhiker's guide to cloud native applicationsStijn Van Den Enden
Microservices are a true hype these days. Netflix, Amazon, eBay, … are all using microservices, but why? The idea is simple; split your application into multiple services which can evolve autonomously through time. The name suggests to keep these services small. Conceptually this seems not all that different from a classical Service Oriented Architecture (SOA). Nonetheless, microservices do offer a new perspective. A monolithic application is divided into a couple small services which can be independently developed, deployed and scaled. Flexibility is increased, but using this model also has some pitfalls.This session sheds a light on the microservices landscape; the key drivers for using the pattern, tooling to support development and maintenance, and the pros and cons that go with it. We’ll also introduce some key design principles that can be used in creating and modelling these modular enterprise applications.
Microservices in Action: putting microservice-based applications into productionManning Publications
Microservices in Action is a practical book about building and deploying microservice-based applications. Written for developers and architects with a solid grasp of service-oriented development, it tackles the challenge of putting microservices into production.
Save 42% off Microservices in Action with code slbruce at: https://www.manning.com/books/microservices-in-action
Best of re:Invent 2016 meetup presentationLahav Savir
At re:Invent 2016, AWS announced major and exciting services which finalized their product pipeline providing customers with a comprehensive end-to-end solution in all product realms including Data and BI, CI/ CD, Serverless Applications, Security and Mobile. Join us and find out what’s coming next and learn how to utilize the complete AWS platform.
Microservices: Organizing Large Teams for Rapid DeliveryVMware Tanzu
SpringOne Platform 2016
Speakers: Patricia Anderson; Senior Consultant, Credera. Micah Blalock; Senior Architect, Credera. Jason Goth; Principal Architect, Credera.
A microservice architecture is pattern that is most commonly associated with larger organizations where services and teams are organized around separate business capabilities. In a project our team recently completed, we used a microservice architecture to allow us to organize a large team to develop a large analytics platform at speeds that would not have been possible using a more typical service-oriented architecture.
In this session, we discuss the organizational structure and communication and development strategies and tools to allow teams to work in parallel without drowning in process overhead and coordination costs.
Reduce Risk with End to End Monitoring of Middleware-based ApplicationsSL Corporation
Kafka communicates within a larger complex and evolving environment. The current modular approach to the integration means that the structure of the software stack is much more dynamic than in the past and operators no longer have the time to become intimate with how dependent components interact. The number of dependencies combined with lack of familiarity can create significant risks to the business including increased outages and longer time to resolve incidents. Both can result in loss of revenue and customers.
These risks are significantly reduced by applying best-practice monitoring. Monitoring can provide a complete end-to-end view of the touch points within the application flow, so they are presented in comprehensive service-based views. This provides the user with a true single-pane of glass for monitoring and alerting for Kafka and its dependent technologies.
Streaming a Million Likes/Second: Real-Time Interactions on Live VideoC4Media
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/39NIjLV.
Akhilesh Gupta does a technical deep-dive into how Linkedin uses the Play/Akka Framework and a scalable distributed system to enable live interactions like likes/comments at massive scale at extremely low costs across multiple data centers. Filmed at qconlondon.com.
Akhilesh Gupta is the technical lead for LinkedIn's Real-time delivery infrastructure and LinkedIn Messaging. He has been working on the revamp of LinkedIn’s offerings to instant, real-time experiences. Before this, he was the head of engineering for the Ride Experience program at Uber Technologies in San Francisco.
Next Generation Client APIs in Envoy MobileC4Media
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2x0Fav8.
Jose Nino guides the audience through the journey of Mobile APIs at Lyft. He focuses on how the team has reaped the benefits of API generation to experiment with the network transport layer. He also discusses recent developments the team has made with Envoy Mobile and the roadmap ahead. Filmed at qconlondon.com.
Jose Nino works as a Software Engineer at Lyft.
Software Teams and Teamwork Trends Report Q1 2020C4Media
How do we cope with an environment that has been radically disrupted, where people are suddenly thrust into remote work in a chaotic state? What are the emerging good practices and new ideas that are shaping the way in which software development teams work? What can we do to make the workplace a more secure and diverse one while increasing the productivity of our teams? This report aims to assist technical leaders in making mid- to long-term decisions that will have a positive impact on their organisations and teams and help individual contributors find the practices, approaches, tools, techniques, and frameworks that can help them get a better experience at work - irrespective of where they are working from.
Understand the Trade-offs Using Compilers for Java ApplicationsC4Media
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2QCmmJ0.
Mark Stoodley examines some of the strengths and weaknesses of the different Java compilation technologies, if one was to apply them in isolation. Stoodley discusses how production JVMs are assembling a combination of these tools that work together to provide excellent performance across the large spectrum of applications written in Java and JVM based languages. Filmed at qconsf.com.
Mark Stoodley joined IBM Canada to build Java JIT compilers for production use and led the team that delivered AOT compilation in the IBM SDK for Java 6. He spent the last five years leading the effort to open source nearly 4.3 million lines of source code from the IBM J9 Java Virtual Machine to create the two open source projects Eclipse OMR and Eclipse OpenJ9, and now co-leads both projects.
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2y2yPiS.
Colin McCabe talks about the ongoing effort to replace the use of Zookeeper in Kafka: why they want to do it and how it will work. He discusses the limitations they have found and how Kafka benefits both in terms of stability and scalability by bringing consensus in house. He talks about their progress, what work is remaining, and how contributors can help. Filmed at qconsf.com.
Colin McCabe is a Kafka committer at Confluent, working on the scalability and extensibility of Kafka. Previously, he worked on the Hadoop Distributed Filesystem and the Ceph Filesystem.
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2SXXXiD.
Katharina Probst talks about what it means to act like an owner and why teams need ownership to be high-performing. When team members, regardless of whether they have a formal leadership role or not, act like owners, magical things can happen. She shares ideas that we can apply to our own work, and talks about how to recognize when we don’t live up to our own expectations of acting like an owner. Filmed at qconsf.com.
Katharina Probst is a Senior Engineering Leader, Kubernetes & SaaS at Google. Before this, she was leading engineering teams at Netflix, being responsible for the Netflix API, which helps bring Netflix streaming to millions of people around the world. Prior to joining Netflix, she was in the cloud computing team at Google, where she saw cloud computing from the provider side.
Does Java Need Inline Types? What Project Valhalla Can Bring to JavaC4Media
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2T04Lw4.
Sergey Kuksenko talks about the performance benefits inline types bring to Java and how to exploit them. Inline/value types are the key part of experimental project Valhalla, which should bring new abilities to the Java language. Filmed at qconsf.com.
Sergey Kuksenko is a Java Performance Engineer at Oracle working on a variety of Java and JVM performance enhancements. He started working as Java Engineer in 1996 and as Java Performance Engineer in 2005. He has had a passion for exploring how Java works on modern hardware.
Do you need service meshes in your tech stack?
This on-line guide aims to answer pertinent questions for software architects and technical leaders, such as: what is a service mesh?, do I need a service mesh?, how do I evaluate the different service mesh offerings? In software architecture, a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between microservices, often using a sidecar proxy.
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2UgQ3BU.
Christie Wilson describes what to expect from CI/CD in 2019, and how Tekton is helping bring that to as many tools as possible, such as Jenkins X and Prow. Wilson talks about Tekton itself and performs a live demo that shows how cloud native CI/CD can help debug, surface and fix mistakes faster. Filmed at qconsf.com.
Christie Wilson is a software engineer at Google, currently leading the Tekton project. Over the past decade, she has worked in the mobile, financial and video game industries. Prior to working at Google she led a team of software developers to build load testing tools for AAA video game titles, and founded the Vancouver chapter of PyLadies.
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2S7lDiS.
Sasha Rosenbaum shows how a CI/CD pipeline for Machine Learning can greatly improve both productivity and reliability. Filmed at qconsf.com.
Sasha Rosenbaum is a Program Manager on the Azure DevOps engineering team, focused on improving the alignment of the product with open source software. She is a co-organizer of the DevOps Days Chicago and the DeliveryConf conferences, and recently published a book on Serverless computing in Azure with .NET.
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/36epVKg.
Todd Montgomery discusses the techniques and lessons learned from implementing Aeron Cluster. His focus is on how Raft can be implemented on Aeron, minimizing the network round trip overhead, and comparing single process to a fully distributed cluster. Filmed at qconsf.com.
Todd Montgomery is a networking hacker who has researched, designed, and built numerous protocols, messaging-oriented middleware systems, and real-time data systems, done research for NASA, contributed to the IETF and IEEE, and co-founded two startups. He currently works as an independent consultant and is active in several open source projects.
Architectures That Scale Deep - Regaining Control in Deep SystemsC4Media
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2FWc5Sk.
Ben Sigelman talks about "Deep Systems", their common properties and re-introduces the fundamentals of control theory from the 1960s, including the original conceptualizations of Observability & Controllability. He uses examples from Google & other companies to illustrate how deep systems have damaged people's ability to observe software, and what needs to be done in order to regain control. Filmed at qconsf.com.
Ben Sigelman is a co-founder and the CEO at LightStep, a co-creator of Dapper (Google’s distributed tracing system), and co-creator of the OpenTracing and OpenTelemetry projects (both part of the CNCF). His work and interests gravitate towards observability, especially where microservices, high transaction volumes, and large engineering organizations are involved.
ML in the Browser: Interactive Experiences with Tensorflow.jsC4Media
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/39SddUL.
Victor Dibia provides a friendly introduction to machine learning, covers concrete steps on how front-end developers can create their own ML models and deploy them as part of web applications. He discusses his experience building Handtrack.js - a library for prototyping real time hand tracking interactions in the browser. Filmed at qconsf.com.
Victor Dibia is a Research Engineer with Cloudera’s Fast Forward Labs. Prior to this, he was a Research Staff Member at the IBM TJ Watson Research Center, New York. His research interests are at the intersection of human computer interaction, computational social science, and applied AI.
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2s9T3Vl.
Colin Eberhardt looks at some of the internals of WebAssembly, explores how it works “under the hood”, and looks at how to create a (simple) compiler that targets this runtime. Filmed at qconsf.com.
Colin Eberhardt is the Technology Director at Scott Logic, a UK-based software consultancy where they create complex application for their financial services clients. He is an avid technology enthusiast, spending his evenings contributing to open source projects, writing blog posts and learning as much as he can.
User & Device Identity for Microservices @ Netflix ScaleC4Media
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2S9tOgy.
Satyajit Thadeshwar provides useful insights on how Netflix implemented a secure, token-agnostic, identity solution that works with services operating at a massive scale. He shares some of the lessons learned from this process, both from architectural diagrams and code. Filmed at qconsf.com.
Satyajit Thadeshwar is an engineer on the Product Edge Access Services team at Netflix, where he works on some of the most critical services focusing on user and device authentication. He has more than a decade of experience building fault-tolerant and highly scalable, distributed systems.
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2Ezs08q.
Justin Ryan talks about Netflix’ scalability issues and some of the ways they addressed it. He shares successes they’ve had from unintuitively partitioning computation into multiple services to get better runtime characteristics. He introduces us to useful probabilistic data structures, innovative bi-directional data passing, open-source projects available from Netflix that make this all possible. Filmed at qconsf.com.
Justin Ryan is Playback Edge Engineering at Netflix. He works on some of the most critical services at Netflix, specifically focusing on user and device authentication. Years of building developer tools has also given him a healthy set of opinions on developer productivity.
Make Your Electron App Feel at Home EverywhereC4Media
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2Z4ZJjn.
Kilian Valkhof discusses the process of making an Electron app feel at home on all three platforms: Windows, MacOS and Linux, making devs aware of the pitfalls and how to avoid them. Filmed at qconsf.com.
Kilian Valkhof is a Front-end Developer & User-experience Designer at Firstversionist. He writes about various topics, from design to machine learning, on his personal website, kilianvalkhof.com and is a frequent contributer to open source software. He is part of the Electron governance team that oversees the development of the Electron framework.
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/344PnB1.
Steve Klabnik goes over the deep details of how async/await works in Rust, covering concepts like coroutines, generators, stack-less vs stack-ful, "pinning", and more. Filmed at qconsf.com.
Steve Klabnik is on the core team of Rust, leads the documentation team, and is an author of "The Rust Programming Language." He is a frequent speaker at conferences and is a prolific open source contributor, previously working on projects such as Ruby and Ruby on Rails.
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2OUz6dt.
Chris Riccomini talks about the current state-of-the-art in data pipelines and data warehousing, and shares some of the solutions to current problems dealing with data streaming and warehousing. Filmed at qconsf.com.
Chris Riccomini works as a Software Engineer at WePay.
Automated Testing for Terraform, Docker, Packer, Kubernetes, and MoreC4Media
Video and slides synchronized, mp3 and slide download available at URL https://bit.ly/2rm4hFD.
Yevgeniy Brikman talks about how to write automated tests for infrastructure code, including the code written for use with tools such as Terraform, Docker, Packer, and Kubernetes. Topics covered include: unit tests, integration tests, end-to-end tests, dependency injection, test parallelism, retries and error handling, static analysis, property testing and CI / CD for infrastructure code. Filmed at qconsf.com.
Yevgeniy Brikman is the co-founder of Gruntwork, a company that provides DevOps as a Service. He is the author of two books published by O'Reilly Media: Hello, Startup and Terraform: Up & Running. Previously, he worked as a software engineer at LinkedIn, TripAdvisor, Cisco Systems, and Thomson Financial.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
2. InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month
Watch the video with slide
synchronization on InfoQ.com!
http://www.infoq.com/presentations
/consul
3. Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide
Presented at QCon San Francisco
www.qconsf.com
5. Towards a software-managed datacenter.
HashiCorp
hashicorp.com
I am a co-founder of HashiCorp, which focuses on building tooling for a software-managed datacenter.
6. You may recognize some of our open source tools such as Vagrant, Packer, Serf, Consul and Terraform.
8. Alphabet Soup
• Service Oriented Architecture (SOA)
• Micro-Services
• Monoliths
• N-Tier Architectures
Today we are talking about Service Oriented at Scale. Unfortunately, we now have a buzzword soup when discussing anything in this space. You may have
heard of terms like Service Oriented Architectures, SOA, Micro-Services, Monoliths, and N-Tier architectures.
9. MonolithMicro-Service
SOA Spectrum
As with most things, SOA is a spectrum. On one side is “Micro-Services”. These are the smallest unit, some define it as 100 LoC, or 1 RPC method. On the
other side we have the “Monolith”. This involves packaging the entire application into a single enormous service.
10. MonolithMicro-Service
SOA Spectrum
Utility of Service
I’d argue that the utility curve of a service, is probably normally distributed along the spectrum. Services that are too small introduce both conceptual
overhead of needing to understand a web of hundreds or thousands of services, while having a few enormous applications makes it very hard to reason
about the workings of that particular service.
11. 2-Tier
Web Tier
Database
In terms of the N-Tier architectures, I think examples are most useful. The most basic example would be a simple 2 tier application. Here we may have a
Web and Data tier.
12. 3-Tier
Web Tier
Database
API Tier
This might eventually evolve into the classic 3 tier architecture. Here we introduce an intermediate API tier which separates presentation from business
logic.
13. N-Tier
Desktop Web Tier
Cache
User Service
Client API Tier
RDBMS
Billing Service
Mobile Web Tier
NoSQL
Timeline Service
Eventually, the final evolution of this is the N-Tier architecture. Here there are multiple presentation tiers, multiple services containing different bits of
business logic and many data tiers that are optimized for their particular access patterns and semantics.
14. SOA Goals
• Autonomous
• Well-Defined (Limited) Scope
• Loose Coupling
More fundamental however is the goals of SOA. Again many definitions are possible, but the one I prefer is that a service should be as autonomous as
possible, it’s scope should be well-defined but limited. This means you can’t define the scope of your service as “Twitter”. Lastly, there should be a loose
coupling between services.
15. SOA Benefits
• Develop Faster
• Composable
• Failure Isolation
• Testable
• Scale Out vs Scale Up
Given that we stick to our goals, using a SOA architecture has many benefits. In many ways this is analogous to writing a single enormous function or
decomposing into many sub-routines. We can develop faster since we can reason about the problem domain. Services can be composed together to build
higher level applications. We can isolate failure domains to specific services. Each service becomes more testable as we know the inputs and outputs.
Lastly, services enable a scale out instead of a scale up approach as well.
16. Challenges
• SOA is Hard!
• Discovery
• Monitoring
• Configuration
• Orchestration
That said, SOA isn’t without it’s challenges. In fact, SOA is hard. There are a number of big challenges including Service Discovery, Monitoring,
Configuration and Orchestration.
17. Discovery
Where are the API Servers?
Web Tier API Tier
The service discovery problem is almost always the most immediate one. Given just a Web and API tier, the web servers need to be able to discover the
location of the API servers.
18. Hard Coded Address
Web Tier API Tier
10.0.1.150
One very simple approach is to simply hard-code the address of the other tiers. This has a number of problems, it’s not a scalable approach, load
balancing, and fault tolerance both are difficult. It suffers from fragility.
19. Hard Coded LB
Web Tier API Tier
10.0.1.150
LB
API Tier
API Tier
The next most common approach is the intermediate load balancer. It does allow the API tier to be scaled independently. It also allows health checking to
be done by the load balancer to provide some resiliency. However, now our load balancer becomes the single point of failure.
20. Health Checking
Web Tier API Tier
API Tier
API Tier
If we are able to remove the load balancer, then we now have re-introduced the problem of health checking. Previously we could rely on the load balancer
to do this for us. Now we need to both know the state of the service and also ensure traffic is not routed to any unhealthy providers.
21. Configuration
Web Tier
Maintenance = False
EnableFoo = True
EnableBar = False
Environment = Prod
Web Tier
Web Tier
Independent of the discovery and health checking problem is just configuration. Given that we are running a service across many machines, how do we
ensure they all get timely updates to their configuration.
22. Orchestration
Desktop Web Tier
Cache
User Service
“Purge Keys”
“Invalidate Sessions”
“Rotate Session Encrypt Key”
The last major issue is orchestration or event delivery. For many services, there are certain types of events that they are designed to respond to. Managing
events and ensuring their timely delivery across a service fleet is also a challenging problem. For example, we may way to purge our caches, force user
sessions to be invalidated, or maybe instruct our web tier to rotate the encryption key that is used. Maybe we are responding to yet another OpenSSL
vulnerability and these need to happen ASAP.
23. SOA Barriers
• Discovery
• Health + Monitoring
• Configuration
• Orchestration
So clearly there are some barriers to SOA. However, putting everything in a monolith doesn’t solve many of these problems either. Ultimately, none of
these problems are new, they’ve been around for a while, and there are existing solutions.
24. Service Discovery
• DNS
• ZooKeeper
• RDBMS
• Redis
On the service discovery side, there are many existing tools. These are some of the prominent tools used to tackle the problem.
25. The problem with most of these tools is exactly that, they are tools. It’s very similar to asking your realtor for a house.
26. And instead being given a hammer, nails and some wood. Sure, it is entirely possible to build a service discovery solution with these components, but
directions are not included.
27. Monitoring
• Load Balancers
• Nagios
• Sensu
Similarly, monitoring tools have existed for a while. Load Balancers usually offer some form of monitoring, and other more general purpose systems like
Nagios and Sensu exist to provide global health checking.
28. The problem with these tools is that they silo health information. They are designed specifically to detect problems and report them to human operators.
They are not designed as a feedback mechanism for service discovery. As a result, a health check may fail on a service but traffic will still be routed to it.
29. Configuration
• Static Files
• Configuration Management
• RDBMS
• Redis
Configuration has probably been an issue from the moment the first application was written. This is probably the least painful problem, as most
configuration tends to be relatively static. It is possible to have more dynamic configuration using config management tools, databases, redis, etc. These
allow for a higher level of runtime configuration that is easy to change. Unfortunately, many of these approaches suffer from issues of speed, scalability or
fault tolerance.
30. Orchestration
• SSH
• Redis
• ZooKeeper
• mCollective
• Custom
Orchestration is the last, but also the least solved issue. There is not broad adoption of specific tooling for this problem. Likely because it’s the easiest to
ignore.
32. Consul
• Solution vs Tool
• Service Discovery
• Health Checking
• Configuration
• Orchestration
Consul is a tool, but the goal is to focus on high-level solutions. We want to give you the house and the hammer. Ultimately, it tackles all the challenges
presented by a service oriented architecture.
33. Service Discovery
• Nodes, Services, Checks
• Simple Registration (JSON)
• DNS Interface
• HTTP API
Service discovery is at the heart of Consul. Consul uniquely blends service discovery with health checking, which is absolutely crucial. Registering services
with Consul requires no code, instead a simple JSON file is provided that describes the service and optionally provides health checks. The checks are
Nagios compatible, which means almost every conceivable service already has a pre-written check. Querying data out of Consul is done using either a
DNS interface or the HTTP API.
34. {
"service": {
"name": "redis",
"tags": ["slave"],
"port": 8000,
"check": {
"script": "/usr/local/bin/check_redis.py",
"interval": "10s"
}
}
}
As an example, here is a simple JSON registration for a redis service. We are declaring the service name, providing a tag, indicating its a ‘slave’ node, the
port and lastly a health check. We’ve provided a nagios compatible check that is run on a 10 second interval to check health.
35. $ dig slave.redis.service.consul
!
; <<>> DiG 9.8.3-P1 <<>> slave.redis.service.consul
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9046
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
!
;; QUESTION SECTION:
;slave.redis.service.consul. IN A
!
;; ANSWER SECTION:
slave.redis.service.consul. 0 IN A 10.1.10.38
DNS is a first-class mechanism to doing service discovery with Consul. Here we can issue a simple request to lookup the “redis” service but filtering only
to instances with the “slave” tag. Consul responds with an A record providing the IP address of the redis instance. Unfortunately, that doesn’t include the
port to use.
36. $ dig slave.redis.service.consul SRV
!
; <<>> DiG 9.8.3-P1 <<>> slave.redis.service.consul SRV
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11480
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
!
;; QUESTION SECTION:
;slave.redis.service.consul. IN SRV
!
;; ANSWER SECTION:
slave.redis.service.consul. 0 IN SRV 1 1 8000 foo.node.dc1.consul.
!
;; ADDITIONAL SECTION:
foo.node.dc1.consul. 0 IN A 10.1.10.38
However, if we issue an SRV request to Consul, it will provide the appropriate records indicated both the port 8000 and the IP address of the host.
37. DNS Interface
• Zero Touch
• Round-Robin DNS (Randomized)
• Filters on Health Checks
Using a DNS based discovery approach allows for a zero-touch integration with Consul. No application code changes. JSON files are provided to register
services, and discovery is done transparently at the DNS level.
Additionally, the DNS records returned are randomized, so you get a round-robin form of load balancing. Entries for services that are failing health checks
are automatically filtered out to avoid routing to unhealthy hosts.
38. HTTP API
• Rich HTTP API
• Deeper integrations
• More intelligent clients
In addition to the DNS interface, there is also a rich HTTP API. The API can be used to deeper more intelligent integrations. This allow clients to customize
their routing logic, connection pooling, etc. It also makes it simple to build tooling around Consul.
39. Monitoring
• Nagios Compatible
• Scalable
• DevOps friendly
• Actionable
As I mentioned, the monitoring features are deeply integrated into the service discovery of Consul. When building Consul, we wanted to ensure that the
checks would be compatible with the existing nagios ecosystem, but unlike nagios we wanted the checks to be scalable, devops friendly and actionable.
40. Server
Client Client
Check State
Monitoring
• Run on the Nodes
• Push vs Pull
• Edge Triggered
As a result, we spent a lot of time designing this feature. We wanted to ensure Consul could scale to thousands of machines, so instead of the central
servers using SSH to run the checks remotely in effect a “Pull” model, Consul runs the health checks on the edges and uses a “Push” model. This allows
for a major optimization which is to only do edge triggering. If a health check is in a stable state, we don’t need to update the servers. This provides
multiple orders of magnitude reduction in write volume.
41. Liveness
• No Heartbeats
• Gossip-based Failure Detector
• Constant Load
• Serf (http://www.serfdom.io)
The problem with edge triggered monitoring is that we have no liveness heartbeats. Meaning in the absence of any updates, we don’t know if the checks
are simply in a stable state or if the server has died. Consul get’s around this by using a gossip-based failure detector. All cluster members take part in a
background gossip, which has a constant load regardless of cluster size. This enables Consul to scale to thousands of machines with negligible load on
CPU or the network.
42. Configuration
• Hierarchical Key/Value Store
• HTTP API
• Long-Polling
• Locking
• ACLs
To support application configuration, Consul provides a hierarchical Key/Value store. The KV store is available through a simple HTTP API. It provides
support for long-polling of changes, distributed locking, and ACLs. This provides a rich set of primitives to integrate applications.
43. envconsul
$ envconsul -reload service/foo/config /usr/bin/foo
...
$ envconsul -reload=true service/foo/config env
MAX_CONNS=256
ENABLE_FOO=True
ENVIRONMENT=production
!
In practice, there are a few common ways of integrating application configuration with Consul. One approach is a tool called ‘envconsul’. Inspired by
‘envdir’, it simply reads the keys from the KV store at a given prefix, and sets them as environmental variables for the application. It can optionally reload
the application on configuration changes, allowing real-time changes to be made.
44. consul-template
• Dynamically renders templates
• Reload on changes
• Integrate with everything*
• Real-time
Another approach is to use a tool like consul-template. This allows templates to be rendered using dynamic values read from the KV store. consul-
template also handles watching for any changes, so that the config file can be re-rendered and the application reloaded, allowing for the same realtime
response to changes.
45. consul-template
backend frontend
maxconn 256
balance roundrobin
server web1 10.0.1.100:80
server web2 10.0.2.200:80
backend frontend
maxconn {{ key "frontend/maxconn" }}
balance roundrobin{{range service "app.frontend"}}
service {{.ID}} {{.Address}}:{{.Port}}{{end}}
consul-template also integrates with both the KV store and the service catalog. This lets us do things like populate an HAProxy configuration with
variables like the maximum connection count from the KV store, and the list of healthy servers from the service catalog. All of this is without HAProxy
needing to be aware of Consul in any way, consul-template just glues the two together.
46. Orchestration
• Watchers
• Event System
• Remote Execution
• Distributed Locking
When it comes to Orchestration, Consul provides an entire toolkit of features. All of these features “just work” out of the box, so that developers and
operators don’t have to write code to get started.
47. Watchers
• Watch for Changes
• “View of Data”
• Custom Handlers
• KV, Services, Nodes, Checks, Events
• Static or Dynamic
Watches are the simplest way to react to changes using Consul. A watcher is basically a pairing between a “view of data” and a custom handler. The
“data” you care about can be KV data, services, nodes, health checks, or custom events. The handler can be any executable, letting operators customize
behavior. Watches can be configured either statically using configuration or with the “consul watch” command dynamically.
48. Watchers
$ consul watch -type nodes
[
{
"Node": "foo",
"Address": "10.1.10.38"
}
]
$ consul watch -type nodes /usr/bin/setup_dns.sh
As an example, a watcher can be setup to watch for changes to the nodes list. Any time a new node joins or leaves the cluster, the handler will be invoked.
If we invoke it without a handler, we just get the current result set. We can also specify a handler which gets updates over stdin and is free to react in any
way. For example, we could update our BIND configuration.
49. Events
• Flexible event system
• Name + Payload
• Filter on Services, Nodes, Tags
• Built on Watches
Building on watches, Consul includes a flexible event system that can be used for any purpose. Events are fired with a name and payload, and handlers
can be registered to respond to events. Events can filter on services, nodes and tags, so that you can target the machines that should process the event.
Because events are built on watches, they operate in the same way. Either statically configured or using consul watch.
50. Events
$ consul watch -type event -name test cat
[{“ID”:”8cf8a891-b08b-6286-8f68-44c6930cafe0”,
“Name":"test",
“Payload":"c2FtcGxlLXBheWxvYWQ=",
“NodeFilter":"",
“ServiceFilter":"redis",
“TagFilter":"",
“Version":1,
"LTime":4}]
$ consul event -service redis -name test sample-payload
Event ID: 8cf8a891-b08b-6286-8f68-44c6930cafe0
As an example, here we are firing an event named “test”, targeting the “redis” service and providing a “sample-payload”. If we had been running a
watcher, it could filter to only “test” events. Here we can see the handler receives the event, with the base64 encoded payload.
51. Remote Execution
• Built on Event System
• Parallel SSH++
• Filter on Services, Nodes, Tags
In addition to the generic event system, Consul also provides a remote execution tool. This allows operators to invoke commands like parallel SSH, while
filtering on services, tags, or nodes. This can be used to avoid writing a specific event handler when a more generic remote exec is suitable.
52. Remote Execution
$ consul exec -service redis uptime
foo: 18:24 up 79 days, 1:10, 1 user, load averages: 10.72 5.34 4.78
foo:
==> foo: finished with exit code 0
1 / 1 node(s) completed / acknowledged
This is a simple example of running the “uptime” command against any node that is providing the “redis” service. The event system is used to notify
nodes of the remote execution, and then the request and all the response data is sent back using the KV store. This avoids an expensive parallel SSH to all
the nodes, and allows for very efficient execution.
53. Distributed Locking
• Built into KV
• Client-side Leader Election
• Semaphores
Lastly, to support more complex orchestration needs, Consul supports distributed locking. This is supported within the Key/Value store and allows
applications to implement client-side leader election or semaphores. This requires a deeper integration with Consul, but frees developers from needing to
develop their own consensus protocols.
54. High-Level Features
• Service Discovery
• Health Checking
• Configuration
• Orchestration
We’ve covered briefly some of the high-level features of Consul. The point was not to comprehensively cover the details of all of these. The
documentation does a much better job of that, we’ve just hit the tip of the iceburg.
55. Solutions vs Tools
• Opinionated Solutions
• 95% Use Case
• “It Just Works”
• House, not the hammer
Instead, the point was to demonstrate that Consul provides a set of opinionated solutions to these common problems. The goal is not to solve every use
case, but to cover the 95% and to do it with a “it just works” experience. We want to provide the house, and not just the hammer.
57. Control Plane
• “Batteries Included”
• Scales to thousands of machines
• Multi-Datacenter Support
• Infrastructure Backbone
As a control plane layer, it comes with all the batteries included. It is designed (and deployed) at thousand node scale, and it supports multiple
datacenters. It provides the backbone on which the rest of infrastructure is built.
58. Deployment
• Agent per Machine
• Server and Client Agents
• 3-5 servers per datacenter
We’ve talked about the What and Why with Consul, but not the How. Consul requires the use of an agent, which runs on every machine. The agent can be
in either a client or server mode. Each datacenter must have at least one server, but usually either 3 or 5 are deployed for fault tolerance.
59. From a 10,000 ft view, Consul looks like this. Here we have two datacenters, containing client and server nodes. Within each datacenter, all of the nodes
are participating in a LAN gossip. The server nodes have a single node elected leader and are replicating to the others. Requests make use of RPC
forwarding, so a client forwards to a server, which then forwards to the leader node. Alternatively, a request may be forwarded to a remote datacenter as
well. The servers participate in a second level of WAN gossip allowing data centers to be aware of each other.
60. Agents
• RPC, HTTP, DNS APIs
• Health Checks
• Event Execution
• Gossip Pool
All of the agents, regardless of being in a client or server mode provide the same set of RPC, HTTP, and DNS APIs. As a client of Consul, the difference is
transparent. The queries are appropriately forwarded to a server, either in the local or a remote datacenter if appropriate. All the agents run health checks
and handle even execution locally and push results to the servers as appropriate.
61. Gossip
• Based on Serf (http://
www.serfdom.io)
• Membership
• Failure Detection
• Event System
The Gossip pool the agents participate in is based on Serf. Serf can be used an independent Cli or embedded as a library like in Consuls case. It provides
membership, failure detection and an event system.
62. Gossip Membership
• Join Requires Any Peer
• Server Discovery
• Protocol Versioning
The gossip membership features are great for operators. They mean only 1 other member of the cluster needs to be known to join. This allows clients to
automatically find all the servers in the cluster without any configuration. Lastly, it provides a layer to do protocol versioning. This allows Consul to
maintain a very strong level of backwards compatibility.
63. Failure Detector
• Leaving vs Failing
• Automatic Reaping
• Distributed Locking with Liveness
• No Heartbeating
• Constant Load
In addition to membership, the gossip layer provides a distributed failure detector. This provides a number of useful features. It allows us to distinguish
between a node leaving the cluster and failing. This allows us to reap nodes from the service catalog automatically. It also lets us build distributed locking
in a way that provides liveness, meaning progress can be made in the face of failure. The distributed nature of the detector means that we also don’t use
centralized heartbeating and have a constant load on the servers regardless of cluster size.
64. Gossip Events
• P2P delivery
• <1s delivery for 1K+ nodes
• No server load
Lastly, the gossip layer provides a very efficient event system. Because messages are delivered peer-to-peer, we get sub-second delivery on clusters with
thousands of nodes. It also avoids placing load on central servers to manage delivery and broadcast of events.
65. Server Agents
• Centralized state
• Query Handling
• Raft Consensus
• WAN Gossip
The server nodes are the “brains” of the cluster. They maintain the state, and replicate data between themselves. They are also responsible for responding
to queries. As a detail, they make use of the Raft Consensus protocol, which is a simplification of Paxos. They also participate in a WAN gossip pool, this
means the servers are aware of the other data centers and can forward requests as appropriate.
66. System Service
• Ubiquitous Agents
• Unified API
• Treat as System Service
• Useful for Operators and Developers
Because of the design of Consul, the agent ends up being ubiquitously deployed. Additionally, since the API is unified across agent types, from a user
perspective we are guarded from the internal details of Consuls implementation. In this way, you can think of Consul as a system service, that can be used
by system operators and developers.
67. Consul in Production
• 2K+ stars (GitHub)
• 100K+ downloads
• VagrantCloud
• Large-scale customer deploys
To really see the impact of Consul, it’s useful to see cases of its use in production. The popularity of Consul is really quite staggering. It has over 2K stars
on GitHub, and over 100K downloads. It is the backbone of HashiCorp’s VagrantCloud infrastructure, which I’ll talk more about. It also has seen some very
large-scale customer deploys as well.
68. Vagrant Cloud
• SaaS Product for Vagrant
• Vagrant Share
• Box Discovery
• Box Hosting
• Service Oriented Architecture
Vagrant Cloud is a SaaS service for Vagrant. It powers the “share” feature of Vagrant,
provides box discovery and hosting. This includes the actual VM images and the associated metadata. I believe it recently crossed the 2M+ mark for box
downloads. All of it is built around a service oriented architecture build on Consul.
69. Consul in Vagrant Cloud
• Single AWS VPC
• Dozens of Services
• Internal + External
• 3 Consul Servers
Vagrant Cloud is deployed within a single VPC on AWS. It is composed of dozens of services. Some of these are internal and hosted by us, and others are
hosted externally using SaaS providers.
70. Discovery in Vagrant Cloud
• DNS for most Services
• Query Agent for Local Service
• Binary Streaming
• HAProxy at Edges
To handle service discovery in Vagrant Cloud, we mostly rely on DNS. There are some exceptions to this. Some of our services query the local agent to
check for a possible co-process. For example, when doing a binary upload we would prefer to talk to a service on localhost instead of going over the
network. The edges of our network also relies on HAProxy.
71. Internet
VPC
Service
HAProxy
Service Service
HAProxy
HAProxy
• Consul Internal Only
• HAProxy “Bridge”
• consul-template
One reason to use HAProxy is that Consul is an internal facing service. There is no simple way to have an external DNS service query Consul, and even
then, the addresses are generally private and not-routable. HAProxy provides a “bridge” to the outside world. To manage this setup, we simply use
consul-template to keep the HAProxy configuration up-to-date.
72. Application Configuration
• consul-template
• envconsul
We also use consul-template more generally to configure internal applications. Many of our simpler services can read all of their configuration from
environmental variables, so we can use envconsul for that.
73. Consul Web UI
To manage setting and updating the configuration, we simply use the Consul Web UI. The UI is included as part of the releases, and provides an easy way
to browse services, nodes, health checks, and to manipulate the KV store.
74. Vagrant Cloud Orchestration
• Deploys
• Leader Election
• Service Coordination (StorageLocker)
But arguably Consul has ingrained itself most deeply in how we orchestrate Vagrant Cloud. It is used to manage deploys, do leader election within
services, and provide deeper coordination. One example I’ll talk about is our use of it in StorageLocker.
75. Deploys
• Event Driven
• Download Binaries
• Rolling Restarts
One very useful integration with Consul is for application deploys. We simply wire specific events for various services, and use this to trigger downloading
the new binaries and performing a rolling restart of the service. This makes updates as simple as issuing a single “consul exec”.
76. Client-Side Leader Election
Highly Available Services, N+1 Deploys
It also provides an essential building block for doing client-side leader election. This allows us to have highly available services. Instead of deploying a
single instance of a service, we can deploy N+1 and use the leader election to ensure only one instances is running. Best of all, Consul gives us insight into
details like who is the current leader very easily.
77. Service Coordination
• StorageLocker, BLOB Storage
• Write-Ahead-Logs
• Atomic Multi-Part Uploads
Lastly, one of my favorite uses of Consul internally is for a service we call StorageLocker. It is a relatively simple service, it provides BLOB Storage with a
simple Put, Get, Delete API. StorageLocker protects against partial failures by using a Write Ahead Log. The WAL logs are stored in Consul and tied to its
Session and Health Checking. This allows us to get atomic multi part uploads to backends like S3.
78. We have a blog post that covers how this works in more detail, but at a very high level, we create a WAL entry in Consul before uploading or deleting files
from the storage backend. We can either commit the WAL entry on success or we can abort and rollback. If the StorageLocker instance handling the
request dies, the other instances can detect this using Consul and automatically start the rollback. Using Consul in this way didn’t add much complexity
but dramatically increased the robustness of the service.
79. Consul + Vagrant Cloud
• Simplified Operations
• More Robust Applications
• Realtime Reactions
• Minimum Ops Pain!
In summary, using Consul with Vagrant Cloud has simplified our ops efforts. Building our applications in a Consul aware manner has allowed us to make
more robust applications by using the available primitives instead of rolling them into the app. We get real-time responsiveness to changes in
configuration or deployed instance, and best of all we’ve suffered no ops pain. It just works.
80. Industry Use
• Many Industry Deploys
• Power Tail
• Few “Very Large”
• Several “Large”
• Many “Medium”
In addition to powering Vagrant Cloud, Consul is seeing deployments in Industry as well. It’s hard to give exact usage numbers, but we’ve had over 100K+
downloads of Consul so far. Of course most deployments aren’t large, but we work with a few customers who have “Large” and “Very Large” Deploys.
81. Lithium Networks
• SaaS, Fortune 500 Customers
• Hybrid Cloud
• Physical, OpenStack, AWS
One of the “large” deploys of Consul is by a very large SaaS company, Lithium Networks. They have a complex hybrid cloud infrastructure that spans
physical hardware, OpenStack and AWS.
82. Deployment Stats
• 1000+ Nodes
• 4 Datacenters
• 3 Environments (QA, Stage, Prod)
• Service Discovery
• 15% Fleet Reduction
This particular deployment has over 1000 nodes. This spans 4 datacenters, with 3 different regions per data center. They are primarily using Consul for
Service Discovery, but they’ve already reduced their fleet size by 15% by just removing intermediary load balancers.
83. CDN Company
• “Very Large” Deployment
• 2000+ Machines
• 12+ POPs
Another “Very Large” deployment comes from a CDN Company. Unfortunately we are also still waiting on legal to release their name. They operate at a
massive scale, with over 2000 machines and over 12 points-of-presense, each which operates as a datacenter.
84. Consul @ CDN Company
• Replacing ZooKeeper
• DNS + HAProxy Discovery
• Application Configs in KV, not CM
• Client-Side Election for Orchestration
• Move Fast, Less Ops
These guys are aggressively adopting Consul and taking advantage of the features it provides. They are replacing their ZooKeeper usage. In doing so,
they are adopting DNS and HAProxy for service discovery internally. Application configuration is moving from config management tools. They are also
using Consul to manage client-side leader election in their services. For them, Consul enables them to move faster and do less ops.
85. Over the Horizon
• Power Tail
• Many deploys with 100’s of Servers
• Next order of magnitude
This is just two anecdotes. There are lots of other deploys of various size, but most follow a power tail. There are many more deploys in the hundreds of
nodes scale as well. At the same time, we are actively working with some customers on testing Consul with an order of magnitude large clusters than
we’ve seen so far. Hopefully we’ll get to talk about them at the next conference!
86. Common Challenges
• Infrastructure is a means to an ends
• Service Discovery
• Monitoring
• Configuration
• Orchestration
One thing I want to point out is that with Vagrant Cloud, and all our industry users, Infrastructure is a means to an ends. The value is in the application
layer. Simultaneously, almost all of us are faced with the same challenges. We all need to have service discovery, monitoring, configuration and
orchestration. However, until now we’ve lacked good tooling to do this.
87. Patchwork Solutions
• Re-invent the wheel
• Done Right vs Done Fast
• Maintenance
• Minimum Viable vs Maximum Utility
Instead what we see is a patch work of different systems being glued together. This involves a lot of re-inventing the wheel, tradeoffs between doing it
something correctly or quickly. It also burdens an organization with maintaining their solution. As a result of this, most solutions are of the minimum viable
as opposed to providing the most utility possible.
88. Datacenter Control Plane
Instead, we propose Consul as the alternative. It provides a single answer for all of the runtime problems in a datacenter, and can act as the single control
plane.
89. Consul
• “Batteries Included”
• Works at Scale
• Robust + Reactive Infrastructure
Consul comes with all the batteries included. You don’t need to figure out how to piece everything together, it just works out of the box. It is also
designed to work at scale, so you can deploy it with a dozen servers and scale to thousands without worrying about redesigning your entire architecture. It
also allows you to build a more robust and reactive infrastructure as a whole, reducing operations pain and allowing you to move faster.