Have you ever built a service where, if you could just maintain a bit of state, the world would be a much simpler place? This presentation will take you on a journey through the wonderful world of stateful services in a distributed environment. It'll introduce you to some basic concepts that will require re-orienting your mind to think about statefulness vs statelessness, some common use cases for stateful services, the pitfalls to avoid, and my own experience building a highly available, high throughput stateful workflow engine. And, as a bonus, learn how you are already using stateful services in production today (and might not know about it) along with easy ways to get started in case you aren't.
Resilient microservices with Kubernetes - Mete Atamel - Codemotion Rome 2017Codemotion
Creating a single microservice is a well-understood problem. Creating a cluster of load-balanced microservices that are resilient and self-healing is not so easy. Managing that cluster with rollouts and rollbacks, scaling individual services on demand, securely sharing secrets and configuration among services is even harder. Kubernetes, an open source container management system, can help with this. In this talk, we will learn what makes Kubernetes a great system for automating deployment, operations, and scaling of containerized applications.
Kubernetes Architecture and Introduction – Paris Kubernetes MeetupStefan Schimanski
The document provides an overview of Kubernetes architecture and introduces how to deploy Kubernetes clusters on different platforms like Mesosphere's DCOS, Google Container Engine, and Mesos/Docker. It discusses the core components of Kubernetes including the API server, scheduler, controller manager and kubelet. It also demonstrates how to interact with Kubernetes using kubectl and view cluster state.
Kubernetes is an open-source system for managing containerized applications across multiple hosts. It includes key components like Pods, Services, ReplicationControllers, and a master node for managing the cluster. The master maintains state using etcd and schedules containers on worker nodes, while nodes run the kubelet daemon to manage Pods and their containers. Kubernetes handles tasks like replication, rollouts, and health checking through its API objects.
This document provides an introduction and overview of Kubernetes. It begins by discussing the state of modern infrastructure and applications, and how microservices architectures help address these challenges. It then introduces containers and Docker as a way to package and run applications. Kubernetes is presented as an open source tool for orchestrating and managing containers at scale. The rest of the document outlines some key Kubernetes concepts like pods, replication controllers, services, labels and selectors. It concludes by noting there will be a demo of these Kubernetes features.
Vladimir Primakov - Qa management in big agile teamsIevgenii Katsan
- Using a straightforward release pipeline with separate teams focused on new features or bug fixes to avoid context switching and overlapping work.
- Conducting cross-team planning and reviews to identify dependencies, risks, and adjust testing scope and approach accordingly.
- Establishing common processes, tools, and data across teams through alignment and documentation to facilitate collaboration.
- Ensuring infrastructure like test environments are automated, stable, and similar to production to support efficient testing across large teams.
Real case studies of QA management in big teams (60-100 people). How to setup robust QA processes and approaches in them. Main impediments and problems, how to solve them. SAFe.
Yan Cui - Applying principles of chaos engineering to Serverless - Codemotion...Codemotion
Most of the existing tools and articles around chaos engineering focus on killing servers, but what do you do when you can no longer access the underlying infrastructure? How can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions? These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Resilient microservices with Kubernetes - Mete Atamel - Codemotion Rome 2017Codemotion
Creating a single microservice is a well-understood problem. Creating a cluster of load-balanced microservices that are resilient and self-healing is not so easy. Managing that cluster with rollouts and rollbacks, scaling individual services on demand, securely sharing secrets and configuration among services is even harder. Kubernetes, an open source container management system, can help with this. In this talk, we will learn what makes Kubernetes a great system for automating deployment, operations, and scaling of containerized applications.
Kubernetes Architecture and Introduction – Paris Kubernetes MeetupStefan Schimanski
The document provides an overview of Kubernetes architecture and introduces how to deploy Kubernetes clusters on different platforms like Mesosphere's DCOS, Google Container Engine, and Mesos/Docker. It discusses the core components of Kubernetes including the API server, scheduler, controller manager and kubelet. It also demonstrates how to interact with Kubernetes using kubectl and view cluster state.
Kubernetes is an open-source system for managing containerized applications across multiple hosts. It includes key components like Pods, Services, ReplicationControllers, and a master node for managing the cluster. The master maintains state using etcd and schedules containers on worker nodes, while nodes run the kubelet daemon to manage Pods and their containers. Kubernetes handles tasks like replication, rollouts, and health checking through its API objects.
This document provides an introduction and overview of Kubernetes. It begins by discussing the state of modern infrastructure and applications, and how microservices architectures help address these challenges. It then introduces containers and Docker as a way to package and run applications. Kubernetes is presented as an open source tool for orchestrating and managing containers at scale. The rest of the document outlines some key Kubernetes concepts like pods, replication controllers, services, labels and selectors. It concludes by noting there will be a demo of these Kubernetes features.
Vladimir Primakov - Qa management in big agile teamsIevgenii Katsan
- Using a straightforward release pipeline with separate teams focused on new features or bug fixes to avoid context switching and overlapping work.
- Conducting cross-team planning and reviews to identify dependencies, risks, and adjust testing scope and approach accordingly.
- Establishing common processes, tools, and data across teams through alignment and documentation to facilitate collaboration.
- Ensuring infrastructure like test environments are automated, stable, and similar to production to support efficient testing across large teams.
Real case studies of QA management in big teams (60-100 people). How to setup robust QA processes and approaches in them. Main impediments and problems, how to solve them. SAFe.
Yan Cui - Applying principles of chaos engineering to Serverless - Codemotion...Codemotion
Most of the existing tools and articles around chaos engineering focus on killing servers, but what do you do when you can no longer access the underlying infrastructure? How can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions? These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Applying principles of chaos engineering to Serverless (CodeMotion Berlin)Yan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Yan Cui - Applying principles of chaos engineering to Serverless - Codemotion...Codemotion
The document discusses applying principles of chaos engineering to serverless architectures. It describes challenges with chaos engineering in serverless due to the lack of servers to inject failures into. It then discusses approaches to injecting latency and errors into serverless functions and downstream services as part of controlled experiments to test resiliency. The goal is not to break systems but to uncover weaknesses and improve robustness. Containment of experiments is emphasized.
Applying principles of chaos engineering to serverless (O'Reilly Software Arc...Yan Cui
This document summarizes a talk on applying principles of chaos engineering to serverless applications. It discusses defining steady state, injecting realistic failures like latency and errors, and using controlled experiments to build confidence in a system's ability to withstand failures in production. Specifically for serverless, it addresses challenges like smaller units of deployment and many managed services, and demonstrates how to inject latency and errors at different points to test failure handling. The goal is learning from failures, not intentionally breaking systems, so containment is important.
How do you implement Continuous Delivery? Part 3: All about PipelinesThoughtworks
This document discusses pipelines for continuous delivery. It describes how pipelines can incorporate progressive testing from unit tests to system integration tests. A typical pipeline includes stages for committing code, building, running unit tests, code analysis, and creating build artifacts. Deployment testing stages prepare environments, deploy artifacts, and run smoke and UI tests. Best practices are to keep everything in source control and replicate production. The document also discusses how to structure pipelines for multiple applications and federated systems.
Applying principles of chaos engineering to ServerlessYan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Applying principles of chaos engineering to ServerlessYan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Applying principles of chaos engineering to serverlessYan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Join us in this talk as Yan Cui shares his thought experiments, and actual experiments, in his pursuit to understand how we can apply the principles of chaos to a serverless architecture. A word of warning though, you’re guaranteed to walk away with more questions than answers!
Applying principles of chaos engineering to serverlessYan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Join us in this talk as Yan Cui shares his thought experiments, and actual experiments, in his pursuit to understand how we can apply the principles of chaos to a serverless architecture.
Last.fm - Lessons from building the World's largest social music platform randomfromtheweb
The document discusses the growth and development of Last.fm, the world's largest social music platform. It describes how Last.fm started in 2004 and grew rapidly by being open with its data and involving users. As it grew from 20 to 40+ employees in 6 months, it emphasized radiating information across the company through simple tools like IRC chat logs. The excerpt shows developers coordinating fixes and improvements in real-time.
Applying principles of chaos engineering to serverless (CodeMesh)Yan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
The presentation paper will touch on our recent contribution to improve the current WordPress security ecosystem. WordPress in itself has grown from just being a Blogging platform to a full-fledged CMS Application and hence people are increasingly using it for multitude of projects or purposes. WordPress Ecosystem has recently been targeted with large number of security issues and we have witnessed the whole depth and breadth of OWASP top 10′s being exploitable in multiple instances. Today’s statistics on WordPress show that there are more than 28000+ plugins and close to 2000+ Themes. However from a security standpoint we have also seen a painful growing trend of the issues that crop-up with both WordPress core as well as the plugin and theme sections. We have decided to stop being a spectator and contribute to the cause and hence we are doing the following activity which will be part of the final outcome:
Analyze the existing vulnerabilities and new issues being reported on a regular basis.
Identify new issues within the plugin and themes (WordPress core we are targeting as a secondary target), report the issue, get the patch released or get the plugin closed on the WordPress repository. The Research/presentation will also describe methods of automating ways to discover vulnerabilities on the entire 28K list of plugins and 2K Themes.
We will strive to get the issues fixed and then only release the details. However, in case the plugin/theme author is not responding and we can only get the plugin closed then we will go ahead with the disclosure in order to get this issue out in public. The final outcome / presentation will touch base on the vulnerability landscape, common issues and quick fixes for those issues and will also coincide with a comprehensive guideline for developers to protect their own plugin’s. We will be updating all our vulnerabilities on our website (will be disclosed) as and when they are patched.
The document summarizes Prajal Kulkarni's project to find security vulnerabilities in the WordPress ecosystem. Over a period of a few months, they found over 100 Common Vulnerabilities and Exposures (CVEs) using both manual and automated techniques. Their automated scanning uncovered many cross-site scripting and file inclusion issues. They reported vulnerabilities to developers and plugin maintainers to get issues patched or plugins removed from repositories. Their goal is to improve WordPress security through their CodeVigilant project.
- Lifeguard is a set of optimizations to the SWIM protocol and memberlist failure detector to make it more robust. It addresses issues seen in the field of healthy nodes being falsely detected as failed.
- Lifeguard introduces three components: self-awareness using a node status counter, dogpiling requiring multiple independent suspicions before failure detection, and a buddy system to more quickly allow nodes to refute suspicions.
- Experiments show Lifeguard significantly reduces false positives, with modest increases to latency and network load in pathological situations. It provides a tunable way for users to tradeoff failures detection speed and false positives.
One of the most magical parts of Habitat is service discovery. Come to this talk to see the beauty of Habitat service discovery in action - how running services become aware of new services, self organize into defined topologies, and handle failure - all without any central orchestrator. Additionally, you will take a deep technical dive into WHY Habitat handles service discovery the way it does and the tradeoffs we made in constructing it. The better you understand the why of Habitat service discovery, the better you will be able to harness its power for your own organization!
Whiskey, Tango, Foxtrot: Understanding API UsageClay Loveless
Launch an API that can survive! Learn about unexpected load recovery techniques, analytic best practices and testing approaches to make sure your API runs smoothly & thrives with these tips from the trenches. Clay Loveless is Mashery's Chief Architect, the leading API management solution provider. With over 100 high-volume API customers, Mashery manages a broad range of enterprise API deployments.
Patterns of the Lambda Architecture -- 2015 April - Hadoop Summit, EuropeFlip Kromer
This talk centers on two things: a set of patterns for the architecture of high-scale data systems; and a framework for understanding the tradeoffs we make in designing them.
Applying principles of chaos engineering to serverless (ServerlessCPH)Yan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Join us in this talk as Yan Cui shares his thought experiments, and actual experiments, in his pursuit to understand how we can apply the principles of chaos to a serverless architecture. A word of warning though, you’re guaranteed to walk away with more questions than answers!
How did I get here? Building confidence in a distributed stream processorSean T Allen
When we build a distributed application, how do we have confidence that our results are correct? We can test our business logic over and over but if the engine executing it isn't trustworthy, we can't trust our results.
How can we build trust in our execution engines? We need to test them. It's hard enough to test a stream processor that runs on a single machine, it gets even more complicated when you start talking about a distributed stream processor. As Kyle Kingsbury's Jepsen series has shown, we have a long way to go creating tests that can provide confidence that our systems are trustworthy.
At Sendence, we're building a distributed streaming data analytics engine that we want to prove is trustworthy. This talk will focus on the various means we have come up with to create repeatable tests that allow us to start trusting that our system will give correct results. You’ll learn how to combine repeatable programmatic fault injection, message tracing, and auditing to create a trustworthy system. Together, we’ll move through the design process repeatedly answering the questions “What do we have to do to trust this result?” and “If we get the wrong result, how can we determine what went wrong so we can fix it?”.
Sri Guru Hargobind Ji - Bandi Chor Guru.pdfBalvir Singh
Sri Guru Hargobind Ji (19 June 1595 - 3 March 1644) is revered as the Sixth Nanak.
• On 25 May 1606 Guru Arjan nominated his son Sri Hargobind Ji as his successor. Shortly
afterwards, Guru Arjan was arrested, tortured and killed by order of the Mogul Emperor
Jahangir.
• Guru Hargobind's succession ceremony took place on 24 June 1606. He was barely
eleven years old when he became 6th Guru.
• As ordered by Guru Arjan Dev Ji, he put on two swords, one indicated his spiritual
authority (PIRI) and the other, his temporal authority (MIRI). He thus for the first time
initiated military tradition in the Sikh faith to resist religious persecution, protect
people’s freedom and independence to practice religion by choice. He transformed
Sikhs to be Saints and Soldier.
• He had a long tenure as Guru, lasting 37 years, 9 months and 3 days
More Related Content
Similar to Desert Code Camp 2016.1 - Stateful Distributed Systems
Applying principles of chaos engineering to Serverless (CodeMotion Berlin)Yan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Yan Cui - Applying principles of chaos engineering to Serverless - Codemotion...Codemotion
The document discusses applying principles of chaos engineering to serverless architectures. It describes challenges with chaos engineering in serverless due to the lack of servers to inject failures into. It then discusses approaches to injecting latency and errors into serverless functions and downstream services as part of controlled experiments to test resiliency. The goal is not to break systems but to uncover weaknesses and improve robustness. Containment of experiments is emphasized.
Applying principles of chaos engineering to serverless (O'Reilly Software Arc...Yan Cui
This document summarizes a talk on applying principles of chaos engineering to serverless applications. It discusses defining steady state, injecting realistic failures like latency and errors, and using controlled experiments to build confidence in a system's ability to withstand failures in production. Specifically for serverless, it addresses challenges like smaller units of deployment and many managed services, and demonstrates how to inject latency and errors at different points to test failure handling. The goal is learning from failures, not intentionally breaking systems, so containment is important.
How do you implement Continuous Delivery? Part 3: All about PipelinesThoughtworks
This document discusses pipelines for continuous delivery. It describes how pipelines can incorporate progressive testing from unit tests to system integration tests. A typical pipeline includes stages for committing code, building, running unit tests, code analysis, and creating build artifacts. Deployment testing stages prepare environments, deploy artifacts, and run smoke and UI tests. Best practices are to keep everything in source control and replicate production. The document also discusses how to structure pipelines for multiple applications and federated systems.
Applying principles of chaos engineering to ServerlessYan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Applying principles of chaos engineering to ServerlessYan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Applying principles of chaos engineering to serverlessYan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Join us in this talk as Yan Cui shares his thought experiments, and actual experiments, in his pursuit to understand how we can apply the principles of chaos to a serverless architecture. A word of warning though, you’re guaranteed to walk away with more questions than answers!
Applying principles of chaos engineering to serverlessYan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Join us in this talk as Yan Cui shares his thought experiments, and actual experiments, in his pursuit to understand how we can apply the principles of chaos to a serverless architecture.
Last.fm - Lessons from building the World's largest social music platform randomfromtheweb
The document discusses the growth and development of Last.fm, the world's largest social music platform. It describes how Last.fm started in 2004 and grew rapidly by being open with its data and involving users. As it grew from 20 to 40+ employees in 6 months, it emphasized radiating information across the company through simple tools like IRC chat logs. The excerpt shows developers coordinating fixes and improvements in real-time.
Applying principles of chaos engineering to serverless (CodeMesh)Yan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
The presentation paper will touch on our recent contribution to improve the current WordPress security ecosystem. WordPress in itself has grown from just being a Blogging platform to a full-fledged CMS Application and hence people are increasingly using it for multitude of projects or purposes. WordPress Ecosystem has recently been targeted with large number of security issues and we have witnessed the whole depth and breadth of OWASP top 10′s being exploitable in multiple instances. Today’s statistics on WordPress show that there are more than 28000+ plugins and close to 2000+ Themes. However from a security standpoint we have also seen a painful growing trend of the issues that crop-up with both WordPress core as well as the plugin and theme sections. We have decided to stop being a spectator and contribute to the cause and hence we are doing the following activity which will be part of the final outcome:
Analyze the existing vulnerabilities and new issues being reported on a regular basis.
Identify new issues within the plugin and themes (WordPress core we are targeting as a secondary target), report the issue, get the patch released or get the plugin closed on the WordPress repository. The Research/presentation will also describe methods of automating ways to discover vulnerabilities on the entire 28K list of plugins and 2K Themes.
We will strive to get the issues fixed and then only release the details. However, in case the plugin/theme author is not responding and we can only get the plugin closed then we will go ahead with the disclosure in order to get this issue out in public. The final outcome / presentation will touch base on the vulnerability landscape, common issues and quick fixes for those issues and will also coincide with a comprehensive guideline for developers to protect their own plugin’s. We will be updating all our vulnerabilities on our website (will be disclosed) as and when they are patched.
The document summarizes Prajal Kulkarni's project to find security vulnerabilities in the WordPress ecosystem. Over a period of a few months, they found over 100 Common Vulnerabilities and Exposures (CVEs) using both manual and automated techniques. Their automated scanning uncovered many cross-site scripting and file inclusion issues. They reported vulnerabilities to developers and plugin maintainers to get issues patched or plugins removed from repositories. Their goal is to improve WordPress security through their CodeVigilant project.
- Lifeguard is a set of optimizations to the SWIM protocol and memberlist failure detector to make it more robust. It addresses issues seen in the field of healthy nodes being falsely detected as failed.
- Lifeguard introduces three components: self-awareness using a node status counter, dogpiling requiring multiple independent suspicions before failure detection, and a buddy system to more quickly allow nodes to refute suspicions.
- Experiments show Lifeguard significantly reduces false positives, with modest increases to latency and network load in pathological situations. It provides a tunable way for users to tradeoff failures detection speed and false positives.
One of the most magical parts of Habitat is service discovery. Come to this talk to see the beauty of Habitat service discovery in action - how running services become aware of new services, self organize into defined topologies, and handle failure - all without any central orchestrator. Additionally, you will take a deep technical dive into WHY Habitat handles service discovery the way it does and the tradeoffs we made in constructing it. The better you understand the why of Habitat service discovery, the better you will be able to harness its power for your own organization!
Whiskey, Tango, Foxtrot: Understanding API UsageClay Loveless
Launch an API that can survive! Learn about unexpected load recovery techniques, analytic best practices and testing approaches to make sure your API runs smoothly & thrives with these tips from the trenches. Clay Loveless is Mashery's Chief Architect, the leading API management solution provider. With over 100 high-volume API customers, Mashery manages a broad range of enterprise API deployments.
Patterns of the Lambda Architecture -- 2015 April - Hadoop Summit, EuropeFlip Kromer
This talk centers on two things: a set of patterns for the architecture of high-scale data systems; and a framework for understanding the tradeoffs we make in designing them.
Applying principles of chaos engineering to serverless (ServerlessCPH)Yan Cui
Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users.
Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions.
But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions?
These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems.
Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?
Join us in this talk as Yan Cui shares his thought experiments, and actual experiments, in his pursuit to understand how we can apply the principles of chaos to a serverless architecture. A word of warning though, you’re guaranteed to walk away with more questions than answers!
How did I get here? Building confidence in a distributed stream processorSean T Allen
When we build a distributed application, how do we have confidence that our results are correct? We can test our business logic over and over but if the engine executing it isn't trustworthy, we can't trust our results.
How can we build trust in our execution engines? We need to test them. It's hard enough to test a stream processor that runs on a single machine, it gets even more complicated when you start talking about a distributed stream processor. As Kyle Kingsbury's Jepsen series has shown, we have a long way to go creating tests that can provide confidence that our systems are trustworthy.
At Sendence, we're building a distributed streaming data analytics engine that we want to prove is trustworthy. This talk will focus on the various means we have come up with to create repeatable tests that allow us to start trusting that our system will give correct results. You’ll learn how to combine repeatable programmatic fault injection, message tracing, and auditing to create a trustworthy system. Together, we’ll move through the design process repeatedly answering the questions “What do we have to do to trust this result?” and “If we get the wrong result, how can we determine what went wrong so we can fix it?”.
Similar to Desert Code Camp 2016.1 - Stateful Distributed Systems (20)
Sri Guru Hargobind Ji - Bandi Chor Guru.pdfBalvir Singh
Sri Guru Hargobind Ji (19 June 1595 - 3 March 1644) is revered as the Sixth Nanak.
• On 25 May 1606 Guru Arjan nominated his son Sri Hargobind Ji as his successor. Shortly
afterwards, Guru Arjan was arrested, tortured and killed by order of the Mogul Emperor
Jahangir.
• Guru Hargobind's succession ceremony took place on 24 June 1606. He was barely
eleven years old when he became 6th Guru.
• As ordered by Guru Arjan Dev Ji, he put on two swords, one indicated his spiritual
authority (PIRI) and the other, his temporal authority (MIRI). He thus for the first time
initiated military tradition in the Sikh faith to resist religious persecution, protect
people’s freedom and independence to practice religion by choice. He transformed
Sikhs to be Saints and Soldier.
• He had a long tenure as Guru, lasting 37 years, 9 months and 3 days
Tools & Techniques for Commissioning and Maintaining PV Systems W-Animations ...Transcat
Join us for this solutions-based webinar on the tools and techniques for commissioning and maintaining PV Systems. In this session, we'll review the process of building and maintaining a solar array, starting with installation and commissioning, then reviewing operations and maintenance of the system. This course will review insulation resistance testing, I-V curve testing, earth-bond continuity, ground resistance testing, performance tests, visual inspections, ground and arc fault testing procedures, and power quality analysis.
Fluke Solar Application Specialist Will White is presenting on this engaging topic:
Will has worked in the renewable energy industry since 2005, first as an installer for a small east coast solar integrator before adding sales, design, and project management to his skillset. In 2022, Will joined Fluke as a solar application specialist, where he supports their renewable energy testing equipment like IV-curve tracers, electrical meters, and thermal imaging cameras. Experienced in wind power, solar thermal, energy storage, and all scales of PV, Will has primarily focused on residential and small commercial systems. He is passionate about implementing high-quality, code-compliant installation techniques.
Impartiality as per ISO /IEC 17025:2017 StandardMuhammadJazib15
This document provides basic guidelines for imparitallity requirement of ISO 17025. It defines in detial how it is met and wiudhwdih jdhsjdhwudjwkdbjwkdddddddddddkkkkkkkkkkkkkkkkkkkkkkkwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwioiiiiiiiiiiiii uwwwwwwwwwwwwwwwwhe wiqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq gbbbbbbbbbbbbb owdjjjjjjjjjjjjjjjjjjjj widhi owqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq uwdhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhwqiiiiiiiiiiiiiiiiiiiiiiiiiiiiw0pooooojjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj whhhhhhhhhhh wheeeeeeee wihieiiiiii wihe
e qqqqqqqqqqeuwiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiqw dddddddddd cccccccccccccccv s w c r
cdf cb bicbsad ishd d qwkbdwiur e wetwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww w
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffw
uuuuhhhhhhhhhhhhhhhhhhhhhhhhe qiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccc bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbu uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuum
m
m mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm m i
g i dijsd sjdnsjd ndjajsdnnsa adjdnawddddddddddddd uw
Digital Twins Computer Networking Paper Presentation.pptxaryanpankaj78
A Digital Twin in computer networking is a virtual representation of a physical network, used to simulate, analyze, and optimize network performance and reliability. It leverages real-time data to enhance network management, predict issues, and improve decision-making processes.
An In-Depth Exploration of Natural Language Processing: Evolution, Applicatio...DharmaBanothu
Natural language processing (NLP) has
recently garnered significant interest for the
computational representation and analysis of human
language. Its applications span multiple domains such
as machine translation, email spam detection,
information extraction, summarization, healthcare,
and question answering. This paper first delineates
four phases by examining various levels of NLP and
components of Natural Language Generation,
followed by a review of the history and progression of
NLP. Subsequently, we delve into the current state of
the art by presenting diverse NLP applications,
contemporary trends, and challenges. Finally, we
discuss some available datasets, models, and
evaluation metrics in NLP.
Accident detection system project report.pdfKamal Acharya
The Rapid growth of technology and infrastructure has made our lives easier. The
advent of technology has also increased the traffic hazards and the road accidents take place
frequently which causes huge loss of life and property because of the poor emergency facilities.
Many lives could have been saved if emergency service could get accident information and
reach in time. Our project will provide an optimum solution to this draw back. A piezo electric
sensor can be used as a crash or rollover detector of the vehicle during and after a crash. With
signals from a piezo electric sensor, a severe accident can be recognized. According to this
project when a vehicle meets with an accident immediately piezo electric sensor will detect the
signal or if a car rolls over. Then with the help of GSM module and GPS module, the location
will be sent to the emergency contact. Then after conforming the location necessary action will
be taken. If the person meets with a small accident or if there is no serious threat to anyone’s
life, then the alert message can be terminated by the driver by a switch provided in order to
avoid wasting the valuable time of the medical rescue team.
This study Examines the Effectiveness of Talent Procurement through the Imple...DharmaBanothu
In the world with high technology and fast
forward mindset recruiters are walking/showing interest
towards E-Recruitment. Present most of the HRs of
many companies are choosing E-Recruitment as the best
choice for recruitment. E-Recruitment is being done
through many online platforms like Linkedin, Naukri,
Instagram , Facebook etc. Now with high technology E-
Recruitment has gone through next level by using
Artificial Intelligence too.
Key Words : Talent Management, Talent Acquisition , E-
Recruitment , Artificial Intelligence Introduction
Effectiveness of Talent Acquisition through E-
Recruitment in this topic we will discuss about 4important
and interlinked topics which are
Open Channel Flow: fluid flow with a free surfaceIndrajeet sahu
Open Channel Flow: This topic focuses on fluid flow with a free surface, such as in rivers, canals, and drainage ditches. Key concepts include the classification of flow types (steady vs. unsteady, uniform vs. non-uniform), hydraulic radius, flow resistance, Manning's equation, critical flow conditions, and energy and momentum principles. It also covers flow measurement techniques, gradually varied flow analysis, and the design of open channels. Understanding these principles is vital for effective water resource management and engineering applications.
2. Amazon is hiring!
To learn more about our Dev Centers: http://bit.ly/phxdevcenters
To learn more about current opportunities, email: phx@amazon.com
Our mission is to provide the
most innovative, scalable,
and reliable systems in the
world.
24. Required to do something useful
Stateful Services
You’re already doing it!
25. Required to do something useful
Stateful Services
(most of the time)
You’re already doing it!
26. Required to do something useful
Stateful Services
(most of the time)
You’re already doing it!
stateful processing systems share
similar concerns
27. Required to do something useful
Stateful Services
(most of the time)
You’re already doing it!
stateful processing systems share
similar concerns
(This is where the fun is)
72. SWIM Protocol
failure detection
1. ping random process from member list
A. Receives Ack, Great! end
B. does not receive ack, goto 2
2. send ping request to k processes from member list
73. SWIM Protocol
failure detection
1. ping random process from member list
A. Receives Ack, Great! end
B. does not receive ack, goto 2
2. send ping request to k processes from member list
3. k processes try to ping “failed” process
74. SWIM Protocol
failure detection
1. ping random process from member list
A. Receives Ack, Great! end
B. does not receive ack, goto 2
2. send ping request to k processes from member list
3. k processes try to ping “failed” process
A. K processes respond back to original process about
status
75. SWIM Protocol
failure detection
1. ping random process from member list
A. Receives Ack, Great! end
B. does not receive ack, goto 2
2. send ping request to k processes from member list
3. k processes try to ping “failed” process
A. K processes respond back to original process about
status
dissemination
76. SWIM Protocol
failure detection
1. ping random process from member list
A. Receives Ack, Great! end
B. does not receive ack, goto 2
2. send ping request to k processes from member list
3. k processes try to ping “failed” process
A. K processes respond back to original process about
status
dissemination
multicast failure (vol. leave) updates
77. SWIM Protocol
failure detection
1. ping random process from member list
A. Receives Ack, Great! end
B. does not receive ack, goto 2
2. send ping request to k processes from member list
3. k processes try to ping “failed” process
A. K processes respond back to original process about
status
dissemination
multicast failure (vol. leave) updates
multicast new members
92. Paxos
Proposers, Acceptors, Learners
Proposers:
Acceptors:
Ask Acceptors to Approve Proposals
Ask Acceptors to accept a proposal & Version
Do not have to approve or accept
Only Approve/Accept what has been proposed
LEARNERS: Proposed Value is chosen when a majority of
Acceptors have accepted the value
98. Paxos
Proposers, Acceptors, Learners
Phase 1:
1) Proposers propose a value
2) Acceptors approve value
1) not approve or accept smaller values
2) send back highest (accepted) version
99. Paxos
Proposers, Acceptors, Learners
Phase 1:
1) Proposers propose a value
2) Acceptors approve value
1) not approve or accept smaller values
2) send back highest (accepted) version
Phase 2:
100. Paxos
Proposers, Acceptors, Learners
Phase 1:
1) Proposers propose a value
2) Acceptors approve value
1) not approve or accept smaller values
2) send back highest (accepted) version
Phase 2:
1) proposer Receives approval from majority
101. Paxos
Proposers, Acceptors, Learners
Phase 1:
1) Proposers propose a value
2) Acceptors approve value
1) not approve or accept smaller values
2) send back highest (accepted) version
Phase 2:
1) proposer Receives approval from majority
2) sends accept! to acceptors with highest
version
102. Paxos
Proposers, Acceptors, Learners
Phase 1:
1) Proposers propose a value
2) Acceptors approve value
1) not approve or accept smaller values
2) send back highest (accepted) version
Phase 2:
1) proposer Receives approval from majority
2) sends accept! to acceptors with highest
version
Phase 3:
103. Paxos
Proposers, Acceptors, Learners
Phase 1:
1) Proposers propose a value
2) Acceptors approve value
1) not approve or accept smaller values
2) send back highest (accepted) version
Phase 2:
1) proposer Receives approval from majority
2) sends accept! to acceptors with highest
version
Phase 3: 1) acceptors notify all learners
117. Consistent Hashing
Distributed Hash Tables
Convenient, Fast O(1)
Great for lookups given a key
Issue
Horizontal scaling
Fault Tolerance
hash(object) (mod n)
n = number of slots
118. Consistent Hashing
Distributed Hash Tables
Convenient, Fast O(1)
Great for lookups given a key
Issue
Horizontal scaling
Fault Tolerance
hash(object) (mod n)
Remapping keys to more slots
n = number of slots
120. Consistent Hashing
Distributed Hash Tables
Convenient, Fast O(1)
Great for Key / Value lookups
Solution
consistent hashing
K = keys, n = number of slots
121. Consistent Hashing
Distributed Hash Tables
Convenient, Fast O(1)
Great for Key / Value lookups
Solution
consistent hashing
During resize, k / n keys are remapped
K = keys, n = number of slots
136. Key Takeaways
Stateful and Stateless systems co-exist
process lifecycle vs data lifecyCle
Stateful services have their place
137. Key Takeaways
Stateful and Stateless systems co-exist
process lifecycle vs data lifecyCle
Stateful services have their place
Interesting opportunities
138. Key Takeaways
Stateful and Stateless systems co-exist
process lifecycle vs data lifecyCle
Stateful services have their place
Interesting opportunities
But not all is rosy
139. Dynamo: Amazon’s Highly Available Key-value Store
http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
Papers We Love
The Chubby lock service for loosely-coupled distributed systems
research.google.com/archive/chubby-osdi06.pdf
Paxos made simple
http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf
Time, Clocks, and the Ordering of Events in a Distributed System
http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf
The Google File System
http://research.google.com/archive/gfs-sosp2003.pdf
141. Thanks!
Q&A
Amazon is hiring!
To learn more about our Dev Centers: http://bit.ly/phxdevcenters
To learn more about current opportunities, email: phx@amazon.com