Devops for Developers

•

4 recomendaciones•7,354 vistas

Many developers think DevOps is nice and valuable but consider it a SEP (Somebody Else's Problem) - not because they do not care but simply because they do not know enough about Ops to relate it to their daily work. This presentation tries to fill the gap a bit, clarifies some common misunderstandings and explains the typical needs of an Ops admin. Then a set of design principles is shown that address the needs of an admin and help to build applications ready for Ops - because in the end it's all about production! As always lots of the information of this presentation is on the voice track but yet I think that you can find some helpful pointers in this deck.

Tecnología Empresariales

Devops for Developers
How Dev can write applications ready for Ops

Uwe Friedrichsen, codecentric AG, 2013-2014

@ufried
Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

DevOps
DevQA
DevPO
DevRE
DevPM
DevDev
DevDevPO
DevDevDev

Top 5 Needs of an Admin

1.  Give me my peace and quiet!
2.  Don‘t make me think!
3.  Let me see that everything is fine!
4.  Show me the problem – now!
5.  Tell me what to do!

Top 5 Needs of an Admin (translated)

1.  Give me my peace and quiet! 
(The application should just run smoothly)
2.  Don‘t make me think! 
(Rollout, setup and operation of the application should be easy)
3.  Let me see that everything is fine! 
(The application should show its state)
4.  Show me the problem – now! 
(The application should provide concise error messages and enable easy root cause drilldown)
5.  Tell me what to do! 
(The application should be documented properly – including error handling instructions)

Top 3 Dev Challenges

1.  Manageability
2.  Resilience
3.  Transparency
4.  Documentation

11 Design Principles

for DevOps-ready Applications

•  Manageability (4)
•  Resilience (5)
•  Transparency (2)

•  One-click deployment
•  Preserve settings
•  Provide rollbacks (or roll-forward)

•  Avoid multiple configuration procedures
•  Define default value handling
•  Organize change traceability
•  Notification about new parameters

Configuration Parameter Types

(Manageability)

•  Context-related parameters 
Do not stage – managed by stage admin
•  Application-related parameters 
Must be staged – managed by application admin
•  Business-related parameters 
Must be staged – managed by business admin

•  Think about backup purpose
•  Define backup strategy
•  Provide tooling

•  Divide system in failure units
•  Isolate failure units
•  Define fallback strategy

•  Elaborate use case 
Minimize MTTR / scale transactions / handle response errors / …
•  Define routing & balancing strategy 
Round robin / master-slave / fan-out & quickest one wins / …
•  Consider admin involvement 
Automatic vs. manual / notification – monitoring / …

•  Isolate failure units (complements bulkheads)
•  Go asynchronous wherever possible
•  Use timeouts & circuit breakers
•  Make actions idempotent

•  What will you do if a request fails?
•  Consider failure handling from the very beginning
•  Supplement with general failure handling strategies

•  Define scaling strategy
•  Think full stack
•  Apply D-I-D rule
•  Design for elasticity

•  Think about required metrics
•  Design hook or event mechanism
•  Plan for changing metrics
•  Consider event sourcing

•  Consider log message structure 
All required information / machine readable / human readable
•  Define logging policy 
Debug and less: developers perspective / Info and more: operations perspective

11 Design Principles

•  Manageability
•  Deployment
•  Configuration
•  Configuration Parameter Types
•  Backup

•  Resilience
•  Bulkheads
•  Redundancy
•  Loose Coupling
•  Fallbacks
•  Scalability

•  Transparency
•  Monitoring
•  Logging

Wrap-up

•  Dev often does not know Ops
•  Know the needs of an admin
•  Face the challenges for a developer
•  Apply the design principles

… and then you‘re ready for DevOps

Más contenido relacionado

La actualidad más candente

Vertafore develops and delivers cloud-based insurance software and services for the insurance industry. In this session, we'll chronicle one development team's journey through the database technology landscape that led to the evaluation and selection of Apache Cassandra as part of DataStax Enterprise from a small pool of contenders. We'll describe the process from setup to selection, including evaluation guidelines, testing strategies, tools, as well as our mindset. We'll also describe the project's initial goals, some milestones, and our communication strategy to inform those with budgetary powers.

Vertafore: Database Evaluation - Selecting Apache Cassandra

DataStax Academy

Chaos Engineering - The Art of Breaking Things in Production

Keet Sugathadasa

Chaos Engineering, When should you release the monkeys?

Thoughtworks

Runaway jobs and processes—including database server jobs—are infamous for consuming resources and degrading system performance right under your nose. So, how do you stay one step ahead of these greedy system performance gobblers? In this PowerPoint, our experts examine several system issues that can cause unplanned delays to a busy IBM i environment and explain how and why these issues take hold. You’ll learn how to: •Define and recognize runaway scenarios and typically problematic jobs like QZDASOINIT •Qualify the impact of runaway jobs and processes on CPU, memory, and storage (temporary and permanent) •Take a proactive approach to automatically identifying and addressing runaways before they escalate Pen up runaway processes before they cause problems!

Stop Feeding IBM i Performance Hogs - Robot

HelpSystems

Resiliency through Failure @ OSCON 2013

Ariel Tseitlin

Lightning talk: highly scalable databases and the PACELC theorem

Vishal Bardoloi

Presented by Damon Edwards, co-founder of Rundeck, at QCon San Francisco 2019. See a Demo of Rundeck Enterprise : https://www.rundeck.com/see-demo --or-- Download Rundeck Open Source here: https://rundeck.com/open-source Connect: Stack Overflow community: https://stackoverflow.com/questions/tagged/rundeck Github: https://github.com/rundeck/rundeck/issues Twitter: https://twitter.com/Rundeck Facebook: https://www.facebook.com/RundeckInc/ LinkedIn: www.linkedin.com › company › rundeck-inc

Incident Management in the Age of DevOps and SRE

Rundeck

In this presentation, CloudSmartz presented the Buffalo, NY Region of CIO and IT Executives recent trends on disaster recovery and business resilience. This was great opportunity to learn and discuss new technologies on how you can maintain control of your data and have the flexibility you want over your environment: • Defining critical applications for Disaster Recovery & Business Continuity • Disaster Recovery approaches within the secure cloud environment • Security, Control and Flexibility at your fingertips • Reduce disaster recovery costs and gain continuous storage access Business resilience is the ability an organization has to quickly adapt to disruptions while maintaining continuous business operations and safeguarding people, assets and overall brand equity.

Disaster Recovery & Business Resilience Trends - CloudSmartz | Smarter Transf...

CloudSmartz

La actualidad más candente (8)

Vertafore: Database Evaluation - Selecting Apache Cassandra

Chaos Engineering - The Art of Breaking Things in Production

Chaos Engineering, When should you release the monkeys?

Stop Feeding IBM i Performance Hogs - Robot

Resiliency through Failure @ OSCON 2013

Lightning talk: highly scalable databases and the PACELC theorem

Incident Management in the Age of DevOps and SRE

Disaster Recovery & Business Resilience Trends - CloudSmartz | Smarter Transf...

Destacado

Resilience becomes a must. Actually resilience is an issue for a long time, but with ever-increasing distribution it becomes a must. But how can we implement resilience into our applications? Hystrix, an open-source library developed by Netflix provides a nice starting point. It provides downstream isolation by implementing patterns like timeout, circuit breaker and load shedder. This presentation gives an introduction into Hystrix, providing lots of code examples.

Resilience with Hystrix

Uwe Friedrichsen

This is a slidedeck about a topic I already talk about for a while: Every company is affected by the economic darwinism, i.e. the companies that respond best to change will survive. And the IT is not a bland cost center, it is the neural system of every company. No IT, no business! Combining those two observations it becomes obvious that the responsiveness of the IT about new business features is a crucial survival factor in the long run - we are no longer talking about months or years for new business features, but about weeks or days. In this slide deck I explain why the approaches most IT departments are not helping (sometimes even being counter-productive) and which building blocks you have to implement in order to survive the economic darwinism. Some of the slides badly miss the audio track but the core ideas should become clear.

Dr. Hectic and Mr. Hype - surviving the economic darwinism

Uwe Friedrichsen

This talk I gave at the NoSQL matters 2013. It quickly introduces BASE transactions and then illustrates the challenges a developer encounters when switching from ACID to BASE using a (very) simple example application. First the ACID variant is shown. Then a naive BASE transformation is done. After that the typical problems with that approach are shown one by one a how to handle them on a conceptual and code level. Of course the voice track is missing again but lots of stuff should become clear from the slides, though.

How to survive in a BASE world

Uwe Friedrichsen

Fault tolerance in general is a challenging topic. Yet we need fault toleranct designs more badly than ever in order to provide robust, highly available systems - especially in times of scale out systems becoming more and more popular. Unfortunately, most developers do not care too much about a fault tolerant design, either because they are scared by the complexity of the realm or because they do not care enough. One of the problems is that a lack of fault tolerant design does not hurt a lot in development or in QA, but it hurts a lot in production - as Michael Nygard said: "It's all about production!" (at least figuratively). In this presentation I do *not* try to give a general introduction to fault tolerant design. Instead I pick a few generic case studies that demonstrate the results of missing fault tolerant design, try to sensitize a bit about the production relevance of fault tolerant design and then go along with a few selected patterns. I picked a few patterns which are surprisingly easy to implement and help to mitigate the problems of the former case studies. This way I try to show two things: 1. A piece of architecture or design as a pattern is not necessarily hard to implement. Sometimes the code is written quicker than it takes to explain the pattern beforehand. 2. Even if fault tolerant design as a general topic might be hard, some parts of it can be implemented very easily and it's more than worth the coding effort if you look how much better your system behaves in production just from adding those few lines of code.

Fault tolerance made easy

Uwe Friedrichsen

This slide deck is basically an extended and updated version of the "Microservices - stress-free and without increased heart-attack risk" slide deck - yet quite a lot of extensions and updates. The deck is organized in three parts: Why, What and How. The first part addresses the question if and when you should use microservices at all. It tries to create a bigger picture by explaining changing (business) markets and a changing role of IT and fits microservices into that picture. When looking at this picture it also becomes clear that microservices always should accompanied by other measures like DevOps, Cloud and some more if you really want to leverage its benefits. Otherwise you usually only get the downsides of microservices with harvesting their benefits. The second part revisits the famous blog post from James Lewis and Martin Fowler, using it to explain what characteristics the microservice architecural style has. It turns out that this post contains quite a lot of information and that quite often only a subset of the characteristics get implemented. The third part, the "How" dives deeper into the challenges and pitfalls that you usually encounter if you decide to adopt microservices. While of course not being complete and not being a perfect guide that makes everything easy, it should at least help you tho avoid the most common problems and pitfalls. As always the voice track is missing which contains most of the information (it is a 90 min talk after all), but hopefully also the slides alone contain some helpful information.

The promises and perils of microservices

Uwe Friedrichsen

This presentation explains that the naive cloud business case that is often presented does not work: simply deploy your existing enterprise applications to a cloud environment and save lots of money by automatically adopting resource usage (and payment) to the actual application load. The problem is that enterprise applications are not elastic by default, i.e. they cannot easily scale out and in, because it takes explicit design and implementation to create an elastic application. A set of design principles is presented in this deck that are required to create an elastic application. As always lots of the information of this presentation is on the voice track but yet I think that you can find some helpful pointers in this deck.

Fantastic Elastic

Uwe Friedrichsen

This session provides a primer to resilience at varying flight altitudes. It starts at a management level and motivates why resilience is important, why it is important today and what the business case for resilience is (or actually is not). Then it descends to a high level architectural view and explains resilience a bit more in detail, its correlation to availability and the difference between resilience and robustness. Afterwards it descends to a design level and explains some selected core principles of resilience, some of them garnished with grass-root level flight altitude code examples. At the end the flight altitude is risen again and some recommendations how to introduce resilient software design into your software development process are given and the correlation to some related topics is explained. Of course this slide deck will only show a fraction of the actual talk contents as the voice track is missing but I hope it will be helpful anyway.

Why resilience - A primer at varying flight altitudes

Uwe Friedrichsen

The talk belonging to this slide deck is basically a "sequel" of the "Patterns of resilience" talk. It briefly repeats a few core statements of the previous talk and then starts to complete the picture. First, it creates a more complete pattern taxonomy and locates the taxonomy of the previous talk in it. Then, it repeats a few of the patterns of the first talk concerning core architectural patterns and error detection patterns, enriching them with some additional information. After that the core part of this talk starts: The error recovery and error mitigation patterns. The talk presents several well known and not so well known patterns from those two domains, partially augmented with code examples. Then after, briefly touching fault treatment patterns, some more patterns of the error prevention domain are presented. The talk concludes with a small guideline, how to identify the appropriate pattern set for a concrete situation. As always, the voice track and therefore a lot of information is missing in this slide deck. Yet, I hope that it provides a few helpful pointers.

Resilience reloaded - more resilience patterns

Uwe Friedrichsen

As the subtitle says, this talk tries to embed DevOps in a broader context. Therefore first briefly is sketched, how the state of IT is perceived by many people in IT. Additionally, DevOps is briefly defined by explaining the three ways as they were described in the book "The Phoenix Project". After this short introduction the claim of the title is picked up: "Why is DevOps not enough?". In order to explain this claim, the history of economic markets and of IT are briefly explained. The bottomline is that almost all markets supported by IT have drastically changed in the years since IT became relevant for companies. Additionally, IT itself has changed dramatically in this period of time. Therefore, most of the common knowledge and best practices, we stick to in IT became counter-productive meanwhile because they solve a completely different problem, i.e., the problems of the times when the markets and IT itself were totally different. The conclusion from the short examination of history is that we basically have to re-think IT as a whole, which is discussed briefly in the next section of the talk. This section first has a look at the new drivers that inflict change on IT. Then it derives the new goals of IT and shows some of the building blocks. Having this new idea of IT at hand, the role of DevOps in it is finally considered. Starting with DevOps and its continuous pursuit of shortening cycle times in order to optimize outcome, DevOps can be used to drive the change of IT. This is exemplarily shown by starting with DevOps and then see, which question arise from that and what solutions it leads to. In the end of the example, many of the building blocks of the new IT are in place - just by starting with DevOps and continuously improving. This is a very dense talk covering a lot of ground in order to lead to the final observation that DevOps can (and should) be used to drive the required change of IT and many detail have been left out. Also the voice track is missing of course, but I still hope that it provides you with some useful information.

DevOps is not enough - Embedding DevOps in a broader context

Uwe Friedrichsen

This is a slide deck belonging to a talk in which I talk about the challenges with µservices in general and provide a few ideas how to avoid the worst pitfalls. The talk starts with a short explanation why µservice are always hard (yes, the title of the presentation is sort of an oxymoron) and when and when not to choose µservices. After that introduction I provide a few ideas which from my experience help to get around the worst problems and pitfalls with µservices. As the ideas are from very different topic areas I organized them according to the software production chain starting with design hints and ending with resilience hints (a pure production related topic). As always the voice track is missing but I hope that also the slides in themselves will give you a few helpful hints.

Microservices - stress-free and without increased heart attack risk

Uwe Friedrichsen

In this presentation I focus on the architectural aspect of the next generation of enterprise IT topic I already covered in some other presentations. The slide deck starts with a quick motivation. It describes the external drivers that require traditional enterprise IT to change. Based on these drivers, the drivers and requirements for an architecture that supports the external drivers are derived. The second major part of the slide deck then examines some of today's IT hype topics and evaluates them with respect to the architectural requirements derived before. Be aware that the evaluation partially is hard to understand without the voice track. Actually, at some places the explanations on the voice track are more important than the evaluations themselves. Thus, please do not take them too literally. The last major part then tries to sketch a possible architectural style that suits the given requirements. Again, the rationale for picking the respective elements are on the voice track, and it is just one possible style. There are for sure more styles available that suit the needs. Yet I think, the style described makes clear that the upcoming enterprise architectural styles are quite different from the styles that were predominant in the last 10 or 15 years and makes clear that we all have to face new challenges - not only on the architectural level. Sorry again that the voice track is missing. Yet I think, that the presentation provides some helpful ideas even without the voice.

Modern times - architectures for a Next Generation of IT

Uwe Friedrichsen

This is the successor of my Dr. Hectic and Mr. Hype presentation where I first explained the consequences of the economic darwinism for an enterprise IT and started to lay out a new, competitive IT that is ready to respond to the new change drivers. In this presentation I try to provide a more comprehensive picture than in the former presentation. I added additional change drivers that were missing in the first presentation and derived the goals, the principles and the building blocks for an appropriate next generation of an enterprise IT in a lot more detail than in the first presentation. Yet, the presentation is still very high level as it tries to lay out a complete vision for a future enterprise IT in 60 minutes, i.e., it would be possible to create one or more detailed presentation for mostly every single term and statement in this presentation. Thus, it might appear too high level for some persons. On the other hand I think it is important to create such a high level vision as it makes it a lot easier to classify all those trends that are pushing on us every single day. And as always the voice track is missing. Yet, I hope that the presentation provides some valuable insights.

The Next Generation (of) IT

Uwe Friedrichsen

This session is sort of a journey from the change drivers that affect today's IT to ways to respond to them in the architecture. It starts with the business and technological drivers that force IT into change. After briefly sketching the big picture for IT as a whole, it focuses on the drivers and requirements that can be derived for architecture from the IT change drivers. After carving out the architectural requirements, those are mapped to some trending topics. Based on the mapping results, it becomes obvious that there is no silver bullet (we all know that but this doesn't keep us from hoping that there still is one). It is required to combine some ideas and concepts to a joint architectural style that becomes more than just the sum of its parts - and that's the last part of the story: Describing an architectural style that helps addressing the IT change drivers shown in the first part. As a side note, at the end an idea is shown how EAM could fit into the picture laid out by the slides. As always, many details are only on the voice track - and as always, sorry about that! But I hope that the slides still contain some ideas which are valuable for you.

Conway's law revisited - Architectures for an effective IT

Uwe Friedrichsen

This slide deck dives a bit in history to understand where IT comes from, where we are now and why we are there and what our options are. It starts with exploring the paradigms of the markets companies live in, travels through matching organizational approaches and finally looks at the history and current state of IT. Based on that and after a quick look at Conway's law the market paradigms and organizational approaches are evaluated with respect to the drivers they imply on IT in general and architecture particularly. And after all that foreplay (which is necessary to really understand where we are and what the forces are) several architectural styles and technologies are located on the scale that the market paradigms and organizational approaches span. This way sort of an "architectural fitness detector" is provided which helps to make architectural choices based on needs instead of hypes or habits (which are way to often the choice drivers). The slide deck then finishes up with a few mismatches that are seen quite often in reality and it can be seen how the distance between architectural choices on the presented scale can be used to quickly determine potential mismatches. As always the voice track is missing but I hope that the slides are still of some help for you.

Towards complex adaptive architectures

Uwe Friedrichsen

In this talk, I address two topics. The first topic is the "one size fits all" dogma that we see quite often in IT. I try to explain, why we do it but also what the pitfalls are and how oversimplified solution spaces lead to the same kind of accidental complexity when trying to solve a given business problem as overly complex solution spaces. The second and core topic is the influence that a communication paradigm you use has on your functional design. Based on the observation that synchronous request/response in all its flavors is the usually used "one size fits all" communication paradigm, I use a real-life example to demonstrate how two different communication paradigms (synchronous request/response and asynchronous event-based communication) can lead to very different functional service designs - and that synchronous request/response not necessarily leads to the more appropriate functional design. The bottom line of the talk is that you should not give up your design options prematurely in order to be able to find the best problem-solution fit and that the choice of the communication paradigm is a more important options than most people usually think it is. As always the voice track is missing and therefore quite a bit of the information (or probably most of the information) contained in the talk. But hopefully the slides still give you some useful pointers.

Watch your communication

Uwe Friedrichsen

This is the slide deck of a keynote I gave at Java Forum Nord 2016. I started with some of the contradictory requirements, developers find themselves often confronted with and the question, if there is a bigger context that we can use to make sense of it. Then I did a bit of "time-traveling", explaining where we came from and how business and IT have evolved over time. The core finding was that we find ourselves in the middle of a revolution that is going on (not only) in IT. The last part were some recommendations how an IT developer can at least reduce the risk to become "revolution roadkill". As always most of the content was on the voice track. But maybe the slides are still a bit helpful on their own.

Life, IT and everything

Uwe Friedrichsen

Bring Down The Walls for Confusion - Agile and Beyond 2016

Dana Pylayeva

Development to Operations (DevOps) will have a profound impact on the global IT sector in the near future. Realizing DevOps’ full potential, IT vendors have been agile enough in providing new products and services under the label “DevOps inside”, at an ever- increasing pace. However, with the growth in product choices, conflicting definitions and competing services, customers often encounter confusion, while making complex purchase decisions. They often seem to be unsure about how to deploy DevOps and get the most out of the solution. While not trying to delve deep into DevOps, the Whitepaper tries to answer the following key questions: What is DevOps? What is DevOps trying to achieve? How will DevOps achieve this? How best to make use of the new developments? Its aim is to help the reader: Understand the DevOps concepts Understand its current value and restrictions

DevOps - The Future of Application Lifecycle Automation

Gunnar Menzel

Bring Down the Wall of Confusion with Chocolate, LEGO and Scrum Simulation Game

Dana Pylayeva

How we sleep well at night using Hystrix at Finn.no

Henning Spjelkavik

Destacado (20)

Resilience with Hystrix

Dr. Hectic and Mr. Hype - surviving the economic darwinism

How to survive in a BASE world

Fault tolerance made easy

The promises and perils of microservices

Fantastic Elastic

Why resilience - A primer at varying flight altitudes

Resilience reloaded - more resilience patterns

DevOps is not enough - Embedding DevOps in a broader context

Microservices - stress-free and without increased heart attack risk

Modern times - architectures for a Next Generation of IT

The Next Generation (of) IT

Conway's law revisited - Architectures for an effective IT

Towards complex adaptive architectures

Watch your communication

Life, IT and everything

Bring Down The Walls for Confusion - Agile and Beyond 2016

DevOps - The Future of Application Lifecycle Automation

Bring Down the Wall of Confusion with Chocolate, LEGO and Scrum Simulation Game

How we sleep well at night using Hystrix at Finn.no

Similar a Devops for Developers

DevOps for Developers - Friedrichsen

Codemotion

DevOps in 2014

David Thompson

Engineering operations

Subbu Allamaraju

Luiz Fernando Testa Contador - Aplicando DevOps em grandes corporações

Agile Trends

DevOps - Understanding Core Concepts (Old)

Nitin Bhide

Seminaire od devops 10traps 1.0

Alain Delafosse

When to Code / Config / Config + Code in Salesforce - Nikunj Doshi In this session discussed about, - Key Criteria in deciding right solution. - Pragmatic takeaways from Salesforce's decision guide https://link.medium.com/SNjI4Rs6Udb - Sample solutions displaying power of Configurable Code! - - Any Object to Big Objects archiving utility - - Metadata Driven declarative rollup - Q&A & Share our horror/memorable stories on this topic

When to Code / Config / Config + Code in Salesforce - Nikunj Doshi

Sakthivel Madesh

TrailblazerDX Motihari.pptx

Om Prakash

Twelve Factor - Designing for Change

Eric Wyles

Playbook for Remote Cutover S4H_747 How to Approach Remote Cutover.pptx

CharithWeerasekara2

Dev Ops for systems of record - Talk at Agile Australia 2015

Mirco Hering

Engineering Operations

Cybera Inc.

1221 raise expectations_for_the_ always_on_enterprise

Scott Simmons

Resisting to The Shocks

Stefano Fago

DevOps - Understanding Core Concepts

Nitin Bhide

Presentation by Damon Edwards, co-founder of Rundeck, at DevOps Enterprise Summit in San Francisco, November 13, 2017 See a Demo of Rundeck Enterprise : https://www.rundeck.com/see-demo --or-- Download Rundeck Open Source here: https://rundeck.com/open-source Connect: Stack Overflow community: https://stackoverflow.com/questions/tagged/rundeck Github: https://github.com/rundeck/rundeck/issues Twitter: https://twitter.com/Rundeck Facebook: https://www.facebook.com/RundeckInc/ LinkedIn: www.linkedin.com › company › rundeck-inc

Keeping Your DevOps Transformation From Crushing Your Ops Capacity

Rundeck

Slides from LAX & DEN usergroup meetings

10n Software, LLC

DevOps day 10 traps to avoid

Eric Mattern

Dawn of the DevOps - TJ Randall - EMC World 2015

XebiaLabs

Introducing the Development Director

The Marketing Practice

Similar a Devops for Developers (20)

DevOps for Developers - Friedrichsen

DevOps in 2014

Engineering operations

Luiz Fernando Testa Contador - Aplicando DevOps em grandes corporações

DevOps - Understanding Core Concepts (Old)

Seminaire od devops 10traps 1.0

When to Code / Config / Config + Code in Salesforce - Nikunj Doshi

TrailblazerDX Motihari.pptx

Twelve Factor - Designing for Change

Playbook for Remote Cutover S4H_747 How to Approach Remote Cutover.pptx

Dev Ops for systems of record - Talk at Agile Australia 2015

Engineering Operations

1221 raise expectations_for_the_ always_on_enterprise

Resisting to The Shocks

DevOps - Understanding Core Concepts

Keeping Your DevOps Transformation From Crushing Your Ops Capacity

Slides from LAX & DEN usergroup meetings

DevOps day 10 traps to avoid

Dawn of the DevOps - TJ Randall - EMC World 2015

Introducing the Development Director

Más de Uwe Friedrichsen

This slide deck basically tries to address functional service design not only from a maintainability point of view, but also form an operational point of view. How to spread your business functionality across your service landscape to maximize availability and responsiveness? It starts with the observation that virtually all system landscapes these days, including cloud-native, are distributed systems. Due to the failure modes of distributed systems every remote communication basically is a predetermined breaking point of your system. After briefly discussing other options to increase availability and responsiveness the biggest part of the deck discusses the question how a good functional design can positively influence the aforementioned system properties. Using a very simple eCommerce application as an example, first a typical design is shown and why it is suboptimal in terms of availability and responsiveness. After that, we briefly dive into classical CS papers and see what we can learn from them. We also learn that while the core insights of those papers are mostly timeless, their implementation instructions are not and that we need to update them to our current context. Then we use the learnt ideas to derive a different functional decomposition approach starting with the system behavior and apply it to our example - which leads to a lot better system behavior in terms of availability and responsiveness. Finally we discuss the most important trade-offs of the different design approach - as every design decision of course also has its downsides ... ;) As always, the voice track is missing (but afaik there will be a recording released from KanDDDinsky 2018). Still, I hope the slides on their own also offer you a few valuable ideas.

Timeless design in a cloud-native world

Uwe Friedrichsen

This is a slide deck from a presentation, that my colleague Shirin Glander (https://www.slideshare.net/ShirinGlander/) and I did together. As we created our respective parts of the presentation on our own, it is quite easy to figure out who did which part of the presentation as the two slide decks look quite different ... :) For the sake of simplicity and completeness, I just copied the two slide decks together. As I did the "surrounding" part, I added Shirin's part at the place when she took over and then added my concluding slides at the end. Well, I'm sure, you will figure it out easily ... ;) The presentation was intended to be an introduction to deep learning (DL) for people who are new to the topic. It starts with some DL success stories as motivation. Then a quick classification and a bit of history follows before the "how" part starts. The first part of the "how" is some theory of DL, to demystify the topic and explain and connect some of the most important terms on the one hand, but also to give an idea of the broadness of the topic on the other hand. After that the second part dives deeper into the question how to actually implement DL networks. This part starts with coding it all on your own and then moves on to less coding step by step, depending on where you want to start. The presentation ends with some pitfalls and challenges that you should have in mind if you want to dive deeper into DL - plus the invitation to become part of it. As always the voice track of the presentation is missing. I hope that the slides are of some use for you, though.

Deep learning - a primer

Uwe Friedrichsen

This slide deck is basically my take on the future development of microservices. It is not so much a technological prediction as a tactical prediction. It starts with taking stock of IT: Where do we come from, where are we right now and what are the trends that (most likely) will shape our future? I try to address those issues from several points of view, not necessarily creating a totally consistent picture of IT (which imo is not possible anyway), but trying to point out the most influential drivers of the past, today and the future. Then I try to locate microservices in that picture with mutliple angles - where they blend in. Having done that, I try to show how microservices will evolve in the future based on my observations. And in order to complete the journey, based on the anticipated future of microservices, I try to give a few recommendations for microservices developers of today how to prepare for that evolution. While - as written in the beginning - this is my take on the evolution of microservices and the voice track is missing, I still hope that it is a bit helpful and delivers some food for thought.

Life after microservices

Uwe Friedrichsen

This talk is basically a successor of the "DevOps is not enough talk", but with a broader focus. In the talk, after a short motivation, I try to take stock of the current state of IT from different points of view. After looking at, where we came from and where we are, I add the most important trends I currently see that affect us in IT. But knowing where we came from, where we are and where we are going to usually is not enough. The key point is using this information - in this talk for evaluating your current position as a software engineer and figuring out your desired future position. As all the details from the first part of the talk make it hard to do this evaluation, I suggest creating a model (actually a framework) on a reduced detail level that makes the evaluation and planning easier. Defining that framework is the third part of the talk. Finally, the last part consists of some general recommendations that - based on my understanding - help you as a software engineer to stay ahead of the curve for a while. While this is extremely much stuff (I really consider to split that plethora of information covered in this talk up in several, single-topic talks) and as always the voice track is missing, I still hope that the slide deck gives you a few ideas worth pondering.

The hitchhiker's guide for the confused developer

Uwe Friedrichsen

This slide deck is about the challenges we have to face if we deal with digitization solutions. As this term currently is massively overused, I first introduce a very simple definition to define what I mean with "digitization solution" in the context of the presentation. Afterwards, I list the challenges - at least the most relevant ones - that arise from moving into the digitzation solution domain. Based on that, I try to examine the trends, prerequisites and limitations that you are confronted with from an IT point of view and you better need to adapt to if you are confronted with digitization in your company. Last, but not least, I try to derive some practical hints for us as individuals, how we can prepare for such an environment. As always, the voice track is missing, but I hope also the slides on their own bear some value for you.

Digitization solutions - A new breed of software

Uwe Friedrichsen

Based on my observations, in IT we suffer from continuous collective amnesia and we are even proud of it. For at least 50 years meanwhile, we struggle how to build systems, that are easy to understand, to maintain, to change and to operate in a reliable way. Each time we hit the wall again, we start to look for a new silver bullet on the horizon, strongly believing that it will solve the problem for good. The key word is "new": "New" is good in our community, while "old" is bad, worthless, crap. We suffer from youthism, not only in recruiting, but in all areas. This way we discard any "old" knowledge, no matter if it is valuable or not. We separate by age, not by value. Additionally we continuously lose our collective memory with every new generation that leaves university as they are also taught not to value anything old and instead only look for the new, shiny stuff. While not all old knowledge is worth being preserved, admittedly, there is still a lot of valuable old knowledge available, offering answers to the problems that we face today - creating maintainable and reliable systems, dealing with distribution and tackling complexity, just to name a few of the challenges. This presentation is a journey through some (very) old computer science papers that contain a lot of very valuable knowledge regarding the problems we face today. For each of the papers, some of the key ideas are presented and how they address our current challenges. Of course, the voice track is missing and there are a lot more papers that would be worth being mentioned in this presentation. Still, I hope that also the slides alone will be of some value for you - and convince you a bit that not everything "old" in IT is automatically worthless ... ;)

Excavating the knowledge of our ancestors

Uwe Friedrichsen

In this slide deck I try to explore the meaning of the often misinterpreted sentence "You build it, you run it". Starting with its origin in a 2006 interview with Werner Vogels and a short description of the misinterpretation of that phrase that can be seen quite often these days in companies that try to pick up concepts like DevOps without really getting the idea behind it, I then start a bit longer journey. It starts with the history and evolution of markets and IT. Based on that I dive deeper into the effects of uncertainty which these days is often predominant for companies facing narrow and highly dynamic markets. I try to approach from a financial point of view as well as from a risk management point of view (yes, even if we have become agile, managing risk and financial aspects have not gone away). The basic result is that we need to go faster (in terms of cycle times) without compromising quality. I also add a quick litmus test to figure out where your own company currently is located as reality never is as simple as a slide deck - to avoid turning a thought model that should support reasoning into a dogma. Having the task set and understanding that IT must support going faster without compromising quality, I look at DevOps as it targets exactly the same goal. After a short explanation of what DevOps actually means (we face a perfect confusion of ideas when talking about DevOps) and what the effects are if you do it seriously, I focus on the effects for the process organization. The traditional process organization - while usually being set up nicely for cost efficiency - is very poor in terms of cycle times. In order to shorten cycle times those organization will eventually become cross-functional, autonomous teams with end-to-end responsibility. And while those teams have all skills and the full authority for all their activities, they also need to take over the full responsibility for their actions - their is no one left to blame ;) And this naturally leads to "(You decide it,) you build it, you run it" which in the end is a required organizational prerequisite for going fast in a DevOps way. There is a lot left out in the slides that would also be worth talking about (after all it is just a 60 min talk) and of course the voice track is missing, but I still hope that those slides are of some value for you.

The truth about "You build it, you run it!"

Uwe Friedrichsen

Más de Uwe Friedrichsen (7)

Timeless design in a cloud-native world

Deep learning - a primer

Life after microservices

The hitchhiker's guide for the confused developer

Digitization solutions - A new breed of software

Excavating the knowledge of our ancestors

The truth about "You build it, you run it!"

Último

Imagine a world where information flows as swiftly as thought itself, making decision-making as fluid as the data driving it. Every moment is critical, and the right tools can significantly boost your organization’s performance. The power of real-time data automation through FME can turn this vision into reality. Aimed at professionals eager to leverage real-time data for enhanced decision-making and efficiency, this webinar will cover the essentials of real-time data and its significance. We’ll explore: FME’s role in real-time event processing, from data intake and analysis to transformation and reporting An overview of leveraging streams vs. automations FME’s impact across various industries highlighted by real-life case studies Live demonstrations on setting up FME workflows for real-time data Practical advice on getting started, best practices, and tips for effective implementation Join us to enhance your skills in real-time data automation with FME, and take your operational capabilities to the next level.

From Event to Action: Accelerate Your Decision Making with Real-Time Automation

Safe Software

The 7 Things I Know About Cyber Security After 25 Years | April 2024

Rafal Los

Scaling API-first – The story of a global engineering organization

Radu Cotescu

Boost Fertility New Invention Ups Success Rates.pdf

sudhanshuwaghmare1

MySQL Webinar, presented on the 25th of April, 2024. Summary: MySQL solutions enable the deployment of diverse Database Architectures tailored to specific needs, including High Availability, Disaster Recovery, and Read Scale-Out. With MySQL Shell's AdminAPI, administrators can seamlessly set up, manage, and monitor these solutions, ensuring efficiency and ease of use in their administration. MySQL Router, on the other hand, provides transparent routing from the application traffic to the backend servers in the architectures, requiring minimal configuration. Completely built in-house and supported by Oracle, these solutions have been adopted by enterprises of all sizes for their business-critical applications. In this presentation, we'll delve into various database architecture solutions to help you choose the right one based on your business requirements. Focusing on technical details and the latest features to maximize the potential of these solutions.

Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...

Miguel Araújo

Created by Mozilla Research in 2012 and now part of Linux Foundation Europe, the Servo project is an experimental rendering engine written in Rust. It combines memory safety and concurrency to create an independent, modular, and embeddable rendering engine that adheres to web standards. Stewardship of Servo moved from Mozilla Research to the Linux Foundation in 2020, where its mission remains unchanged. After some slow years, in 2023 there has been renewed activity on the project, with a roadmap now focused on improving the engine’s CSS 2 conformance, exploring Android support, and making Servo a practical embeddable rendering engine. In this presentation, Rakhi Sharma reviews the status of the project, our recent developments in 2023, our collaboration with Tauri to make Servo an easy-to-use embeddable rendering engine, and our plans for the future to make Servo an alternative web rendering engine for the embedded devices industry. (c) Embedded Open Source Summit 2024 April 16-18, 2024 Seattle, Washington (US) https://events.linuxfoundation.org/embedded-open-source-summit/ https://ossna2024.sched.com/event/1aBNF/a-year-of-servo-reboot-where-are-we-now-rakhi-sharma-igalia

A Year of the Servo Reboot: Where Are We Now?

Igalia

Finology Group – Insurtech Innovation Award 2024

The Digital Insurer

Abhishek Deb(1), Mr Abdul Kalam(2) M. Des (UX) , School of Design, DIT University , Dehradun. This paper explores the future potential of AI-enabled smartphone processors, aiming to investigate the advancements, capabilities, and implications of integrating artificial intelligence (AI) into smartphone technology. The research study goals consist of evaluating the development of AI in mobile phone processors, analyzing the existing state as well as abilities of AI-enabled cpus determining future patterns as well as chances together with reviewing obstacles as well as factors to consider for more growth.

Exploring the Future Potential of AI-Enabled Smartphone Processors

debabhi2

How to convert PDF to text with Nanonets

naman860154

Presentation on how to chat with PDF using ChatGPT code interpreter

naman860154

BooK Now Call us at +918448380779 to hire a gorgeous and seductive call girl for sex. Take a Delhi Escort Service. The help of our escort agency is mostly meant for men who want sexual Indian Escorts In Delhi NCR. It should be noted that any impersonator will get 100 attention from our Young Girls Escorts in Delhi. They will assume the position of reliable allies. VIP Call Girl With Original Photos Book Tonight +918448380779 Our Cheap Price 1 Hour not available 2 Hours 5000 Full Night 8000 TAG: Call Girls in Delhi, Noida, Gurgaon, Ghaziabad, Connaught Place, Greater Kailash Delhi, Lajpat Nagar Delhi, Mayur Vihar Delhi, Chanakyapuri Delhi, New Friends Colony Delhi, Majnu Ka Tilla, Karol Bagh, Malviya Nagar, Saket, Khan Market, Noida Sector 18, Noida Sector 76, Noida Sector 51, Gurgaon Mg Road, Iffco Chowk Gurgaon, Rajiv Chowk Gurgaon All Delhi Ncr Free Home Deliver

08448380779 Call Girls In Civil Lines Women Seeking Men

Delhi Call girls

How to Troubleshoot Apps for the Modern Connected Worker

ThousandEyes

Choosing the right accounts payable services provider is a strategic decision that can significantly impact your business's financial performance and operational efficiency. By considering factors such as expertise, range of services, technology infrastructure, scalability, cost, and reputation, businesses can make informed decisions and select a provider that aligns with their unique needs and objectives. Partnering with the right provider can streamline accounts payable processes, drive cost savings, and position your business for long-term success. https://katprotech.com/accounts-payable-and-purchase-order-automation/

Factors to Consider When Choosing Accounts Payable Services Providers.pptx

Katpro Technologies

08448380779 Call Girls In Greater Kailash - I Women Seeking Men

Delhi Call girls

2024: Domino Containers - The Next Step. News from the Domino Container commu...

Martijn de Jong

Discord is a free app offering voice, video, and text chat functionalities, primarily catering to the gaming community. It serves as a hub for users to create and join servers tailored to their interests. Discord’s ecosystem comprises servers, each functioning as a distinct online community with its own channels dedicated to specific topics or activities. Users can engage in text-based discussions, voice calls, or video chats within these channels. Understanding Discord Servers Discord servers are virtual spaces where users congregate to interact, share content, and build communities. Servers may revolve around gaming, hobbies, interests, or fandoms, providing a platform for like-minded individuals to connect. Communication Features Discord offers a range of communication tools, including text channels for messaging, voice channels for real-time audio conversations, and video channels for face-to-face interactions. These features facilitate seamless communication and collaboration. What Does NSFW Mean? The acronym NSFW stands for “Not Safe For Work,” indicating content that may be inappropriate for professional or public settings. NSFW Content NSFW content encompasses material that is sexually explicit, violent, or otherwise graphic in nature. It often includes nudity, profanity, or depictions of sensitive topics.

Understanding Discord NSFW Servers A Guide for Responsible Users.pdf

UK Journal

Automating Google Workspace (GWS) & more with Apps Script

wesley chun

🐬 The future of MySQL is Postgres 🐘

RTylerCroy

What is a good lead in your organisation? Which leads are priority? What happens to leads? When sales and marketing give different answers to these questions, or perhaps aren't sure of the answers at all, frustrations build and opportunities are left on the table. Join us for an illuminating session with Cian McLoughlin, HubSpot Principal Customer Success Manager, as we look at that crucial piece of the customer journey in which leads are transferred from marketing to sales.

04-2024-HHUG-Sales-and-Marketing-Alignment.pptx

HampshireHUG

Axa Assurance Maroc - Insurer Innovation Award 2024

The Digital Insurer

Devops for Developers

1. Devops for Developers How Dev can write applications ready for Ops Uwe Friedrichsen, codecentric AG, 2013-2014

2. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

3. DevOps

4. DevOps DevQA DevPO DevRE DevPM DevDev DevDevPO DevDevDev

5. It‘s all about production!

6. Operations Developers Point of View

7. Admin Developers Point of View

8. Admin Closer to Reality Point of View

9. Top 5 Needs of an Admin 1.  Give me my peace and quiet! 2.  Don‘t make me think! 3.  Let me see that everything is fine! 4.  Show me the problem – now! 5.  Tell me what to do!

10. Top 5 Needs of an Admin (translated) 1.  Give me my peace and quiet!  (The application should just run smoothly) 2.  Don‘t make me think!  (Rollout, setup and operation of the application should be easy) 3.  Let me see that everything is fine!  (The application should show its state) 4.  Show me the problem – now!  (The application should provide concise error messages and enable easy root cause drilldown) 5.  Tell me what to do!  (The application should be documented properly – including error handling instructions)

11. Top 3 Dev Challenges 1.  Manageability 2.  Resilience 3.  Transparency 4.  Documentation

12. 11 Design Principles for DevOps-ready Applications •  Manageability (4) •  Resilience (5) •  Transparency (2)

13. Manageability

14. Deployment (Manageability)

15. •  One-click deployment •  Preserve settings •  Provide rollbacks (or roll-forward)

16. Configuration (Manageability)

17. •  Avoid multiple configuration procedures •  Define default value handling •  Organize change traceability •  Notification about new parameters

18. Configuration Parameter Types (Manageability)

19. •  Context-related parameters  Do not stage – managed by stage admin •  Application-related parameters  Must be staged – managed by application admin •  Business-related parameters  Must be staged – managed by business admin

20. Backup (Manageability)

21. •  Think about backup purpose •  Define backup strategy •  Provide tooling

22. Resilience

23. Bulkheads (Resilience)

24. •  Divide system in failure units •  Isolate failure units •  Define fallback strategy

25. Redundancy (Resilience)

26. •  Elaborate use case  Minimize MTTR / scale transactions / handle response errors / … •  Define routing & balancing strategy  Round robin / master-slave / fan-out & quickest one wins / … •  Consider admin involvement  Automatic vs. manual / notification – monitoring / …

27. Loose Coupling (Resilience)

28. •  Isolate failure units (complements bulkheads) •  Go asynchronous wherever possible •  Use timeouts & circuit breakers •  Make actions idempotent

29. Fallbacks (Resilience)

30. •  What will you do if a request fails? •  Consider failure handling from the very beginning •  Supplement with general failure handling strategies

31. Scalability (Resilience)

32. •  Define scaling strategy •  Think full stack •  Apply D-I-D rule •  Design for elasticity

33. Transparency

34. Monitoring (Transparency)

35. •  Think about required metrics •  Design hook or event mechanism •  Plan for changing metrics •  Consider event sourcing

36. Logging (Transparency)

37. •  Consider log message structure  All required information / machine readable / human readable •  Define logging policy  Debug and less: developers perspective / Info and more: operations perspective

38. 11 Design Principles •  Manageability •  Deployment •  Configuration •  Configuration Parameter Types •  Backup •  Resilience •  Bulkheads •  Redundancy •  Loose Coupling •  Fallbacks •  Scalability •  Transparency •  Monitoring •  Logging

39. Wrap-up •  Dev often does not know Ops •  Know the needs of an admin •  Face the challenges for a developer •  Apply the design principles … and then you‘re ready for DevOps

40. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

Devops for Developers

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (8)

Destacado

Destacado (20)

Similar a Devops for Developers

Similar a Devops for Developers (20)

Más de Uwe Friedrichsen

Más de Uwe Friedrichsen (7)

Último

Último (20)

Devops for Developers