Alle Artikel mit dem Schlagwort “cloud

Kommentare 0

AWS:Summit 2019

Letzte Woche war in Berlin der AWS:Summit, die Hausmesse der Amazon‘s Cloud Tochter in Deutschland. Da mein Arbeitgeber dort einen Stand hatte, kombinierte ich Interesse und Standdienst und war vor Ort. Durch andere Verpflichtungen habe ich es nur an einem von zwei Tage geschafft, dieser war jedoch durchaus aufschlussreich.

Wenn man die Konferenz über die letzten Jahre verfolgt (die letzten vier Jahre war ich berufsbedingt nicht dabei), fällt vor allem das stetige Wachstum in allen Bereichen auf, mehr…

  • Sponsoren
  • Besucher
  • Vorträge
  • Startups
  • AWS Mitarbeiter (aus Deutschland)

Daraus folgt positives wie negatives. Man trifft zig alte Bekannte, ehemalige Kollegen, aktuelle und eventuell zukünftige Kollegen. Zudem sieht man ehemalige und aktuelle Kunden. Der Sehen und Gesehen werden Faktor ist nicht zu vernachlässigen – Networking ist das Stichwort hier. Der Veranstaltungsort am Gleisdreieck platzte aus allen Nähten. Die Toilettensituation war grenzwertig, die Verpflegung ließ massiv zu Wünschen übrig, der Kaffee war sowas wie braunes Wasser. Essen bekam man nur mit Glück und nur bedingt warm. Nicht umsonst machte das Gerücht die Runde, dass sich AWS nach einer anderen Location umsieht. Das ist nachvollziehbar, gleichzeitig aber auch schade, da dieser Vintage Look einen Teil des Charme des Events ausmacht.

Inhaltlich fand ich den ersten Tag ein wenig dünn. Die wenigen Vorträge, die ich besuchte waren entweder sehr high-level oder reines Marketing für AWS. Die einzige Ausnahme war ein Vortrag zur Datenmigration und den verschiedensten Optionen.

Die AWS eigenen Vorträge für den ersten Tag waren von vornherein als „Entry-Level“ klassifiziert, wodurch der fehlende Tiefgang zu entschuldigen ist. Was mich jedoch immer stört sind Kundenvorträge die sich rein auf das Abfeiern von AWS reduzieren. Wenn nur noch gesagt wird „how great this was“, „not possible without AWS“ fehlt mir dann doch meistens der Inhalt, was schlussendlich so besonders war, und wie etwas erreicht wurde.

Interessant waren auch die Kommentare der Konkurrenz. Während ein Mitarbeiter von Microsoft noch meinte, „man müsse ja sehen, was die Konkurrenz macht“, hörte man von RedHat/IBM, dass man nicht noch einen Stand buchen und „dem AWS Geld hinterherwirft“. Von den großen Infratrukturanbieter waren glaube ich nur NetApp da. Der führende Cloudanbieter frisst sich unaufhaltbar durch den Jurassic Park…

Funfact, die DJane im Eingangsbereich ließ die Teilnehmer ein paar mal zum Instrumental von GZUZ‘ CL500 den Kopf nicken.

Kommentare 0

Was man heute als IT‘ler lernen sollte

Letzte Monat habe ich mich ehemaligen Kollegen getroffen. Wie so üblich bei diesen Runden im Lahmen Esel, „Eselrunde“ genannt, wird neben dem üblichen Palaver auch über neueste Technologie, Erfahrungen im Job und ähnliches geredet. Nachdem ich nun drei Monate bei meinem Arbeitgeber The unbelievable Machine Company bin, habe ich von meinen Erfahrungen erzählt.

In dem Zuge haben wir diverse Aspekte des modernen Berufsleben diskutiert. Was machen Firmen heute, was machen Nicht-Telkos heute und wohin entwickelt sich wohl der Markt.

Meine zwei Empfehlungen kann ich wie folgt zusammenfassen:

  1. In einem wirklich agilem Umfeld arbeiten:

In vielen Unternehmen wird meines Erachtens pseudo-agil gearbeitet. Das bedeutet in der Regel, dass man sich gerne agiles Arbeiten und agile Methoden, sowie flache Hierarchien vorgaukelt. Am Ende zählt oftmals aber doch HIPO (Highest Individual Payed Opinion), also der mit dem höchsten Gehaltszettel hat Recht. Ich möchte das an dieser Stelle gar nicht schlecht reden, aber echtes agiles Arbeiten mit geteilter Kompetenz und Verantwortung lernt man so nicht. Und es reicht zudem auch nicht, mal ein JIRA Ticket geschrieben zu haben und schon mal ein Kanban Board gesehen zu haben. Es geht vielmehr darum die notwendige Diskussion konstruktiv führen zu können, das wirkliche Interesse an kontinuierlicher Verbesserung zu lernen – aktiv. Die sich ergebenen neuen Führungsmodelle und Modelle der Zusammenarbeit verinnerlichen.

  1. Mit einer der drei großen Clouds (aktiv) arbeiten:

Den Markt an Public Clouds teilen sich Amazon (AWS), Microsoft (Azure) und Google (GCP) untereinander auf. Es folgen mit Abstand „Nischen-Spieler“ und Dinosaurier, die alleine aus den Capex Skalen Effekten heraus nicht mit diesen dreien werden mithalten können – Alibaba nimmt aufgrund seiner politischen Protektion eine Sonderrolle ein.

Daher ist es so, dass aktuell jedes größere und mittelgroße Unternehmen eine Cloud Strategie hat. Ob das nun Cloud-First ist, oder Cloud-Experimente oder Cloud-Workloads für unwichtige Applikationen, so gut wie alle experimentieren mit den Cloud Plattformen. Nebenbei, unter Venture-Capital Geldgebern ist es „good-practice“ bei Pitchdecks zu schauen, ob die Gründer statt teurer Hardware nicht auf skalierende Pay-as-you-go Cloud Modelle setzen. Wenn man nicht wirklich gute Gründe hat das Investoren Geld in eigene Hardware zu versenken, sollte man heutzutage tunlichst nicht mit eigener Hardware den Unternehmensaufbau planen.

Kurzum, Public Clouds sind da und werden nicht mehr verschwinden. So dass es absolut notwendig ist, mit einer der drei Plattformen praktische Erfahrungen gesammelt zu haben. Ich schreibe bewusst praktische, denn es ist ein signifikanter Unterschied die Theorie oder die praktische Anwendung und das Cloud-Native Design und die veränderten Paradigmen zu kennen.
Gleichzeitig ist irrelevant für welche Plattform man sich entscheidet, alle drei werden bestehen. Sie sind vergleichbar, die Unterschiede beim Einstieg marginal. Einen schönen Vergleich gibt es hier.
Die meisten Unternehmen haben einen oder zwei („Multi-Cloud“ und No Vendor Lock In nennen sie das) der Anbieter in Benutzung. Es ist die Zeit gekommen, in dem IT Ressourcen wirklich wie aus der Steckdose konsumiert werden. In dem Bilde muss sich der IT-Pro von heute und morgen aber mit Strom und seinen Varianten auskennen.

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

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.