Virtualisation and Devops Day 2018

2018. november 8.

Mi az a VDay?

https://vday.hu/

• ingyenes egész napos konferencia
   
• alulbecsült
   
• érdekes előadások
   
• Témák általában:
  • Virtualization
  • DevOps
  • Cloud
  • Microservices
  • Scalability
  • Docker
  • Data Centers
  • IoT

Mit adott nekünk
az Azure?

Kocsis Attila
Cloud Solution Architect
@ Microsoft

Microsoft
❤️
Open Source

• CEO-k 40%-a szerint open source-nak
  stratégia helye van a cégben
   
• fejlesztők több mint 60% elvárja hogy
  OSS-t a szolgáltatás részévé tegye
   
• nagyvállalatok 90%-a valamilyen formában használ OSS-t.

Miért?

2014. Satya - Microsoft Loves Linux

2015. VSCode
 

2016. NodJS alapítvány, Linux Subsystem, Linux
           alapítványhoz csatlakozik

2017. Kubernetes service, MySQL és PostgreSQL Azure

2018. GitHub, Service Fabric, Azure Sphere (IoT, Linux
           alapú), Azure workload több mint 50%-a Linuxon fut.

           Github aktivitása ugyanígy nő

Microsoft vs Linux history

OSS szoftverek

• R
• TypeScript
• PowerShell
• Linux kontributor
• Azure-ban open source

Azure Service Fabric

• Microservice-ek és containerek csomagolása, skálázása, managelése
   
• 10 éve fejlesztik, 20 saját szolgáltatás mögött ez van.
   
• https://github.com/Microsoft/service-fabric

Aktív OSS részvétel

• .NET core közösség
   
• Open Invention Network -
  patent trolloktól védi az Open Source megoldásokat
   
• 60 ezer szabadalmat tett elérhetővé ennek keretében

Demo

• Azure-ban felhúzott egy web appot és egy PostgreSQL-t
   
• Integrált monitoring
   
• Fejlesztőnek jó aki nem akar vagy nem tud foglalkozni az infrastruktúrával, mégis tud produktív lenni.

Azure DevOps

from code to production

Osvay Soma
@ Starschema
 

• Azure Pipelines
   
• Azure Artifacts
  dependenciák kezelése (pl. npm)
   
• Azure Repos
  git repo, opcionális
   
• Azure Board
   
• Azure Test Plans
  manuális tesztek, load testing

Service-ek

Demo

Sources
 

Build pipelines
 

Build artifacts (Docker image)
 

Release pipelines
 

Production environment

How to build a
cloud-native application

Pásztor János
@ Exoscale

Cloud Native?

• Microservices

• CI/CD

• Containers

• Kubernetes

• Infrastructure as code

Cloud native apps

• take advantage

• deal with the unknowns

of the cloud.

Problémák

• network level problems
  • bandwith (cephfs)
  • latency
     
• hardware problems
  • things will fail
     
• virtualization problems
  • neighbours
  • even filesystem
    (PHP session file lock)

It's OK not to be
cloud-native.

It costs more.

CAP theorem

MySQL megoldás példák:

• quorum
  can write only if db is part of cluster
   
• master-slave
  not guaranteed consistency

Immutable servers

• no problem with old configuration files
   
• do it frequently!
   
• Example: Ansible -> deploy --> cloud init --> node
   
• Autoscaling
   
• Where is your data?

Summary

• it's a way of thinking!
   

• any machine can fail any time.
  restart servers, do it often
   

• handle failures gracefully!
   

• allow for running more than one copy of the application

Fog and Edge
computing
and how to tame
the Industrial
IoT world

Gulyás Máté

@ Data Pao

Actual big data

200 ms / 32 byte * 200 sensors * 20 measurements
= 20 Tb / year

Small factory in Hungary.

Problems

• Latency, 100-200ms oda-vissza
   

• Heterogenous environments
  (Docker helps)
   

• Organisational challenges
   

• Modeling rare events:
  one failure in one year

Solutions

• Predictive maintenance
   

• FOG computing

   

• EDGE computing
   

• Docker
   

• Baby steps
   

• Educating the user

Predictive maintenance

• Tell the problem before the failure
   
• RUL: remaining useful lifecycle
   
• machine learning model for RUL

FOG computing

servers in the factory

EDGE computing

• 15ms latency from the factory
   
• aggregate and clean, buffer the data there
   
• push to the cloud later
   
• 50ms total (to the cloud)
   
• Cisco industrial router, can run Docker

DevTestOps;
Testing és Monitoring
a DevOps
kultúrában

Szombath István

@ evosoft

Kinek a feladata a QA?

• Mindenkinek.
   
• Fejlesztőket fel kell készíteni hogy a QA-t biztosítsák.

"Mikor hagyjuk abba a tesztelést?"

"Amikor elfogy a pénz
vagy az idő."

Módszerek

• Shift left:
  ha valamit tudunk korábban tesztelni,
  azt hozzuk előre
   
• Shift right:
  staging vagy prod rendszerben tesztelünk,
  de nagyon gyorsan tudunk reagálni a problémákra

• Cloud testing:
  nagyon költséges lehet
   
• Metrics with business impact:
  Biztos minden metrikát meg kell nézni?

Mire figyeljünk?

Automation, integration, Red Hat

Végh Károly

@ Red Hat

• Red Hat csak és kizárólag
  Open Source termékekből profitál
   
• Fortune 500 cégek 90%-a Red Hat-ot használ
   
• 2 milliárd dolláros bevétel
   
• platform cég
   
• nincs saját intellectual property-je,
  kizárólag upstream

Fun facts

IBM acquisition

Cél: ők akarnak lenni a hybrid cloud mestere.
Nézet, technológia, tapasztalat.

• container platformok

• multi / hybrid cloud

• data portability

• automation

IBM 34 milliárd dollárért megvette, valaha legnagyobb eladott szoftvercég.

Termékek

• Minden terméknek van upstream verziója
   
• Kód szinten megegyezik az upstreammel
   
• update, security fixek, training, garancia
   
• Az ügyfél NEM terméket vásárol

Termék kategóriák

• szolgáltatások
   

• application services
   

• container platform
   

• infrastruktúra
   

• security and services (pl. insights, ansible)

Use case-ek

• Hyperconverged infrastructure
   
• Container platforms
   
• LifeCycle management
   
• Hybrid / multi cloud management

How to make technical decisions

Oresztesz Margaritisz

@ EPAM

Examples

• docker swarm vs Kubernetes
   

• Graphite vs Prometheus
   

• MongoDB vs MySQL
   

• implement vs reuse

Cost of a bad decision

• sticky
   

• cognitive noise
   

• technical debt
   

• accidental complexity

Good technical decisions

• The opposite of bad decision,
  just solves the right problem
  like a puzzle piece.
   
• Four dimensions:
  • learning curve
  • runtime
  • support
  • design

Learning curve

• quality documentation
   

• usability
   

• fast feedback
   

• team expertise

Runtime

• feature richness
   

• technical constraints
  (integrate with other services)
   

• no Single Point of Failure
   

• stability
   

• security
   

• performance

Support

• logging
   

• debugging
   

• monitoring
   

• exceptions
   

• no snowflakes (unique service,
  irreproducible in the staging area)
   

• testing

Design

• API
   

• maturity
   

• feature richness
   

• interfacing (replaceable)
   

• simplicity

How to measure

• Google Trends
• GitHut
• Stackoverflow insights
  (number of answers)
• Code Analysis tools
• Stability: Github stats
• Performance: Benchmarks Game

Decision making

• Group can be smarter / dumber sometimes it's better to make individual decisions
   

• use your intuition
   

• Remember: breadth-first you won't have time to all those choices
   

• Be CALM & COLLABORATIVE

Recipe

1. Get away from computers

2. Pick 4-7 metrics

3. Brainstorm --> alternatives

4. Collect measures

5. Rate 1-5 ⭐️

6. Disagreement --> LEAN

Summary

• How > What
   
• Technology is not the most important.

From test drive to production: adopting Kubernetes to build an enterprise appliance firmware

Vau
@ Balabit

• More people can leverage Kubernetes
  than big data
   
• Rancher 2.0
   
• 3-node cluster in <1day!
   
• reused SaltStack
   
• no AD groups, you can only authenticate

Kubernetes,
deployment

Production grade?

• automated deployments
   
• tested throughly
   
• documentation, playbooks
   
• What is it NOT?
   
• not good for advanced networking