Object-oriented design for infrastructure-as-a-code - Anna Bankirer

•

0 likes•249 views

Infrastructure code can really benefit from some proven object oriented design principles like SOLID and others. Instead of just thinking about automation, we need to design and build infrastructure software systems that are easy to understand, test and maintain Everyone talks about the fact that infrastructure should be programmatic and treated as a code, but often what this means is just writing a bunch of scripts to automate our deployments. By doing so, aspects like proper documentation, separation to modules , abstraction, even version control that are standard for "regular" software projects are omitted from infrastructure systems. This leads to cumbersome, monolith system - the very thing we are trying to resolve in the software design. I would like to discuss the basic software design principles like SOLID and DRY and how to apply them when automating our deployments, writing docker containers or writing our application stack.

Object Oriented
Design
For infrastructure code
Anna Bankirer

Introduction
Anna Bankirer
Software Engineer
Backend, infrastructure,
Distributed systems
anna.bankirer@aidoc.com

Introduction
❑ What is Object Oriented Design?
❑ How OOD can beneﬁt infrastructure development
❑ Disclaimer

What OOD is NOT
❑ Inheritance
❑ Polymorphism
❑ Complex hierarchies
❑ Multiple levels of abstraction

What is the origin of OOD?
❑ Who coined the term?
❑ What problem is it supposed to
solve?
❑ Build modular decentralized
systems that are resilient to change

What is OOD about?
“ Build systems that are
resilient to change ”
No need to be perfect
Java, C#?

History - how did we get here
It’s 1960
Meet the computer
programmer

History - how did we get here
Software 2000
❑ New discipline
❑ Abstract the infra
❑ Build software
systems
❑ The rise of OOD

History - how did we get here
❏ Hardware
❏ Performance
❏ Databases
❏ Networking
❏ Internet
❏ Cloud
Infrastructure 2000

Where are we now
● Infrastructure status
● Software status

Where are we now
Application code
+
Infrastructure code
=
<3

What is an Object
❑ Independent entity
❑ Internal state
❑ Operations
❑ Speciﬁc purpose

Basic OOD Principles
❑ Single responsibility
❑ Dependency inversion
SOLID

SRP - Single Responsibility
Principle
Do one thing and do it well
- easier said than done.
“Only one reason to change”
(Robert Martin)

SRP - Single Responsibility
Principle
❑ Small components
❑ Similar together
❑ Limit the impact of change.
❑ Tests
“Gather together the things that change for the same reasons.
Separate those things that change for different reasons.”
(Robert Martin)

SRP in a restaurant
❑ Small - 1 man show
❑ Big - assign responsibility
❑ Easier to manage, scale

Dependency inversion
“High-level modules should not depend on
low-level modules. Both should depend on
abstractions.” (Robert Martin)
❏ Complex objects
❏ More dependencies - less resilient to change
❏ Use simple objects + abstraction
❏ Limit the impact of future change
❏ Easier to test

Dependency inversion
in a restaurant
❑ In house delivery service
❑ Outsourcing==Abstraction
❑ Less control less
dependency
❑ Easier to change

Our architecture (before)
❑ So 2017..
❑ 2 services
❑ Main pain

Our architecture (now)
❑ So 2019..
❑ Dynamic
❑ Modular
❑ Consul
❑ Queues

Single Responsibility
Principle
❑ Objects
❑ responsibilities
❑ Deploy

Conclusion and takeaways
❑ OOD not only for application code
❑ See for yourself and decide
❑ KISS - Keep It Simple Stupid

Thank you!
https://www.linkedin.com/in/anna-bankirer-41a0b81
https://www.aidoc.com/careers/

Resources used in the talk
and other useful links
❑ https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship
/dp/0132350882
❑ https://www.amazon.com/gp/product/0201633612?ie=UTF8&tag=martinfo
wlerc-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=020163361
2
❑ https://medium.com/javascript-scene/the-forgotten-history-of-oop-88d71
b9b2d9f
❑ https://dev.to/checkgit/the-joel-test-20-years-later-1kjk
❑ https://hackernoon.com/you-dont-understand-the-single-responsibility-pri
nciple-abfdd005b137
❑ https://hackernoon.com/solid-principles-made-easy-67b1246bcdf

When it comes to data solutions, one-size doesn’t fit all. Choosing the right best-matching database, or data tools, can be a game changer for your system. How can you take such decision effectively? The system, the company, the product, and probably your team - all are evolving, and the best solution for today may not fit tomorrow’s needs. In order to pick a data solution for longer term, you should evaluate the optional data tools according to several factors. These factors will reflect the requirements looking forward. At this session, we will share such use case, of evaluating data solution, when we redesigned one of Oribi features from scratch. Our goal was to avoid a data explosion crisis, while the system kept scaling up. Having so many solutions out there - we needed to make sure that we are choosing the one that will support the increasing load farthest. Eventually we picked up ten criteria factors, which we used to compare and choose the best solution effectively. Join the session to hear what were these factors, and get prepared for choosing the next data solution for your system.

THE PLEASURES OF ON-PREM, TOMER GABEL

DevOpsDays Tel Aviv

The last two decades have been all about SaaS, with advantages that cannot be overstated. Except SaaS isn’t always an option, nor is it always the right choice: businesses in tightly regulated industries, or where information security is paramount, for example, will not - often can not - consider any software that isn’t under their control. For many software enterprises, this leads to the dreaded inevitability of on-premise deployment. Fortunately, the situation today is dramatically different to a scant few years ago, let alone a decade or two: the same technologies that enable SaaS have also radically transformed on-prem deployment. Modern tools like Docker, Consul, ELK and Kubernetes - to name a few - can be leveraged to completely transform the experience for both customers and vendors. In this talk we’ll contrast the challenges and advantages of SaaS and on-prem, see how things have evolved in recent history, and see how modern on-prem deployment can be, if not pleasurable, at least relatively painless.

Solving trust issues at scale - Omer Levi Hevroni

DevOpsDays Tel Aviv

Securing service to service communication was never easy. Can we build a system that enforce good practices like least privilege and secure by default without affecting devlopement velocity? Apparently yes - and in this talk I’ll share how! Micro-services are social beings: they can’t function without talking with other services. Every microservice has its own domain, and it usually relies on other micro-services to function properly. But this also raises an interesting question: do we trust all of our micro-services? The truth is that not all micro-services are the same: some micro-services are more sensitive - for example, services that handle user data. Others are user-facing and therefore riskier. We cannot treat all services as equal. We need a good and robust mechanism to describe who can talk with who. At Soluto, we are dealing with this challenge for a while. In this talk, I’ll share the journey we went through until we found a solution we’re happy with: a simple and declarative system that allows services to define who can access them. Any dev can request access to any service, and the service owner can review it. In talk, I’ll share how we build this solution, using open source tools like Open Policy Agent, so you can easily build something similar.

Strong Consistency in Databases. What does it actually guarantee? - Andy Goo...

DevOpsDays Tel Aviv

Subject to the CAP theorem, NoSQL distributed systems have mostly chosen availability over consistency. This has been changing, yet many famous databases are still AP only. This talk includes a theoretical overview, and a practical look at the tradeoffs for your application and data between AP and CP modes. Also, how do different levels of consistency actually matter? Distributed data stores are subject to the CAP theorem, and historically NoSQL distributed systems have chosen availability over consistency. This has been changing, yet many famous databases are still AP only. In Eric Brewer's 2012 follow-up article about the CAP theorem he stated: "Availability is obviously continuous from 0 to 100 percent, but there are also many levels of consistency, and even partitions have nuances, including disagreement within the system about whether a partition exists." This talk will include a theoretical overview, but focus on the practical aspects of the theorem. * What are the tradeoffs between AP and CP modes? * How do they affect your application and data? * How do different levels of consistency actually matter?

Managing Data in Microservices

Randy Shoup

From a talk at the SF CTO Summit 2017 (https://www.ctoconnection.com/summits/sf2017), these slides cover the speaker's experience at Stitch Fix with managing data in a microservices environment. Areas include: * Breaking up a monolithic database into services * Using events as a first-class part of your architecture * Sharing data among microservices * Handling "joins" among microservices * Simulating "transactions" among microservices using the Saga pattern

Why Enterprises Are Embracing the Cloud

Randy Shoup

After being deeply involved in public cloud for the last several years, as both a provider and a consumer, I have been very pleasantly surprised at the rate at which large enterprises are rapidly moving to the cloud. For all the right reasons, even the most regulated and risk-averse of industries -- banking, for example -- are rapidly moving workloads out of their own owned data centers. Public cloud is not just for the "unicorns", but for the "horses" as well. This short vignette, presented at the GOTO Aarhus 2014 conference, tries to explain why this trend will continue and accelerate, and why we should be excited about it.

Scaling Your Architecture for the Long Term

Randy Shoup

One Terrible Day at Google, and How It Made Us Better

Randy Shoup

The best response to a system outage is not "What did you do?", but "What did we learn?" This session will walk through three system-wide outages at Google, at Stitch Fix, and at WeWork—their incidents, aftermaths, and recoveries. In all cases, many things went right and a few went wrong; also in all cases, because of blameless cultures, we buckled down, learned a lot, and made substantial improvements in the systems for the future. Looking back with the perspective of 20-20 hindsight, all of these incidents were seminal events that changed the focus and trajectory of engineering at each organization. You will leave with a set of actionable suggestions in dealing with customers, engineering teams, and upper management. You will also enjoy a few war stories from the trenches.

Testit 2017 - Exploratory Testing for Everyone

Johan Hoberg

Service Architectures at Scale

Randy Shoup

How do effective large-scale service ecosystems work? Keynote Presentation at Istanbul Tech Talks 2018 How to Design Services * Systems of record * Interface specification * Interface backward / forward compatibility Service Ecosystems * Layered services * "Standardization" through encouragement * Vendor-customer relationships between teams Operating and Deploying Services * Data Migration * Automated Pipelines * Incremental Deployment * Feature Flags

Evolving Architecture and Organization - Lessons from Google and eBay

Randy Shoup

Keynote at DevOpsDays Cuba Successful Internet companies are built on a foundation of excellent culture, efficient organization, and solid technology. As a company needs to scale, all of these parts of the foundation need to grow and scale with it. This session covers modern best practices at innovative companies in Silicon Valley for scaling culture, organization, and technology. Driven primarily by the presenter's experience ranging from small Valley startups to Google and eBay, it discusses: * Organizing small, fast-moving engineering teams * Building a scalable system out of smaller microservices * Maintaining a culture of ownership and collaboration * Developing effective engineering processes of continuous integration and continuous delivery

Minimum Viable Architecture - Good Enough is Good Enough

Randy Shoup

The “right” architecture and organization depends on the size and scale of your company. The only constant is change, and what works for 5 engineers does not work for 5000. Based upon lessons from Google and eBay, learn how to evolve both technology and organization together successfully. This presentation is based on many hard-won lessons by the speaker, who led large-scale engineering teams at Google and eBay, but also co-founded a tiny startup and tried (unsuccessfully) to apply the same techniques. This session hopes to help others from making the same mistakes by introducing the concept of “Minimal Viable Architecture”. It outlines the common architectural evolution of a company or project through the search, execution, and scaling phases, and discusses the appropriate technologies, disciplines, and organizational structures at each phase. You'll start with a monolith, and end up with microservices, and that's completely and entirely appropriate.

Minimal Viable Architecture - Silicon Slopes 2020

Randy Shoup

This presentation introduces the idea of a "Minimal Viable Architecture". As a company and product evolves, its architecture should evolve as well. We talk about the different phases of a product -- from the idea phase, to the starting phase, scaling phase, and optimizing phase. For each phase, we discuss the goals and constraints on the business, and we suggest an appropriate software architecture to match. Throughout the presentation, we use examples from eBay, Google, StitchFix, and others.

Monoliths, Migrations, and Microservices

Randy Shoup

How to adopt React for moving fast startup

Sira Sujjinanont

Anatomy of Three Incidents -- Commonalities and Lessons

Randy Shoup

Testing Small Agile Projects from Agile Vancouver Quality Conference 2014

Lanette Creamer

Competency Center: retaining experts, growing expertise, maximizing income (O...

Valentin Kropov

The stronger IT engineer, the faster his natural desire to receive the maximum amount of experience, but it is often impossible to achieve it w/o project or in some cases even company change . How to retain highly skilled professionals and make them answering: "Thank you, but I have the best job in the world!" to any recruiter request, thus avoiding hard and expensive replacement search? Unexpected sick leaves, prolonged holidays, unforeseen circumstances – creates a significant risk of failure or delays in the project. How to make sure that there is always someone to finish project no matter what, ensuring the reliability of the project in face of the customer? How to deal with situations where the short-term expertise of highly qualified specialists are required to start a new project as soon as possible? How to minimize staffing time to zero, thereby increasing profits? How to provide first-class technical pre-sales support process that any potential customer can't resist, to get even more interesting and profitable projects? Valentin Kropov, senior consultant in SoftServe's gives the answers to these questions in his speech "Competency Center: retaining experts, growing expertise, maximizing income".

The agile elephant in the room

AgileDenver

There are many excellent courses, books and videos that can help you learn Agile and Scrum, but they all tend to ignore some common challenges teams run into. For example, non-functional requirements. How should we deal with them? Technical stories are also a big challenge. Good luck finding concrete, unbiased information on the pros and cons of the different approaches. Forecasting is another great example. How do you estimate or forecast an entire project? This session will cover a number of these "elephants" in the room and provide concrete and unbiased advise on how to deal with them. All recommendations are based on real-world experiences and will include an honest discussion of relevant pros and cons.

How To Train Your Microservice

VMware Tanzu

SpringOne Platform 2016 Speaker: Doug Sherman; Principal Engineer, DreamWorks DreamWorks Animation is a company that has historically thrived on taking advantage of cutting edge technologies and has more currently set its sights on further utilizing Microservices and the Cloud as part of its movie making process. This session will review the efforts that took place in both the initial phases which incorporated targeted parts of the Spring Framework, as well as more current efforts that leveraged Spring projects such as Spring Boot, Spring Data and Spring Cloud. Highlighted throughout the talk will be examples demonstrating the pros and cons of various approaches taken, including the social engineering aspects of changing a movie making culture to fully embrace what it means to adopt a Microservices platform.

Introduction to the Typesafe Reactive Platform

BoldRadius Solutions

In this webinar, Michael Nash of BoldRadius explores the Typesafe Reactive Platform. The Typesafe Reactive Platform is a suite of technologies and tools that support the creation of reactive applications, that is, applications that handle the kind of responsiveness requirements, data volume, and user load that was out of practical reach only a few years ago. From analysis of the human genome to wearable technology to communications at a massive scale, BoldRadius has the premier team of experts with decades of collective experience in designing and building these types of applications, and in helping teams adopt these tools.

Lazar Milovic - No estimates

Serbian Product Community

OneHourTranslation - AWS Cloud Case Study

Newvewm

One Hour Translation provides High quality, Fast, 24x7 Professional Human Translation in more than 57 languages. We are able to provide high-quality translations around the clock, any day, thanks to a community of over 10000 professional translators from over 100 different countries. One Hour Translation serve tens of thousands of projects a month thanks to AWS cloud technologies which enables fast and transparent scaling of our service. In this session I will present a case study for IT architecture and deployment on AWS with security monitoring using Newvem's services. Oren Yagev Co-Founder, CTO at OneHourTranslation.com

Tis The Season: Load Testing Tips and Checklist for Retail Seasonal Readiness

SOASTA

‘Tis the Season – Holiday 2014 eCommerce Quality Checklist Past Webinar Archived (originally presented June 26th, 2014) This year, your holiday traffic will increase 15% or more, and 50% of the users will be mobile. Recent research shows 71% of your revenue comes from multi-channel users, so if you haven’t started planning, you’re already behind. Leading retailers are preparing for Holiday “14 and testing their production sites for multi-channel access to 115% capacity, or beyond! If you’re not one of them, your plans are incomplete. Cover your risks. Join Tenzing and SOASTA experts as they discuss the must-do checklist for peak performance. In this webinar you’ll learn: Align your Marketing and Quality plans Cover the multichannel user experience Test early in the lab and fully in production Optimize end-to-end site speed and performance When to freeze for the winter Don’t miss this opportunity to “shop early” and see how the leading retailers are already beating the odds with cloud testing.

ASPgems Company Profile

Agustin Cuenca

Software architecture, Patterns for Scale

iGbanam

SFSCON23 - Daniele Fontani Daniele Ciulli - CrudIt an opensource framework t...

South Tyrol Free Software Conference

Nowadays application implementation requires a lot of different competencies that make it impossible for a single person to build an entire application. This led to the need for a big multi-competencies team and increasing in communication issues during the project. But what if we could implement an application without the need of implementing a backend? CrudIt does exactly that. CrudiIt is an open-source framework that enables a small team or a single front-end developer to create small SaaS applications without any knowledge of backend, cloud and sysadmin needs. During the event, we will see how to implement a simple SaaS service using Crudit and how to use the framework to accelerate application development. Moreover, we will discuss how to host a CrudIt application without any sysadmin competencies in the cloud, using free services. This talk will unveil how, thanks to this powerful low-code framework, it is possible to save data without writing a line of code, even if you are working in complex, multitenant scenarios. The talk will explain also how the framework is born, how it works internally and promote the opensource philosophy that brings to this library.

CQRS recipes or how to cook your architecture

Thomas Jaskula

What's hot

OWASP Developer Guide Reboot

Andrew van der Stock

Learning from Learnings: Anatomy of Three Incidents

Randy Shoup

Testit 2017 - Exploratory Testing for Everyone

Johan Hoberg

Service Architectures at Scale

Randy Shoup

Evolving Architecture and Organization - Lessons from Google and eBay

Randy Shoup

Minimum Viable Architecture - Good Enough is Good Enough

Randy Shoup

Minimal Viable Architecture - Silicon Slopes 2020

Randy Shoup

Monoliths, Migrations, and Microservices

Randy Shoup

How to adopt React for moving fast startup

Sira Sujjinanont

Anatomy of Three Incidents -- Commonalities and Lessons

Randy Shoup

Testing Small Agile Projects from Agile Vancouver Quality Conference 2014

Lanette Creamer

Competency Center: retaining experts, growing expertise, maximizing income (O...

Valentin Kropov

The agile elephant in the room

AgileDenver

How To Train Your Microservice

VMware Tanzu

Introduction to the Typesafe Reactive Platform

BoldRadius Solutions

Lazar Milovic - No estimates

Serbian Product Community

OneHourTranslation - AWS Cloud Case Study

Newvewm

Tis The Season: Load Testing Tips and Checklist for Retail Seasonal Readiness

SOASTA

ASPgems Company Profile

Agustin Cuenca

What's hot (19)

OWASP Developer Guide Reboot

Learning from Learnings: Anatomy of Three Incidents

Testit 2017 - Exploratory Testing for Everyone

Service Architectures at Scale

Evolving Architecture and Organization - Lessons from Google and eBay

Minimum Viable Architecture - Good Enough is Good Enough

Minimal Viable Architecture - Silicon Slopes 2020

Monoliths, Migrations, and Microservices

How to adopt React for moving fast startup

Anatomy of Three Incidents -- Commonalities and Lessons

Testing Small Agile Projects from Agile Vancouver Quality Conference 2014

Competency Center: retaining experts, growing expertise, maximizing income (O...

The agile elephant in the room

How To Train Your Microservice

Introduction to the Typesafe Reactive Platform

Lazar Milovic - No estimates

OneHourTranslation - AWS Cloud Case Study

Tis The Season: Load Testing Tips and Checklist for Retail Seasonal Readiness

ASPgems Company Profile

Similar to Object-oriented design for infrastructure-as-a-code - Anna Bankirer

Software architecture, Patterns for Scale

iGbanam

SFSCON23 - Daniele Fontani Daniele Ciulli - CrudIt an opensource framework t...

South Tyrol Free Software Conference

CQRS recipes or how to cook your architecture

Thomas Jaskula

How Financial Institutions Must Enforce DevOps Organizational Policy

Tamir Belzer

The Bleeding Edge

jClarity

Enterprise Java developers value reliability and stability, but what happens to your technology stack if you’re willing to take a risk? At jClarity we’re running production systems using HTML 5, AngularJS, Vert.x, Mongo, Groovy and deploying using Chef. Its been an interesting ride: some things worked really well and some things don’t. Come along and find out what we’d recommend and what we’d avoid with hindsight. We’ll also talk about how we ended up with such a diverse stack and how to make technology choices in a fairer way. We’ve made the mistakes so you don’t have to!

The Bleeding Edge

RichardWarburton

Enterprise Java developers value reliability and stability, but what happens to your technology stack if you’re willing to take a risk? At jClarity we’re running production systems using Html 5, Angular.js, vertx, Mongo, groovy and deploying using chef. Its been an interesting ride: some things worked really well and some things don’t. Come along and find out what we’d recommend and what we’d avoid with hindsight. We’ll also talk about how we ended up with such a diverse stack and how to make technology choices in a fairer way. We’ve made the mistakes so you don’t have to.

Functional Ops - the cake is a lie

rhirschfeld

Beyond rails new

Paul Oguda

Evolving to Cloud-Native - Anand Rao

VMware Tanzu

Beyond The Rails Way

Andrzej Krzywda

Object Oriented Design Principles

Thang Tran Duc

The CQRS diet

Luismi Cavallé

Presented at Conferencia Rails 2010 You probably follow the motto “skinny controller, fat model”, which is a good thing. Skinny controllers are definitely the way to go but, as your domain logic grows, it’s very easy to end up with a model overweight problem, which is not so good. The issue is that your ActiveRecord objects have to deal with too many different responsibilities: validation, business rules, awareness of its own persistence, filtering… Command-Query Responsibility Segregation (CQRS) is an architectural pattern that promises to improve the maintainability, performance and scalability of your applications by helping to separate concerns in your system. This pattern, along with Event Sourcing and other Domain-Driven Design ideas, is gaining increased popularity, particularly among developers building solutions for rich / complex domains. This talk will introduce these concepts and show different ways we can (re)architect our Rails application in order to get their benefits. From a simple implementation using just the “tools in the room” to a implementation “in all its full glory” using NoSQL data stores and messaging queues. All those who have a Rails projects complex enough to abuse of model callbacks, de-normalize the database or use presenter objects, may get benefits in terms of simplicity and maintainability from implementing the ideas I’ll present in this talk.

Refactoring to SOLID Code

Adil Mughal

It is a sunny day

bcoder

Friday final test

bcoder

Pilot's Engineering Principles

Jill Wetzler

From good to solid: How to become a better developer

Katerina Trajchevska

Laptop Devops: Putting Modern Infrastructure Automation to Work For Local Dev...

Thoughtworks

Getting out of the monolith hell

mimmozzo_

L21 Architecture and Agile

Ólafur Andri Ragnarsson

Similar to Object-oriented design for infrastructure-as-a-code - Anna Bankirer (20)

Software architecture, Patterns for Scale

SFSCON23 - Daniele Fontani Daniele Ciulli - CrudIt an opensource framework t...

CQRS recipes or how to cook your architecture

How Financial Institutions Must Enforce DevOps Organizational Policy

The Bleeding Edge

Functional Ops - the cake is a lie

Beyond rails new

Evolving to Cloud-Native - Anand Rao

Beyond The Rails Way

Object Oriented Design Principles

The CQRS diet

Refactoring to SOLID Code

It is a sunny day

Friday final test

Pilot's Engineering Principles

From good to solid: How to become a better developer

Laptop Devops: Putting Modern Infrastructure Automation to Work For Local Dev...

Getting out of the monolith hell

L21 Architecture and Agile

More from DevOpsDays Tel Aviv

YOUR OPEN SOURCE PROJECT IS LIKE A STARTUP, TREAT IT LIKE ONE, EYAR ZILBERMAN...

DevOpsDays Tel Aviv

From idea to execution, the challenges of publishing an open source project are very similar to initializing a startup when it comes to creating a successful product that people will love and use. Most open source projects are not “taking-off”, although they are really good! This is because developers (which are usually the creators of open source projects) think that writing the code is the hard part and “neglect” the other parts of publishing a good open source project. In this talk, I will use my experience as a contributor to open source and product head of a startup, to go beyond writing the code itself and cover the other central aspects of creating an open source project, like MVP, product/market fit, marketing and more.

GRAPHQL TO THE RES(T)CUE, ELLA SHARAKANSKI, Salto

DevOpsDays Tel Aviv

If you have never used GraphQL before, you probably think that it is just another buzzword that will be forgotten in a few years. You might think: “Why do I need to learn a new way to write APIs when REST already answers all my needs?”. Or, you are excited to learn something new but don’t believe GraphQL is mature enough for production. In this talk, I will remind you of some of the pain points you have probably experienced when using REST. I will then explain what GraphQL is and demonstrate how it solves these pain points. Next, I will discuss the disadvantages of GraphQL. Finally, I will provide some guidelines for choosing between REST and GraphQL. By the end of this talk, you will understand what GraphQL is and when to use it.

MICROSERVICES ABOVE THE CLOUD - DESIGNING THE INTERNATIONAL SPACE STATION FOR...

DevOpsDays Tel Aviv

“The International Space Station has been orbiting the Earth for over 20 years. It was not launched fully formed, as a monolith in space. Instead, it is built out of dozens of individual modules, each with a dedicated role - life support, engineering, science, commercial applications and more. Each module (or container) functions as a microservice, adding additional capabilities to the whole. Not only do the modules need to function together, delivering both functional and non-functional capabilities, they were designed, developed and built by different countries on Earth and once launched into space (deployed in multiple different ways), had to work together - perfectly. Despite the many (minor) reliability issues which have occurred over the decades, the ISS remains a highly reliable platform for cutting edge scientific and engineering research. In this session I will describe the way the space station was developed and the lessons Site Reliability and DevOps Engineers can learn from it.

THE (IR)RATIONAL INCIDENT RESPONSE: HOW PSYCHOLOGICAL BIASES AFFECT INCIDENT ...

DevOpsDays Tel Aviv

Have you ever felt you took every wrong turn possible in the process of mitigating a production incident? Did you go through a 3-hour hell during incident response and felt the incident wasn’t complex enough to justify the horrors you’ve experienced? Did it cause you to question your engineering or problem-solving skills? Well, it’s only partially you. Our brain is wired to make decision-making simpler. In doing so, it exposes itself to biases, heuristics, and other quirks that may seem like “bad decisions” in hindsight. In this talk, through real-life outages, we’ll project those psychological principles onto the world of production monitor, and incident management. As a responder, you’ll learn why those behavioral patterns emerge during production incidents and what can be done to limit their effect, and as a manager, you’ll learn how to enable and encourage a healthy environment to better support those patterns.

PRINCIPLES OF OBSERVABILITY // DANIEL MAHER, DataDog

DevOpsDays Tel Aviv

The word observable entered the English language roughly 400 years ago, but the concepts of what it means to see, comprehend, and understand something have been debated since time immemorial. Starting in the 19th century, a series of postulates and criteria coalesced into control theory, and it is from this body of knowledge that we gained the word “observability”. Today, with the advent of complex, interconnected computer systems, that word has taken on new meanings and connotations—some useful, some detrimental, and some just plain confusing. In this talk, we’ll mix a little history, a touch of philosophy, and a healthy dose of reality, to demystify what observability means to us as professional computer people. We’ll tear through the marketing material and unearth foundational principles that will help us to build better infrastructure, write better software, and promote healthier business practices. Finally, we’ll explore some potential new avenues for discussion and understanding.

NUDGE AND SLUDGE: DRIVING SECURITY WITH DESIGN // J. WOLFGANG GOERLICH, Duo S...

DevOpsDays Tel Aviv

Security people say users are the weakest link. But are they? When complying with security becomes too burdensome, users take shortcuts, find workarounds, and end up jeopardizing security. Blaming users is lazy and easy. Making security usable is time consuming and challenging. How does design research help us understand our customers? What patterns and principles drive secure behavior? How can we build empathy with customers and make the right thing to do the easiest thing to do? This session explores these questions, and provides examples of how design thinking and research can help us be more secure. We will walk through our creation of core user personas, design principles, and how these inform and direct our design choices and intent. Don’t blame your users anymore. Come learn how to be part of a future where usability leads security.

(Ignite) TAKE A HIKE: PREVENTING BATTERY CORROSION - LEAH VOGEL, CHEGG

DevOpsDays Tel Aviv

This is for you, you rockstar, ninja coffee drinking workaholic who doesn’t know what a vacation day looks like. Even though you love your job and are dedicated and are super important, you need a break too. We tend to think that working all the time is an effective practice while the truth is that finding the time for self care and recharging your batteries is beneficial for both you and your company. Additionally, if you’re a leader, you’re responsible for the wellbeing of your team. In this talk I’ll discuss the importance of taking time off of work and creating a positive culture surrounding vacation time.

BUILDING A DR PLAN FOR YOUR CLOUD INFRASTRUCTURE FROM THE GROUND UP, MOSHE BE...

DevOpsDays Tel Aviv

This is a story about taking the cloud infrastructure of a successful company, that is still managed as infrastructure of a startup company, and rebuilding it to support the growing business requirements, especially around disaster recovery and business continuity. In the session I will share Next Insurance’s journey - where we started, where we are now and what we learned on the way so far. I will talk about how we managed to build our proven DR plans, and actually execute them in our DR drills. I will also talk about why we decided that the only way to prove your DR plan works is to continue running your business in the DR account and make it your production account, and go on to build your next DR account. If you are a part of a company that is about to embark on a similar journey, this session might equip you with some very useful insights on how to think about such a challenge, and some very useful and practical tips on how to execute it.

THE THREE DISCIPLINES OF CI/CD SECURITY, DANIEL KRIVELEVICH, Cider Security

DevOpsDays Tel Aviv

CI/CD pipelines are quickly becoming the path of least resistance for would-be attackers into sensitive internal systems, gaining access to critical data, with minimal effort. In the InfoSec world when we talk about CI/CD security often times this focuses on specific aspects of securing your pipeline - scanning the code, protecting secrets, securely managing code deployments, or even authentication and authorization mechanisms, but we rarely talk about all of these together. After years of being in the trenches and realizing that the attack surface is growing and the threat landscape becoming more and more complex, it has become increasingly apparent that security teams need to adapt and modify strategies to keep up with the new reality of CI/CD protection, without compromising developer velocity. In this talk I would like to propose a new way of thinking about CI/CD security - that encompasses the three disciplines that comprise CI/CD security - security in the pipeline, of the pipeline, and around the pipeline. Partial coverage of any or all of these disciplines simply will not cut it with the continuously evolving risk landscape. Security engineers need to address each of these aspects in their entirety to provide the full scope of coverage that modern organizations need, and I will take a deep dive on the challenges each introduce, and the approaches and techniques for mitigating them based on adversarial sec research.

CONFIGURATION MANAGEMENT IN THE CLOUD NATIVE ERA, SHAHAR MINTZ, EggPack

DevOpsDays Tel Aviv

Configuration Management is at the core of Ops. It’s the biggest enabler of any compute operation, small and big. In the past decade, we have switched from thinking about the machines we are configuring, to think about the software and services we are controlling. With that change of mindset, so did the tools we are using. Traditional tools like Puppet, chef, salt and Ansible are slowly declining while new tools such as Terraform, Pulumi, Helm and Kustomize are on the rise. In this talk I will try to describe the pain-points and the opportunities of this transformation as well as suggesting a future direction based on tools developed at the big-tech companies (Mainly facebook and google).

SOLVING THE DEVOPS CRISIS, ONE PERSON AT A TIME, CHRISTINA BABITSKI, Develeap

DevOpsDays Tel Aviv

We all know how hard it is to find DevOps engineers, and creating a diverse team despite gender and ethnicity bias? Nearly impossible. At this talk we will show our tools and methods implemented in the Develeap hiring process that overcome this inherited bias. About 2 years ago we faced a crisis in our DevOps consulting company - the market demand was higher than we could supply. The traditional recruiting process depending on CV and artificial credentials was not working. So we came up with an alternative solution, and since then - we are growing exponentially and diversely. In this talk we will show the practical tools we deployed in order to increase our capacity, and we will show how these tools overcome the inherited bias in the process.

OPTIMIZING PERFORMANCE USING CONTINUOUS PRODUCTION PROFILING ,YONATAN GOLDSCH...

DevOpsDays Tel Aviv

Everyone wants observability into their system, but find themselves with too many vendors and tools, each with its own API, SDK, agent and collectors. With the increasing complexity of modern applications, continuous profiling methods and tools are gaining popularity among the Developer and Engineering communities. In this session, we cover what continuous profiling entails and why you should implement a profiler into your tech stack (if you haven’t done so already). We’ll then bring theory to practice and demonstrate a real-life scenario using gProfiler, a free open-source continuous profiling tool, covering Linux servers on multiple architectures (such as Graviton).

HOW TO SCALE YOUR ONCALL OPERATION, AND SURVIVE TO TELL, ANTON DRUKH

DevOpsDays Tel Aviv

“Being oncall sucks. But it doesn’t have to!” We all heard this one before. Why is it though, that oncall still remains the biggest scar for many? What can a modern Engineering org do to rein the oncall dragons, and actually help people grow as professionals as they go oncall? In this talk, I will present the main reasons why oncall is difficult in modern orgs, and describe ways to mitigate these hardships. The idea is that oncall is often the ‘backroom’ of an org, where all the technical and organizational debt take their toll. Be it unwieldy systems or broken processes between teams, oncall checks all the ‘weak boxes’. Therefore, the only way to win at oncall is to sort out your debts, starting with the organizational ones. I will dive into the detail of the oncall rotation at Snyk as the org scaled from 1 to 220 people, what worked well about it, and what was less than perfect. I will discuss the decisions made to turn oncall into a building block of the org, and show a path to rein oncall in your organization as well.

HOW TO OPTIMIZE NON-CODING TIME, ORI KEREN, LinearB

DevOpsDays Tel Aviv

Github Copilot and tools that help us code better are cool. But I’m lucky if I spend 90 minutes a day writing code. We really need to optimize the hours we spend reviewing code, updating tickets and tracing where our code is deployed. Learn how I save an hour a day streamlining non-coding tasks. This talk is unique because 99% of developer productivity tools and hacks are about coding faster, better, smarter. And yet the vast majority of our time is spent doing all of this other stuff. After I started focusing on optimizing the 10 hours I spend every day on non-coding tasks, I found I my productivity went up and my frustration at annoying stuff went way down. I cover how to save time by reducing cognitive load and by cutting menial, non-coding tasks that we have to perform 10-50 times every day. For example: Bug or hotfix comes through and you want to start working on it right away so you create a branch and start fixing. What you don’t do is create a Jira ticket but then later your boss/PM/CSM yells at your due to lack of visibility. I share how I automated ticket creation in Slack by correlating Github to Jira. You have 20 minutes until your next meeting and you open a pull request and start a review. But you get pulled away half way through and when you come back the next day you forgot everything and have to start over. Huge waste of time. I share an ML job I wrote that tells me how long the review will take so I can pick PRs that fit the amount of time I have. You build. You ship it. You own it. Great. But after I merge my code I never know where it actually is. Did the CI job fail? Is it release under feature flag? Did it just go GA to everyone? I share a bot I wrote that personally tells me where my code is in the pipeline after it leaves my hands so I can actually take full ownership without spending tons of time figuring out what code is in what release.

FLYING BLIND - ACCESSIBILITY IN MONITORING, FEU MOUREK, Icinga

DevOpsDays Tel Aviv

Do you know what it feels like to navigate as someone who can’t distinguish between green and red - looking at those badges that tell you whether something is broken or a-okay? I’ll give you a quick look into what it feels like with some examples from the monitoring tool Icinga Web 2. We all tend to forget, that not everyone sees the world like we do. In this talk I’ll be walking you through different views in Icinga Web 2 with side-by-side comparisons for the default views and how different kinds of vision impairments affect those. The talks also features a few suggestions on how to improve colour schemes and making websites and webapps better to navigate with screen readers!

(Ignite) WHAT'S BURNING THROUGH YOUR CLOUD BILL - GIL BAHAT, CIDER SECURITY

DevOpsDays Tel Aviv

Recent years have exposed startups to a major plague - cloud overspend. No vaccine appears to exist, plethora of tools and consultants fail to stop the bleeding. And yet, some companies manage to stay safe. What makes them different? Is it the tools? Is it the mindset? Is it developer training? In this session we will examine the cultural factors involved in sound and responsible financial management in the cloud. We will also look at relevant system design elements and product design elements which enable us to spend wisely while our business runs smoothly. Following this session, you should be better versed in cost-aware system design and some of the cultural and structural requirements to keeping your cloud bill low.

SLO DRIVEN DEVELOPMENT, ALON NATIV, Tomorrow.io

DevOpsDays Tel Aviv

In every development process there is the question, do we invest enough on quality? Do we need to invest more? Every team knows about the dilemma of how many tests is the right amount of tests we should write. Is 80% test coverage is good enough? Maybe 90%? 100%? Should we invest more time in unit testing? Are we wasting too much time on unit-testing? Should we invest time on a faster rollback mechanism? WIIFM “Without data, you’re just another person with an opinion” - W. Edwards Deming SLO Driven Development is a framework that helps the developers focus on impact and balance of every aspect of the dev process. When working currently with SLI, SLA, SLO and error budget you can learn where to invest in the development process. Let’s talk about the importance of good SLOs and how they can help us improve our day2day

ONBOARDING IN LOCKDOWN, HILA FOX, Augury

DevOpsDays Tel Aviv

In this talk, I will share do's and don'ts on how to onboard successfully in a remote or hybrid setup including moving to a leadership role, speaking from my own journey onboarding remotely in the midst of a global pandemic. I will share the tips that worked for me for successful onboarding, how I was able to be productive, impactful, and make a good impression on others. The key issues as an “onbordee” that I will talk about are how to create relationships, make yourself visible in the company, time management, and more. Since I started working in Augury over 100 new employees have joined the company. Each month I give a session that is part of their general onboarding process. This became a crucial step due to the fact that we are now a hybrid company and a lot of people are onboarding remotely or in a hybrid setup for the first time in their lives. I joined the company as a backend developer and a few months into my role, the squad leader position in my squad was up for grabs and I was fortunate enough to grab it :) This is my first official leadership role, which I also needed to onboard into in a hybrid setup. I will share the process that I built for myself on “How to lead”. Also, a word or two on the process we built as a squad on how we work in a hybrid setup, what are we optimizing for when we do meet and how to include new members of the team.

DON'T PANIC: GETTING YOUR INFRASTRUCTURE DRIFT UNDER CONTROL, ERAN BIBI, Firefly

DevOpsDays Tel Aviv

In your ever-changing Infrastructure, some changes are intentional while others are not. Drift is what happens whenever the real-world state of your infrastructure differs from the state defined in your configuration. This can happen for many reasons, sometimes it happens when adding or removing resources, other times when changing resource definitions upon resource termination or failure, and even when changes have been made manually or via other automation tools. While Terraform itself can detect drifts, in most cases, you will be informed about it too late: just before you are about to deploy new changes to your infrastructure. What’s interesting about Terraform though, is that you can apply changes in two separate and distinct steps of “Planning” and “Applying”. This means that you have full visibility of what Terraform is planning on doing beforehand, and if you are satisfied with the changes, you can choose to apply them. So how does this work? When something is changed intentionally, it will appear in the source code, and the Terraform plan will not do anything. However, if any part of the infrastructure has been changed manually, Terraform’s plan will identify this, and alert you to the change. In other words, if your IaC drifted from its expected state, then Terraform’s plan will, in fact, detect it. Applying this simple solution can empower DevOps and developer velocity, with the reassurance and context for unexpected changes in your IaC, in near real-time. This talk will showcase real-world examples, and practical ways to apply this in your production environments while doing so safely and at the pace of your engineering cycles.

KEYNOTE | WHAT'S COMING IN THE NEXT 10 YEARS OF DEVOPS? // ELLEN CHISA, bolds...

DevOpsDays Tel Aviv

More from DevOpsDays Tel Aviv (20)