The Importance of Culture: Building and Sustaining Effective Engineering Org...Randy Shoup
Randy is a 25-year veteran of Silicon Valley, having led engineering organizations at eBay, Google, Oracle, and a number of other companies. Through the lens of his personal experience from hands-on engineer to architect to CTO, at organizations ranging from tiny startups to global giants, Randy will discuss several important aspects of engineering cultures, which both support and hinder the ability to innovate: hiring and retention, ownership and collaboration, quality and discipline, and learning and experimentation.
Randy will suggest some learnings about what has worked well -- and what has not -- in creating and sustaining an effective engineering culture. He will further offer some concrete suggestions on how other organizations -- both large and small -- can evolve their cultures as well.
One of the most powerful trends in software today is building large systems out of composable microservices. Many large-scale web companies have migrated over time to this architecture – and for good reason. But, as with any powerful technique, microservices come with their own brand of tradeoffs, and it is important to be aware of them before deciding whether they are appropriate in any particular case. They are not for every scale of problem, for every stage of company, or for every team.
This session takes a pragmatic approach to microservices, and compares them to the alternatives at different stages of company evolution. Using examples both from Google and eBay as well as from smaller organizations, it makes practical suggestions about whether, when, and how an organization should consider adopting a microservices architecture. Assuming microservices are the appropriate choice, it outlines an experience-based, incremental approach to making a successful rearchitecture to microservices.
Minimum Viable Architecture -- Good Enough is Good Enough in a StartupRandy Shoup
I have spent the last decade building large-scale systems at eBay and Google -- and talking publicly about it -- and this presentation is about why a startup should completely ignore what I said! In an early-stage startup, it is not only not worth architecting for a future of massive scale; it is actively counterproductive. This presentation from the SF Startup CTO Summit outlines the common architectural evolution of a startup through the search, execution, and scaling phases, and discusses the appropriate technologies and disciplines at each phase. It ends with some real-world examples from eBay, Twitter, and Amazon to illustrate the point.
[AIIM17] It’s Harvest Time in the Information Garden - Dan AntionAIIM International
We’ve been collecting information for many years, driven by the usual suspects: compliance and fear. Now it’s time to take advantage of the information we’ve gathered by shifting our focus from the people who felt they had to keep it to the people who can actually use it. In short, it’s time to reap the benefits of the hard work we have already done. Learn how American Nuclear Insurers is using their information today, the process that got them there, and the technology it took to make it happen.
Learn about the current state of Information Management in AIIM’s latest report: http://info.aiim.org/2017-state-of-information-management
Leadership Without Management: Scaling Organizations by Scaling Engineersbcantrill
My talk at Surge 2013. Video is at http://www.youtube.com/watch?v=bGkVM1B5NuI Caution: Should not be consumed by stack-ranking six-sigma black belts with fragile constitutions.
When going into the development of a software product, a possible source of mistake is the incorrect evaluation of the complexity that lies behind an idea , as well as a clutter coming from the massive amounts of technologies enabled. This presentation explains a possible way to deal with such issues.
DevOpsDays Silicon Valley 2014 - The Game of OperationsRandy Shoup
Operating online games is fun and challenging. Games are some of the spikiest workloads around, and real-time really means *real-time*. Randy shares many of the DevOps techniques his team has put into practice at KIXEYE: Cloud infrastructure, Service teams, and DevOps Culture. He talks about elastic workloads, micro-services, configuration automation, and a common service "chassis". He further discusses the organizational and technical disciplines of team autonomy, internal vendor-customer relationships, and, of course, "you build it, you run it"!
The Importance of Culture: Building and Sustaining Effective Engineering Org...Randy Shoup
Randy is a 25-year veteran of Silicon Valley, having led engineering organizations at eBay, Google, Oracle, and a number of other companies. Through the lens of his personal experience from hands-on engineer to architect to CTO, at organizations ranging from tiny startups to global giants, Randy will discuss several important aspects of engineering cultures, which both support and hinder the ability to innovate: hiring and retention, ownership and collaboration, quality and discipline, and learning and experimentation.
Randy will suggest some learnings about what has worked well -- and what has not -- in creating and sustaining an effective engineering culture. He will further offer some concrete suggestions on how other organizations -- both large and small -- can evolve their cultures as well.
One of the most powerful trends in software today is building large systems out of composable microservices. Many large-scale web companies have migrated over time to this architecture – and for good reason. But, as with any powerful technique, microservices come with their own brand of tradeoffs, and it is important to be aware of them before deciding whether they are appropriate in any particular case. They are not for every scale of problem, for every stage of company, or for every team.
This session takes a pragmatic approach to microservices, and compares them to the alternatives at different stages of company evolution. Using examples both from Google and eBay as well as from smaller organizations, it makes practical suggestions about whether, when, and how an organization should consider adopting a microservices architecture. Assuming microservices are the appropriate choice, it outlines an experience-based, incremental approach to making a successful rearchitecture to microservices.
Minimum Viable Architecture -- Good Enough is Good Enough in a StartupRandy Shoup
I have spent the last decade building large-scale systems at eBay and Google -- and talking publicly about it -- and this presentation is about why a startup should completely ignore what I said! In an early-stage startup, it is not only not worth architecting for a future of massive scale; it is actively counterproductive. This presentation from the SF Startup CTO Summit outlines the common architectural evolution of a startup through the search, execution, and scaling phases, and discusses the appropriate technologies and disciplines at each phase. It ends with some real-world examples from eBay, Twitter, and Amazon to illustrate the point.
[AIIM17] It’s Harvest Time in the Information Garden - Dan AntionAIIM International
We’ve been collecting information for many years, driven by the usual suspects: compliance and fear. Now it’s time to take advantage of the information we’ve gathered by shifting our focus from the people who felt they had to keep it to the people who can actually use it. In short, it’s time to reap the benefits of the hard work we have already done. Learn how American Nuclear Insurers is using their information today, the process that got them there, and the technology it took to make it happen.
Learn about the current state of Information Management in AIIM’s latest report: http://info.aiim.org/2017-state-of-information-management
Leadership Without Management: Scaling Organizations by Scaling Engineersbcantrill
My talk at Surge 2013. Video is at http://www.youtube.com/watch?v=bGkVM1B5NuI Caution: Should not be consumed by stack-ranking six-sigma black belts with fragile constitutions.
When going into the development of a software product, a possible source of mistake is the incorrect evaluation of the complexity that lies behind an idea , as well as a clutter coming from the massive amounts of technologies enabled. This presentation explains a possible way to deal with such issues.
DevOpsDays Silicon Valley 2014 - The Game of OperationsRandy Shoup
Operating online games is fun and challenging. Games are some of the spikiest workloads around, and real-time really means *real-time*. Randy shares many of the DevOps techniques his team has put into practice at KIXEYE: Cloud infrastructure, Service teams, and DevOps Culture. He talks about elastic workloads, micro-services, configuration automation, and a common service "chassis". He further discusses the organizational and technical disciplines of team autonomy, internal vendor-customer relationships, and, of course, "you build it, you run it"!
Being Elastic -- Evolving Programming for the CloudRandy Shoup
eBay Chief Engineer Randy Shoup's keynote at QCon 2010 outlines several critical elements of the evolving cloud programming model – what developers need to do to develop successful systems in the cloud. It discusses state management and statelessness, distribution- and network-awareness, workload partitioning, cost and resource metering, automation readiness, and deployment strategies
Models, Sketches and Everything In BetweenEoin Woods
ust the mention of the word “modeling” brings back horrible memories of analysis paralysis for many software developers. As a result of the conventional wisdom around Agile development that modeling is usually waste, countless software teams have completely abandoned modeling their systems. The problem is that there is a lot of design information that isn’t in the code, and without any models this information can get lost. Over time, the team ends up with a “big ball of mud.”
In this talk we explain what modeling brings to the development process and its value in different situations, discussing the different levels of formality available, from models to sketches and everything in between. Along the way, we share real-world advice on how a little well-chosen modeling can help avoid chaos.
DevOps does not exist in a vacuum; it rests on a social structure and culture that are intertwined. Hierarchies within organizations, industry connections, and globalization all influence culture. At the same time, culture influences social structure and impacts its effectiveness. To complicate matters even more, the tools we use have an overarching influence. Tools can affect our behavior, how we share knowledge, and our organizational hierarchies.
Often, a particular technology is presented as a “best practice” or as the right way to solve a problem. How do we resolve the cognitive dissonance that arises when the “correct” tool is no longer suited to our current environment? As technology increasingly shapes how we work, how do we determine what technologies to adopt to help effect the changes we want?
In this webinar, Chef Software Engineer Jennifer Davis will help you to frame the choices available to you, identify the weaknesses in your environment that your current tools disguise, and be more effective and deliberate with the tools used in your organization.
See the recorded webinar here: https://www.chef.io/blog/event/webinar-effective-tools-for-effective-change/
No Silver Bullet - Essence and Accidents of Software EngineeringAditi Abhang
”There is no single development, in either technology or in management technique, that by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity.”
DSC UTeM DevOps Session#1: Intro to DevOps Presentation SlidesDSC UTeM
DevOps has been such a buzzword in the IT field nowadays. If you look into job postings, you might be surprised to find terms like "work with DevOps team", "work in an agile team" etc.
What is DevOps? What is agile? And why all these? 樂
Join us on 24 May 2021, where we have a short session to explore on the events that led to the trend nowadays
We will be exploring on the current trends, tech stacks and the existence of DevOps itself! 朗
Mark this date on your calendar and we'll see you there!
* Note: This is an introductory "brief overview" session that gives you context on our upcoming events.
Slides by KwongTN.
Thierry de Pauw - Feature Branching considered Evil - Codemotion Milan 2018Codemotion
With DVCSs branch creation became very easy, but it comes at a certain cost. Long living branches break the flow of the software delivery process, impacting stability and throughput. The session explores why teams are using feature branches, what problems are introduced by using them and what techniques exist to avoid them altogether. It explores exactly what's evil about feature branches, which is not necessarily the problems they introduce - but rather, the real reasons why teams are using them. After the session, you'll understand a different branching strategy and how it relates to CI/CD.
The Paradox of Agile Architecture Quality: Designing for FailureJason Bloomberg
Change is fundamental to Agile Architecture. If it’s not the business and their requirements, processes, policies, or metadata that change, it’s the underlying technologies, implementations, and schemas that do. The enterprise is constantly shifting.
The more that we can enable change without having a high penalty cost for that change, the more we enable business agility. Getting things right at the start isn't an appropriate goal for an Agile Architecture effort. In fact, the goal might be just the reverse — build capabilities that you know won’t be right and then make sure the architecture enables you to change them without breaking anything.
As a result, there’s no point to trying to get all the software right, and then locking everything down so that nothing can change. Instead, focus on failing your way to success. When things keep changing, there’s no way you can always be right. So fail often to succeed sooner. And to do that, you need to reduce the cost of failure.
But clearly, any technology you deploy has to work, otherwise it’s not meeting any business requirements. Building software that works is a fundamental Agile principle to be sure. How can you build for failure while building software that works?
Agile Architecture solves this contradiction. Instead of making failure expensive, focus on reducing its costs. To deal with continual change, Agile Architecture enables agility through the abstraction of IT capabilities so that your system allows for ambiguity. Design your system for flexibility by working at a level of abstraction that treats change as a constant.
Walk This Way - An Introduction to DevOpsNathen Harvey
"DevOps" is a term that has become mainstream enough to be hated, misunderstood, misused, and abused. But what is "DevOps"? And, more importantly, why should I care?
Being Elastic -- Evolving Programming for the CloudRandy Shoup
eBay Chief Engineer Randy Shoup's keynote at QCon 2010 outlines several critical elements of the evolving cloud programming model – what developers need to do to develop successful systems in the cloud. It discusses state management and statelessness, distribution- and network-awareness, workload partitioning, cost and resource metering, automation readiness, and deployment strategies
Models, Sketches and Everything In BetweenEoin Woods
ust the mention of the word “modeling” brings back horrible memories of analysis paralysis for many software developers. As a result of the conventional wisdom around Agile development that modeling is usually waste, countless software teams have completely abandoned modeling their systems. The problem is that there is a lot of design information that isn’t in the code, and without any models this information can get lost. Over time, the team ends up with a “big ball of mud.”
In this talk we explain what modeling brings to the development process and its value in different situations, discussing the different levels of formality available, from models to sketches and everything in between. Along the way, we share real-world advice on how a little well-chosen modeling can help avoid chaos.
DevOps does not exist in a vacuum; it rests on a social structure and culture that are intertwined. Hierarchies within organizations, industry connections, and globalization all influence culture. At the same time, culture influences social structure and impacts its effectiveness. To complicate matters even more, the tools we use have an overarching influence. Tools can affect our behavior, how we share knowledge, and our organizational hierarchies.
Often, a particular technology is presented as a “best practice” or as the right way to solve a problem. How do we resolve the cognitive dissonance that arises when the “correct” tool is no longer suited to our current environment? As technology increasingly shapes how we work, how do we determine what technologies to adopt to help effect the changes we want?
In this webinar, Chef Software Engineer Jennifer Davis will help you to frame the choices available to you, identify the weaknesses in your environment that your current tools disguise, and be more effective and deliberate with the tools used in your organization.
See the recorded webinar here: https://www.chef.io/blog/event/webinar-effective-tools-for-effective-change/
No Silver Bullet - Essence and Accidents of Software EngineeringAditi Abhang
”There is no single development, in either technology or in management technique, that by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity.”
DSC UTeM DevOps Session#1: Intro to DevOps Presentation SlidesDSC UTeM
DevOps has been such a buzzword in the IT field nowadays. If you look into job postings, you might be surprised to find terms like "work with DevOps team", "work in an agile team" etc.
What is DevOps? What is agile? And why all these? 樂
Join us on 24 May 2021, where we have a short session to explore on the events that led to the trend nowadays
We will be exploring on the current trends, tech stacks and the existence of DevOps itself! 朗
Mark this date on your calendar and we'll see you there!
* Note: This is an introductory "brief overview" session that gives you context on our upcoming events.
Slides by KwongTN.
Thierry de Pauw - Feature Branching considered Evil - Codemotion Milan 2018Codemotion
With DVCSs branch creation became very easy, but it comes at a certain cost. Long living branches break the flow of the software delivery process, impacting stability and throughput. The session explores why teams are using feature branches, what problems are introduced by using them and what techniques exist to avoid them altogether. It explores exactly what's evil about feature branches, which is not necessarily the problems they introduce - but rather, the real reasons why teams are using them. After the session, you'll understand a different branching strategy and how it relates to CI/CD.
The Paradox of Agile Architecture Quality: Designing for FailureJason Bloomberg
Change is fundamental to Agile Architecture. If it’s not the business and their requirements, processes, policies, or metadata that change, it’s the underlying technologies, implementations, and schemas that do. The enterprise is constantly shifting.
The more that we can enable change without having a high penalty cost for that change, the more we enable business agility. Getting things right at the start isn't an appropriate goal for an Agile Architecture effort. In fact, the goal might be just the reverse — build capabilities that you know won’t be right and then make sure the architecture enables you to change them without breaking anything.
As a result, there’s no point to trying to get all the software right, and then locking everything down so that nothing can change. Instead, focus on failing your way to success. When things keep changing, there’s no way you can always be right. So fail often to succeed sooner. And to do that, you need to reduce the cost of failure.
But clearly, any technology you deploy has to work, otherwise it’s not meeting any business requirements. Building software that works is a fundamental Agile principle to be sure. How can you build for failure while building software that works?
Agile Architecture solves this contradiction. Instead of making failure expensive, focus on reducing its costs. To deal with continual change, Agile Architecture enables agility through the abstraction of IT capabilities so that your system allows for ambiguity. Design your system for flexibility by working at a level of abstraction that treats change as a constant.
Walk This Way - An Introduction to DevOpsNathen Harvey
"DevOps" is a term that has become mainstream enough to be hated, misunderstood, misused, and abused. But what is "DevOps"? And, more importantly, why should I care?
A Digital Enterprise is one that leverages customer, contextual and enterprise data and use new-age technologies to drive exponential business impact. To facilitate digital transformation, enterprises are increasingly setting up Digital Labs/Hubs in geographies with rich product capabilities, such as the Bay Area (US) and Bangalore (India).
Stealing the Best Ideas from DevOps: A Guide for Sysadmins without DevelopersTom Limoncelli
DevOps is not a set of tools, nor is it just automating deployments. It is a set of principles that benefit anyone trying to improve a complex process. This talk will present the DevOps principles in terms that apply to all system administrators, and use case studies to explore their use in non-developer environments.
Thomas Limoncelli, StackOverflow.com, and Christina Hogan, AT&T
Presented at: Usenix LISA 2016
https://www.usenix.org/conference/lisa16/conference-program
DevOps provides competitive advantage to businesses through faster time to market by breaking down silos between business, development, testing and operations. They combine the Development and Operations teams leveraging automation of processes to enable rapid release cycles.
Some tools such as Chef and Jenkins are used by engineers in ops to great effect. Rarely though, a technology brings a paradigm to the masses.
Docker, like cloud virtualization is of this more rare breed.
DevOps and Continuous Delivery Reference Architectures - Volume 2Sonatype
CONTINUOUS DELIVERY REFERENCE ARCHITECTURES Including Sonatype Nexus and other popular DevOps tools Derek E. Weeks (@weekstweets) VP and DevOps Advocate Sonatype.
Continuous Delivery and DevOps Reference Architectures include many common tool choices. The most common tool choices we find in these reference architectures are: Eclipse, git, Cloudbees Jenkins / Atlassian Bamboo, Sonatype Nexus, Atlassian JIRA, SonarQube, Puppet, Chef, Rundeck, Maven / Ant / Gradle, Subversion (svn), Junit, LiveRebel, ServiceNow
DevOps: A Culture Transformation, More than TechnologyCA Technologies
DevOps is not a new technology or a product. It's an approach or culture of SW development that seeks stability and performance at the same time that it speeds software deliveries to the business. We will discuss this cultural shift where development teams have to accept the feedback of operations teams and the operations team should be ready to accept frequent updates to the SW that it's running.
To learn more about DevOps solutions from CA Technologies, please visit: http://bit.ly/1wbjjqX
C’est quoi DevOps ?
DevOps (Abrégé pour le développement et les opérations). comme toutes autre approche, il n’est qu’un buzzword pour la plupart des gens ...
As tech professionals, what we need is a way to work better so that we can create more, right? Through exploring various concepts and approaches, including the neuroscience of creativity, productivity techniques, and emerging practices that spur innovation, we'll discover not only the ways in which our brains work best, but also what’s behind the times when we feel on fire with creativity and when we don't. We’ll translate this information into processes and techniques for dramatically enhanced creative productivity. Beware: this session challenges the standard norms around concentration, focus, productivity, and may change how you work…for the better.
5 Ways ITSM can Support DevOps, an ITSM Academy WebinarITSM Academy, Inc.
Presenter: Jayne Groll, President, ITSM Academy
There is much debate about the relevancy of ITIL and ITSM in a new DevOps world. The truth is that DevOps does not negate the need for service management, it validates it – with some adaptation to be faster and more agile. This presentation will demonstrate five ways that ITSM processes can be adapted to and support emerging DevOps practices.
Motivated by the ideas presented? Print a Personal Action Plan to capture them.... https://www.itsmacademy.com/content/PAP-FOLD.pdf
sitHH16 - The Implications of Becoming AgileMarkus Theilen
Slides from my talk about the not so obvious changes that occur when change from waterfall to agile software development with Scrum. A review on the past three years in an agile transition.
The biggest DevOps problems you didn't know you had and what to do about themWayne Greene
Slide deck from www.ReleaseIQ.io webinar on August 25, 2021. Learn about the biggest problems DevOps teams face. You might be surprised what keeps DevOps teams stuck in mid-evolution.
Personal customer experiences are and will be more and more vital. People to people, but also people to machine. Today, there are several providers of the same services, and the new ones are faster, more flexible, and more personalized in their communications with their customers & users. How do we ensure that we provide the right information to our employees as well as to our customers so they can better serve and increase customer satisfaction?
This webinar will focus on how you as an organization will have to restructure, rethink and redesign your technological platform to support increasing employee- and customer demands.
Key takeaways:
Holistic understanding of how to make a successful cloud transition
Learn why modern organizations excel in customer treatment, productivity, flexibility, and agility
High-level architecture and how and why DevOps changes organizations
DevOps Beyond the Buzzwords: Culture, Tools, & Straight TalkMark Heckler
Discussion of DevOps concepts, enabling tools & platforms, and some candid observations. Small plug at end for Cloud Foundry. Slides only, sparkling commentary & conversation with attendees only available in person. :)
DevOps es un conjunto de prácticas que automatizan los procesos entre el desarrollo de software y los equipos de infraestructura, de manera que el software pueda ser construido, probado y puesto en producción más rápidamente y con la misma confiabilidad.
El concepto de DevOps esta fundamentado en la construcción de una cultura de colaboración entre equipos que históricamente son silos. Los beneficios aparentes incluyen confianza mutua, más rápidos ciclos de puesta en producción, habilidad para resolución de incidentes más rápidamente y mejor adaptación a los cambios.
En esta sesión revisamos conceptos clave de DevOps, el estado del arte y algunas de las tecnologías involucradas.
Enterprise DevOps: Crossing the Great Divide with DevOps TrainingITpreneurs
This session (and slide deck) was specifically created for training and consulting companies interested in offering DevOps training courses. Jayne Groll, co-founder of ITSM Academy and an expert on ITSM, Agile, Scrum DevOps, leading the session.
This deck covers:
1. A brief overview of DevOps – its history, concepts and relationship to other frameworks such as Agile and ITSM
2. The increasing interest in DevOps at the enterprise level
3. The value of adding DevOps training to your portfolio
-Small / Medium Size Training Companies
-Large Training Companies
-Consulting Companies
4. Scenario’s for Successfully Going to Market with DevOps
5. How You Can Get Started
Agility via Software Engineering Practices - Agile Tour Montreal 2015Steve Mercier
A presentation given to Agile Tour Montreal 2015 about how you can attain better Agility by applying software development practices helping to correct typical issues with Agile methodologies.
How AI is transforming DevOps | Calidad InfotechCalidad Infotech
DevOps is a remarkable asset to start-ups. The growing technology over the last two decades has made it easier to build & scale all sizes of businesses & organizations. In this fast-paced growing technology world, DevOps has paved its way with its innovative & effective tools & practices that have turned out to be a… Continue reading.. https://calidadinfotech.com/devops-services
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/
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
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
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
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.
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.
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
2. What is DevOps? (according to Wikipedia)
• software DEVelopment and information technology OPerationS
• “A set practices that emphasize the collaboration and communication
of both software developers and information technology professionals
while automating the process of software delivery and infrastructure
changes”
• “Establishing a culture and environment where building, testing, and
releasing software can happen rapidly, frequently, and more reliably”
• Generally agreed to have started around 2008-2009 (devopsdays.org)
3. What is DevOps? (my personal definition)
• The art and science of identifying and automating the routine parts of managing
information, software, and technology for rapid, reliable deployment
• A framework/toolset that helps technologists focus on the interesting parts of our
work and lets non-technologists focus on their core jobs
• By this metric, DevOps in some form has been around as long as there has been
systems administration
• “Fighting fires” is not interesting in a good way
• Unplanned incidents consume resources uncontrollably (wildfire)
• Planned, proactive fire management is better
• Forestry to manage the forest, plus understanding how fires could start and
when controlled burns are needed, is best
4. What motivated me to think about DevOps?
• The Phoenix Project: a novel about IT, DevOps, and helping your business
win by Gene Kim, Kevin Behr, George Spafford
(http://itrevolution.com/books/phoenix-project-devops-book/ )
• Our protagonist inherits an IT infrastructure which is badly broken
• Catastrophe -> heroic recovery -> maybe learning (repeat)
• Incremental improvements to understanding, infrastructure
• Ticketing system to make work visible (with actual tickets: KanBan!)
• Identify and ameliorate bottlenecks (Brent)
• Prioritize IT work by understanding business needs, IT infrastructure
• Develop knowledge of and skill in workplace politics
5. Real life DevOps example: npm
• https://speakerdeck.com/ceejbot/devops-at-npm-scaling-the-registry
• CJ Silverio, CTO at npm, describes how they scaled up infrastructure
to create a usable global Node.js registry
• Moved from best guess predictive scaling to reactive monitoring
and scaling to proactive improvements based on reliable metrics
• Infrastructure was exciting for several months while trying to meet
increasing demand
• Sometimes learned what needs to be monitored by having it break
• “The goal is to be boring”
6. Real life DevOps example: Etsy
• https://codeascraft.com/2012/05/22/blameless-postmortems/
• John Allspaw, CTO at Etsy, writes about their culture where failure
is expected and used to learn how to make improvements
• Human error is inevitable
• Equip ourselves to better deal with problems that may arise
• Give people the authority to make things better
• Just Culture requires understanding personal reactions to failure
7. Does Arts need DevOps?
(audience participation time)
• Why are we here?
• Do we develop technology solutions to help Arts work effectively?
• Are we solely/primarily a support organization?
• Should we be?
• Should central IT be where DevOps happens?
• How effectively do we work across units?
8. What DevOps Isn’t (busting a few myths, 1/n)
• A replacement for Agile
• The Agile Manifesto http://agilemanifesto.org/principles.html (created in
2001) is about building and maintaining software responsively
• In a sense, DevOps is an extension of work flow practices used in
Agile/Extreme/Lean/Scrum methods to technology management
• Agile is not a prerequisite for DevOps
• Flexible IT service delivery can support Agile software development
• Our job isn’t over when code is fully tested and in production
• Do we use Agile/Lean software development or project
management?
9. What DevOps Isn’t (2/n)
• A replacement for ITIL
• ITIL is a set of best practices
• ITIL and ITSM describe capabilities needed to support DevOps
• Service design is relevant
• Problem management is relevant to DevOps, too
• Many processes codified in ITIL can be automated
• This includes change, configuration, release processes
• As with Agile, DevOps can enable ITIL implementation
• Do we use ITIL? Has this changed in the past year?
10. What DevOps Isn’t (3/n)
• NoOps (entirely eliminating IT Operations)
• Many IT operations tasks become self service under DevOps
• Pushes some operations functionality to groups that don’t
have an operations focus, e.g. development
• Operations still has responsibility to maintain and develop
the environment that makes everyone’s job less frustrating
• Are there areas of our work where we use NoOps? Do we
consume any NoOps services? Would we like to?
11. What DevOps Isn’t (4/n)
• Linked primarily to Open Source
• Principles are universal
• You don’t need a LAMP stack: independent of underlying technology
• Some DevOps requirements are common in Open Source environments
• automated testing
• configuration management
• version control
• How much of our work relies on vendor solutions? Open
source? Home grown software?
12. What DevOps Isn’t (5/n)
• Infrastructure as code (nothing but automation)
• Many patterns require automation
• We also need mutual trust, shared goals
• Understanding how technology enables the business and how
people (technologists and non-techs) get things done
• The business of higher education has a lot of moving parts
• How much of our work involves knowing academic,
administrative work flows?
13. What DevOps Isn’t (6/6)
• For tech startups and behemoths/unicorns
• Google, Amazon, Twitter, LinkedIn, Esty, Facebook started with
traditional IT Operations practices
• DevOps practices are widespread across industries
• Financial services (Bank of America, Paychex, World Bank)
• Retailers (REI, Macy’s, GameStop)
• Higher education (UBC, Kansas State)
• US and UK government agencies
• Does DevOps make sense for Arts Computing? For UW?
14. What DevOps is: core concepts
The three ways
The four types of work
Monitoring and visibility
15. The three ways of DevOps
(looks a lot like Toyota Production System)
Left to right flow of work
Right to left flow of information
Creating a culture where errors and feedback are normal
16. Left to right flow of work
• Work in progress always moves forward
• Development -> IT Operations -> end user
• Small batch sizes and intervals
• Do not pass defects downstream
• Constantly optimize for global goals
• Continuous build, integration, deployment
• Create environments on demand
• Limit work in process
• Build safe systems
• Build infrastructure that is resilient to change in requirements, environment, demand
17. Right to left flow of information
• Constant, fast feedback at all stages
• Amplify information
• Identify exceptions
• Speed up exception detection and recovery
• Prevent problems from recurring
• Stop everything when something goes wrong
• Improvement of work takes precedence over the work itself
• Fast, automated testing
• Shared goals among business, development, operations
• Pervasive, visible production telemetry
18. Creating a resilient culture
• Foster continual experimentation
• Reward taking risks
• Learn from both failure and success
• Improve relentlessly
• Innovation demands a high level of trust
• Understand: repetition and practice are needed for mastery
• Develop reliable skills and habits
• How can we help each other be comfortable taking risks?
19. The four types of work that IT does
• Business projects (why we get paid)
• The work of the organization, often software development/projects
• This includes some client support of various kinds as well
• IT projects (how we make it easier to do what we get paid for)
• Infrastructure creation/maintenance
• Internally generated improvement work
• Changes (planned updates because we don’t exist in a bubble)
• Feature development, service delivery, patches
• Unplanned work (forest fires)
• Incidents, problems
20. Why track (and visualize) these types of work?
• Evaluate our performance
• Identify bottlenecks
• Identify priorities
• Plan use of resources
• Avoid resource starvation
• People are resources too
• http://images.itrevolution.com/images/kanbans/waittime_vs_percentbusy.jpg
21. How are we doing?
• Following the three ways (workflow, flow of feedback, flow of trust)
• How much of each of four types of work we do (Arts, IT, change, fires)
• Can we measure this more effectively?
• Identifying and fixing bottlenecks
• Automating what we can
• Figuring out what can be automated
• Understanding the business that makes our work necessary
• Tell me about the Faculty of Arts; how does it work?
22. Where do we go from here? (homework)
• Automate something you do by hand
• Help a client automate something
• Look at what you see in monitoring results
• Fix it so it’s actionable or response is automated
• Find out what your supported departments and programs are
doing/planning and how we can help them
• Prepare to take a two week vacation without checking email
• Check in with team on your progress in 2-6 months (set deadline)
