Kommentare 0

Chaos Engineering – das Impfen unter den Operations Modellen

Vor ein paar Wochen stellte ich fest, dass mein Impfschutz gegen Tetanus vor 21 Jahren abgelaufen war. Das war dann in der Tat notwendig. Wikipedia definiert den Begriff einer Impfung wie folgt:

Eine Impfung, auch Schutzimpfung oder Vakzination (ursprünglich die Infektion mit Kuhpockenmaterial; von lateinisch vacca, ‚Kuh‘) genannt, ist die Gabe eines Impfstoffes mit dem Ziel, vor einer (übertragbaren) Krankheit zu schützen. Sie dient der Aktivierung des Immunsystems gegen spezifische Stoffe. Impfungen wurden als vorbeugende Maßnahme gegen Infektionskrankheiten entwickelt.

Das past zu einer Analogie, die ich im Cloudcast #299 gehört hatte. Dort ging es um die Disziplin des Chaos Engineerings, einem Betriebsmodell bei dem es darum geht, dass (verteilte) IT-Systeme niemals perfekt sind. Vielmehr ist die These sogar, dass sie verwundbar sind und eher die Frage berechtigt ist, wem diese Verwundbarkeit zuerst auffällt. Dem dafür verantwortlichen Betreiber oder jemand externem.1
Der Begriff Chaos Engineering leitet sich am ehesten von einem Modell, dass bei Netflix angewandt wird ab. Dort wurde vor Jahren ein Tool namens Chaos Monkey genutzt (und für Jedermann veröffentlicht), welches zufällig bestimmte Komponenten eines Systems bewusst im laufenden Betrieb zum Absturz bringt. Damit kann dann validiert werden, on das System als Ganzes wirklich hinreichend ausfallsicher ausgelegt ist.
Die Denke ist, Fehler werden passieren, die Frage ist nur wann. Und wie sehr kann ich den „Impact“ durch diesen Fehler im Falle minimieren.
Hier kommt die Analogie zur Impfung ins Spiel. Damit mein Immunsystem zur Abwehr gegen bestimmte Stoffe aktiviert wird, muss ich es zunächst einer kleinen Menge eben dieses Stoffes aussetzen.

Was sind die Prinzipien des Chaos Engineerings?

Hierzu bietet die eigens von Afficionados angelegte Seite PRINCIPLES OF CHAOS ENGINEERING eine gute Definition:

Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.

Selbst wenn alle einzelnen Systeme einer verteilten Umgebung voll funktionstüchtig sind, kann es dennoch zu einer Nutzerbetreffenden Einschränkung kommen. Eben diese impliziten Abhängigkeiten sind in großen Systeme oftmals nur nach einer Störung herauszufinden (dran Denken, Lessons Learned nach einem Incident). Will man hier etwas „proaktiver“ Vorgehen, ist das Modell des Chaos Engineerings prädestiniert:

  1. Definiere den ‚steady state’, am besten in einer messbaren Form, aus dem das zu erwartende normale Verhalten Deines Systems hervorgeht. Wichtig ist hier meines Erachtens der Aspekt des messbaren. Das kann bei einer Webseite die Antwortzeit auf bestimmte Anfragen sein, am besten auf Anfragen, die eine Vielzahl von Backend-Services mit einbezieht.
  2. Stelle die Hypothese auf, dass sowohl die Kontrollgruppe, als auch die experimentelle Gruppe sich gleich verhalten werden.
  3. Definiere Variablen, die ein echtes Verhalten darstellen, wie denkbare Anzahl von abgestürzten Servern, reduzierter oder limitierter Netzwerkbandbreite, usw.
  4. Vergleiche die Experimentier und die Kontrollgruppe kontinuierlich. D.h. starte durchgängig Experimente, die durch die Veränderung der definierten Variablen geprägt sind.

Die Fortgeschrittenen führen die Experimente direkt in der Produktion aus. Naheliegend fängt man mit einem reduziertem Radius an und vergrößert diesen immer weiter. Im Idealfall ist das gesamte System eingebunden. Mir ist zudem immer wichtig, dass man die dennoch auftretenden Incidents und im wiederholten Falle Problems (nach ITIL Sprache) als Input für die Testfälle/Variablen hernimmt.

  1. Extern muss nicht limitiert sein auf einen externen „Angreifer“ im Security Sinne. Es kann sich dabei einfach um einen operationsfremden und zu spät erkannten Incident handeln.
Kommentare 0

Lesenswert KW31

7 Interesting Parallels Between the Invention of Tiny Satellites and Cloud Computing  – High Scalability –
ImageNet: the data that spawned the current AI boom — Quartz
Corporations in the Age of Inequality
How We Built a Virtual Scheduling Assistant at Microsoft
When Moore’s Law Met AI – Artificial Intelligence and the Future of Computing – Medium
Japan battles population decline with robots – CBS News
Facebook builds natural language processing into Messenger | VentureBeat | Bots | by Khari Johnson
Google launches its own AI Studio to foster machine intelligence startups | TechCrunch
A practical explanation of a Naive Bayes classifier | MonkeyLearn Blog
Hackers break into voting machines in minutes at hacking competition | TheHill
Unlock | The Daily | L2

Kommentare 0

Die Verfügbarkeits Pyramide – oder wie man zu hoch verfügbaren Services kommt – Teil 2

Im vorhergehenden Post zum Thema Verfügbarkeits Pyramide beschrieb ich die ersten drei Ebenen. Nun zu den weiteren.
Ebene vier, wenn man die ersten Drei „im Griff“ hat, ist ein ordentliches Testkonzept und gesetzte Release Verfahren. Ein gutes Zitat zur Frage wie weit man Testaufwände treiben sollte, geht wie folgt:

„If you haven’t tried it, assume it’s broken.“

(Autor unbekannt)
Dem folgend gilt also alles als kaputt, solange nicht das Gegenteil nachweisbar ist. Das ist eine vielerorts untypische Vorgehensweise. Ist es doch traditionell so, dass man in ein System eindringt, oder ein Fehlverhalten auftrat. Folgt man der oben angeführten Haltung, geht man davon aus, dass bis zum Bestehen eines negativen Tests ein System als unbekannt gilt.
In der Softwareentwicklung gebt es dazu den Ansatz der Testgetriebenen Entwicklung. Dabei werden die Testfälle vor der Entwicklung der eigentlichen funktionalen Komponenten geschrieben. Nach dem Paradigma des Site Reliability Engineerings https://landing.google.com/sre/book/chapters/testing-reliability.html wird davon ausgegangen, dass man durch fundiertes und professionelles Testing die MTTR (Mean-Time-To-Repair) reduzieren und damit die MTBF (Mean-Time-Between-Failures) steigern kann:

It’s possible for a testing system to identify a bug with zero MTTR. Zero MTTR occurs when a system-level test is applied to a subsystem, and that test detects the exact same problem that monitoring would detect. Such a test enables the push to be blocked so the bug never reaches production (though it still needs to be repaired in the source code). Repairing zero MTTR bugs by blocking a push is both quick and convenient. The more bugs you can find with zero MTTR, the higher the Mean Time Between Failures (MTBF) experienced by your users.

Klassisch gibt es drei Testtypen:

  • Unit Tests, zum Testing einzelner Komponenten
  • Integrationstests, zum Testen der Komponenten im Verbund
  • Systemtests, zum Testen ganzer Umgebungen unter Simulation bestimmter Thesen (wie z.B. „Kann 10.000 User Sessions standhalten“)

Als nächster Aspekt der Pyramide wird das Capacity Planning angesehen. Also der kontrollierte Umgang mit der vorhandenen und basierend auf Trends oder Annahmen benötigten Kapazität. Bei eigenen Installationen („On-Premise“) sind hier in der Regel auch Investitionsplanungen und Entscheidungen abhängig. Aber auch beim Einsatz von Cloud Service Providern gilt es diese Disziplin sachgerecht durchzuführen. Denn man möchte/muss die etwaigen Ressourcen bei Zeiten verfügbar haben (Spin-up, Konfiguration laden, Applikation ausrollen, etc.).
Die letzten beiden Punkte der Pyramide würde ich tendenziell zusammenfassen: Development und Product.
Es ist essentiell, dass die Produktentwicklung von vornherein Skalierung vorsieht. Dazu benötigt es die richtigen Komponenten, wie Analyse Tools. Aber auch einen passenden Produktstart, wie zum Beispiel eine Einführung in Phasen („Beta“, Closed User Group, usw.). Bei Google haben sie auch dafür eine eigene Rolle, die des Launch Coordination Engineers. Diese kümmern sich um die korrekte Bearbeitung der Lauch Coordination Checklist.

Kommentare 0

Lesenswert KW 30

Amazon’s New Customer – Stratechery by Ben Thompson
ipSpace.net: Automation or Orchestration?
ipSpace.net: Swimlanes, Read-Write Transactions and Session State
ipSpace.net: Sample Network Automation Ansible Playbooks
Get eyes in the sky with your Raspberry Pi
Learn Kubernetes behind a corporate proxy
Build a budget IoT Grow-box with your Raspberry Pi
HBR: The Business of Artificial Intelligence
NYT: Beijing Wants A.I. to Be Made in China by 2030
Is Anyone Home? A Way to Find Out If AI Has Become Self-Aware
Techcrunch: Why the future of deep learning depends on finding good data

Kommentare 0

Lesenswert KW29

Der erste Eintrag ist eher hörenswert. Vom Digital Kompakt Podcast, 40 min über B2B Sales. Was sollte ein Vertriebler machen und was nicht.
Die fünf goldenen Regeln des B2B-Sales | The Art of Sales #6
‘Chinafrica’ is a macro megatrend set to impact everything from Silicon Valley to Wall Street | TechCrunch
Crypto-tulips
You’ll Never Expect Which Generation Has the Most Freelancers Today
Sesame Workshop and IBM team up to test a new A.I.-powered teaching method | TechCrunch
How AWS Cloud is demolishing the cult of youth – James Governor’s Monkchips
An introduction to model ensembling – weights and biases – Medium
Google wants to make sure AI advances don’t leave anyone behind – The Verge

Kommentare 0

Lesenswert KW28

Why Artificial Intelligence is Different from Previous Technology Waves
Facebook, for the first time, acknowledges election manipulation – CBS News
Without saying the words „Russia,“ „Hillary Clinton,“ or „Donald Trump,“ Facebook acknowledged Thursday for the first time what others have been saying for months.
AI Progress Measurement | Electronic Frontier Foundation
When the automatons explode – MIT Sloan School of Management
How AI detectives are cracking open the black box of deep learning | Science | AAAS
Where Machine Learning meets rule-based verification – The Foretellix Blog
Mesosphere-Chef Florian Leibert: Der Bill Gates des Cloud-Computings | ❤ t3n

Kommentare 0

Warum benötigt man ein Service Mesh bei einem Cloud Deployment

Im Cloudcast #298 wurde Linkerd vorgestellt. Linkerd (gesprochen linker-dee) ist ein Service Proxy, der dazu dient die Kommunikation zwischen lose gekoppelten System oder Microservices zu orchestrieren. Früher nannte man sowas manchmal auch ESB (Enterprise Service Bus).
Der Unterschied zu den ehemaligen SOA (Service Oriented Architecture) Ansätzen der Nuller Jahre, wo man in der Regeln versucht hat statische Systeme miteinander zu koppeln folgt der Ansatz des Service Mesh der Annahme moderner Cloud Paradigmen wonach die Services unstet sind. Das bedeutet sind sind in Teilen verfügbar, werde teilweise aufskaliert („Autoscale“), oder abgebaut bei weniger Last. Im Idealfall orchestriert sich das System selbst, sei es nun gesteuert durch entsprechende Container-Manager wir Kubernetes oder Docker Swarm oder durch andere Mechanismen.
Das Konzept eines Service Mesh dient nun dazu entsprechende Inter-Service-Requests zu gewährleisten und zu steuern.

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. (But there are variations to this idea, as we’ll see.)
The concept of the service mesh as a separate layer is tied to the rise of the cloud native application. In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state as they are dynamically scheduled by an orchestrator like Kubernetes. Not only is service communication in this world incredibly complex, it’s a pervasive and fundamental part of runtime behavior. Managing it is vital to ensuring end-to-end performance and reliability.

Da setzt linkerd nun an. Aus ehemaligen twitter Produktleuten und hinreichend mit VC Kapital ausgestattet, ist es sicherlich kein komplett neues Konzept.

The service mesh is ultimately not an introduction of new functionality, but rather a shift in where functionality is located. Web applications have always had to manage the complexity of service communication. The origins of the service mesh model can be traced in the evolution of these applications over the past decade and a half.
Consider the typical architecture of a medium-sized web application in the 2000’s: the three-tiered app. In this model, application logic, web serving logic, and storage logic are each a separate layer. The communication between layers, while complex, is limited in scope—there are only two hops, after all. There is no “mesh”, but there is communication logic between hops, handled within the code of each layer.


Inter-Service Kommunikation, load-balancing, latency-assurance, all diese Features können durch ein Service Mesh unterstützt werden. Die Plugin Architektur von linkerd finde ich am reizvollsten, da hierdurch sogar einfache Protokollumsetzungen möglich sind.
linkerd ist seit neuem auch Teil der CNCF.

Kommentare 0

Lesenswert KW 23

Marketing mit Gesichtserkennung: Eine Pizzeria in Oslo filmt Kunden

Eigentlich wollte sich Jeff Newman in einem Einkaufszentrum in Oslo nur eine Werbung für eine Pizzeria anschauen. Doch plötzlich zeigte der Bildschirm eine lange Reihe von Buchstaben und Zeilen. Der IT’ler erkannte schnell: Die Pizzeria hatte über eine Kamera Informationen wie Alter, Geschlecht und sogar Stimmung über ihn und andere gesammelt, die sich die Werbung angeschaut hatten.

Modeling Spelling Correction for Search at Etsy – Code as Craft

When a user searches for an item on Etsy, they don’t always type what they mean. Sometimes they type the query jewlery when they’re looking for jewelry; sometimes they just accidentally hit an extra key and type dresss instead of dress. To make their online shopping experience successful, we need to identify and fix these mistakes, and display search results for the canonical spelling of the actual intended query. With this motivation in mind, and through the efforts of the Data Science, Linguistic Tools, and the Search Infrastructure teams, we overhauled the way we do spelling correction at Etsy late last year.

Nati Shalom’s Blog: The End of Cloud Management As We Know It – Part 1

The numbers speak for themselves, and the conclusion is unavoidable: the tools we’ve used to manage cloud in the early stages of its growth are no longer sufficient for an agile, responsive world in which business unit developers and central IT are moving faster and covering larger and more complex application portfolios than ever before.

Streaming-Dienst: Wird Spotify den eigenen Erfolg überleben? – manager magazin – Nachrichten – Unternehmen
Collecting huge amounts of data with WhatsApp – Loran Kloeze
Google to Sell New AI Supercomputer Chip Via Cloud Business

Companies will be able to purchase the hardware, called Cloud Tensor Processing Units (TPUs), through a Google Cloud service. Google hopes it will quicken the pace of AI advancements. And despite official statements to the contrary, it may also threaten Intel Corp. and Nvidia Corp., the main suppliers of powerful semiconductors that run large processing tasks.

Google bietet Supercomputer Power für den Rest von uns an. Mich interessiert das Kleingedruckte, wem gehören die Daten und die trainierten Netze…?
Facebook’s Data Center Powerhouse Spawns another Startup

Over the last six or seven years, Facebook has become one of the handful of companies whose scale means they’ve had to innovate at every level of data center infrastructure, pushing the envelope in data center and hardware design further than most data center vendors and their customers as a result.

The Evolution of Container Usage at Netflix

This month marks two major milestones for containers at Netflix. First, we have achieved a new level of scale, crossing one million containers launched per week. Second, Titus now supports services that are part of our streaming service customer experience. We will dive deeper into what we have done with Docker containers as well as what makes our container runtime unique.

Netflix Container Ansatz – immer eine Lesung Wert…

Kommentare 1

Die Verfügbarkeits Pyramide – oder wie man zu hoch verfügbaren Services kommt

 
Im Jahr 2017 werden (digitale) Produkte oder Services wahrscheinlich komplett oder weitgehend auf Basis von Cloud Services konzipiert. Mindestens jedoch greifen sie in Teilen auf Cloud Services zurück. Daher ist es essentiell einen sauberen Überblick über deren Zustand zu gewährleisten.
Im Zuge des SRE (Site Reliability Engineering) Ansatzes von Google gibt es dazu ein Modell, was die notwendigsten Disziplinen strukturiert, die Site Reliability Hierachy:

sre-pyramide

Service Reliability Hierarchy by https://landing.google.com/sre/book/chapters/part3.html


An der Bedürfnispyramide von Maslow orientiert, bietet diese Pyramide eine gute Struktur zur Orientierung beim Betrieb eines Produktes/Service.
Der eigentliche „No-Brainer“ ist die erste Stufe: Monitoring. Es sollte klar sein, dass ohne ein ordentlich implementiertes Monitoring der Betrieb de-facto im Blindflug läuft.

Without monitoring, you have no way to tell whether the service is even working; absent a thoughtfully designed monitoring infrastructure, you’re flying blind. Maybe everyone who tries to use the website gets an error, maybe not—but you want to be aware of problems before your users notice them.

Die gute Nachricht, die Implementierung ist heutzutage ein Kinderspiel. Alleine in der Cloud Native Landscape tummeln sich zahlreiche neue und alte Vertreter. Es gibt keine Ausreden für ein mangelhaftes Monitoring.

CloudNativeLandscape_v0.9.4

https://github.com/cncf/landscape


Eine Ebene darüber ist die Incident Response angesiedelt, also der aktive Umgang mit Störungen („Incidents“). Nach klassischem ITIL bedeutet das umgehende Lösung, im Zweifel mittels Work-Around (Reboot tut gut). Im Rahmen eines Incidents muss nicht zwingend eine finale Lösung implementiert werden. Wichtig ist, die geordnete Wiederherstellung der eigentlichen Funktion. Meiner Meinung nach sollten Incidents auch immer sinnvoll strukturiert aufgezeichnet werden. Also sinnvolle Datenbanken führen, aus denen man Statistiken ziehen und Analysen fahren kann:

  • Welche (wiederkehrende) Muster kann man erkennen?
  • Wo treten Probleme auf?
  • Was kann ich daraus ableiten?

Nahtlos reiht sich dann die nächste Ebene ein, Post Mortem und Root Cause Analyse. In der ITIL Welt ist das oftmals auch Teil der Problem Management Disziplin. Im Kern geht es darum einerseits zu lernen was schief gelaufen ist und andererseits proaktiv in der Zukunft die Art Fehler zu vermeiden.
Ein solides Port-Mortem hört sich leichter an, als es ist. Sehr schnell entwickelt sich hier eine Blaming Kultur. Das wichtigste ist „sachlich bleiben“:

Best Practice: Avoid Blame and Keep It Constructive

Blameless postmortems can be challenging to write, because the postmortem format clearly identifies the actions that led to the incident. Removing blame from a postmortem gives people the confidence to escalate issues without fear. It is also important not to stigmatize frequent production of postmortems by a person or team. An atmosphere of blame risks creating a culture in which incidents and issues are swept under the rug, leading to greater risk for the organization

Mehr zu den anderen Ebenen in einem zukünftigen Post…

Kommentare 0

Cassette App – Was AI aus der Cloud möglich macht

Vor einigen Wochen machte die iOS App Cassette auf sich aufmerksam. Eine toll gestaltete App von Designern, die auf (Live) Transkription von gesprochener Sprache ausgelegt ist. Die App gibt es im ersten Schritt nur für die iOS Plattform, was aufgrund der primären Zielgruppe Designer und Gestalter naheliegt. Das Ganze ist zudem ein Spin-off der Stanford d.school.
Die Qualität der Ergebnisse ist recht gut. Wie erreicht aber solch ein Indie Entwickler Team aus dem Quasi-Nichts solch eine gute Spracherkennung?
Relativ simpel, indem das Unternehmen auf entsprechende Cloud-APIs setzt und entsprechende Plattformen im Hintergrund nutzt.
Konkret setzt Cassette auf den Speech Toolstack von IBM Watson . Damit ist die App ein Paradebeispiel für eine neue Möglichkeit Produkte und Lösungen zu denken. Dank der breiten Verfügbarkeit von entsprechenden AI APIs kann man mit geringen Entwicklungsaufwänden kleine Produkte/Apps mit echtem Mehrwert schaffen.
Kommerziell gesehen dürfte sich der Ansatz zudem sehr gut lohnen.
Neben den kostenlosen 30 Minuten Transkription zum probieren gibt es noch drei Zeitbegrenzte Pakete.

Cassette Pricing

Cassette Pricing


Stellt man dem das Pricing „im Einkauf“ bei IBM entgegen, so sieht man die gesunde Marge des Service:

  • 3 Stunden zu 3,6$ (Verkaufspreis 10$)
  • 10 Stunden zu 12$ (Verkaufspreis 25$)
  • 50 Stunden zu 60$ (Verkaufspreis 100$)

Desweiteren spielt es Cassette in die Hand, dass die Verkaufspreise im Rahmen einer Subskription garantiert sind, währenddessen Kunden ggf. weniger als die maximale Menge der Transkription nutzen.
In der Zukunft ist davon auszugehen, dass sie weitere Watson Services wie wahrscheinlich den Natural Language Classifier einbinden werden.

Deeper insights through empathy
Collaboratively prepare conversation questions and hone strategy ahead of time with Guides.
One-tap question choices to get you started – handpicked by experts in Design Thinking from the Stanford d.school.

Alternativ zu Watson prüft das Cassette Team auf Rückfrage in losen Abständen die Qualität der Alternativen (wie zum Beispiel aws Polly oder Lex), setzt aber bis auf weiteres auf Watson als AI Plattform.