Uncategorised

Cloud 4 You

Wir bringen Ihre Anwendungen in die Cloud

Sie wollen auch die Vorteile der Cloud nutzen, wissen aber nicht genau wie? Und was sich denn nun eigentlich hinter dem ganzen "Cloud-Hype" verbirgt?

Dann sind Sie hier richtig gelandet! Wir machen seit Jahren Beratung zum Thema Cloud Technologien und unsere Kunden profitieren davon schon heute.

Was ist denn nun eigentlich diese "Cloud"?

Nun, hier muss man zunächst zwischen verschiedenen Ausprägungen der Cloud unterscheiden. Die bekannteste ist sicher die

PUBLIC CLOUD

Dahinter verbergen sich Server verschiedener Anbieter auf denen Sie Ihre Daten und Applikationen ablegen können. Die bekanntesten sind sicher DropBox oder Amazon AWS. Das Problem hierbei ist aber, dass Ihre Daten auf irgendwelchen Servern in den USA gespeichert werden, was nach dem Abhörskandal um die NSA sicher viele Firmen davon abhält, diese Dienste kommerziell zu nutzen, da sie sich nicht mehr sicher sein können wer alles Zugriff auf ihre Daten hat.

Deshalb wollen immer mehr Firmen die Vorteile der Cloud nutzen, die Daten aber im eigenen Haus halten. Sie wollen also eine

PRIVATE CLOUD

Eine Private Cloud bedeutet dass alle Daten im eigenen Rechenzentrum auf eigenen Servern untergebracht sind, man aber die Vorteile der Cloud, nämlich Skalierbarkeit von Diensten und einfachen und günstigen Datenspeicher und skalierbare Computing Dienste bekommt.

Die momentan marktführende Lösung für solche Private Clouds basiert auf der Software OpenStack.

Wie hier zu sehen ist besteht OpenStack aus drei Grundkomponenten:

  • Compute
  • Networking
  • Storage

COMPUTE

Der Bereich Compute ist für die meisten Installationen der wichtigste. Hierunter verbirgt sich der Virtualisierungslayer mit dessen Hilfe die virtuellen Maschinen abgebildet werden.

OpenStack kann eine große Anzahl an Hypervisoren zur Virtualisierung von Rechnern verwenden:

  • XenServer/XCP
  • KVM
  • QEMU
  • LXC (Linux Container)
  • XEN
  • VMware
  • Hyper-V
  • Docker
  • PowerKVM
  • z/VM

Wenn Sie also in Ihrer EDV bisher eine oder mehrere dieser Virtualisierungslösungen verwendet haben, können Sie diese mit Hilfe von OpenStack in einem Produkt unter einer Administrationsoberfläche konsolidieren. Und natürlich Ihren zentralen Objekt- oder Block-Speicher für alle diese Hypervisoren nutzen.

STORAGE

OpenStack unterstützt generell zwei Arten von Storage:

  • Block Speicher
  • Objekt Speicher

Block Speicher wird von den virtuellen Maschinen so genutzt wie formatierte Festplatten. OpenStack bietet hier die Möglichkeit normalen nichtredundanten Block Speicher zu nutzen, oder auch redundanten wie z.B. CEPH. Block Speicher eignet sich für schnell und oft ändernde Daten.

Objekt Speicher ist per Definition redundant und wird auf billigen Festplatten ohne RAID realisiert. Die Redundanz ergibt sich aus der verteilten Speicherung über mehrere Rechner hinweg. Objekt Speicher wird für die Speicherung großer Datenmengen benutzt die sich nicht oft ändern, wie z.B. Betriebssystem Images, Datensicherungen oder archivierte Daten. DropBox-ähnliche Dienste basieren auf dieser Technologie.

NETWORKING

Damit die verschiedenen virtuellen Maschinen miteinander, der Außenwelt und dem Speicher kommunizieren können ist ein Netzwek-Layer notwendig. Dieser wird durch die Networking Komponente von OpenStack abgebildet. OpenStack bietet hier Netzwerkkommunikation auf Layer 2 und 3 des OSI Modelles an und stellt Plugins für die native Unterstützung von Netzwerkequipment diverser Hersteller bereit.

HYBRID CLOUD

Wie man sich denken kann besteht eine Hybrid Cloud aus einer Mischform von Public und Private Cloud. Eine Hybrid Cloud kann z.B. Sinn machen wenn man für die schützenswerten Daten nur interne Server in der Private Cloud nutzen will, für Massendaten die nicht schützenswert sind oder aber separat verschlüsselt auf kostengünstige Dienste von Amazon, Google oder anderen Public Cloud Anbietern zurückgreifen will.

 

Egal ob Sie damit Ihre Produktions- oder Testumgebung flexibilisieren wollen, oder vielleicht schnell eine Big-Data Lösung implementieren, unsere Cloud-Lösungen sind auf Ihren Bedarf zugeschnitten und schnell und zuverlässig realisiert.

Wir realisieren für Sie Cloudlösungen von 1 bis über 1000 Servern auf Basis von OpenStack.

 

Kontaktieren Sie uns per E-Mail und erfahren Sie mehr !  E-Mail: bmueller [at] adartis.de

Kubernetes

Kubernetes ist die weitaus gebräuchlichste Plattform um Docker Container zu orchestrieren und laufen zu lassen.

Wenn Sie mit Microservices arbeiten wollen und diese in Docker Container packen brauchen Sie eine Umgebung um diese auszuführen. Kubernetes, das von Google entwickelt wurde, ist die beste Plattform dafür. Mittels Kubernetes können Container deployed und skaliert werden. Es findet ein automatisches Loadbalancing innerhalb des Kubernetes Clusters statt und mittels sogenannter Ingress Controller braucht man nur einen einzigen Loadbalancer vor dem Kubernetes Cluster. Die einzelnen Anwendungen innerhalb des Clusters werden dann mittels voll qualifizierten DNS Namen angesprochen.

Für Kubernetes gibt es auch ein eigenes Package Management namens HELM. Mittels Helm können containerbasierte Anwendungen in den Kubernetes Cluster eingespielt und wieder entfernt werden wie man das auf Linux Seite von apt oder yum kennt. Dies allein ist schon ein Grund Kubernetes zu benutzen.

Es gibt aber noch eine Reihe weiterer Vorteile. Für Kubernetes gibt es eine Reihe von Zusatztools, wie z.B. Istio, ein Service Mesh. Dies bedeutet dass mittels Istio in jeden Pod ein Sidecar Container injiziert werden kann, der die Möglichkeiten von Kubernetes erweitert. So kann damit z.B. ermöglicht werden mehrere Versionen von Pods und Containern einer Software nebeneinander laufen zu lassen und den Traffic prozentual auf die Versionen zu verteilen. Damit sind also neben rolling Upgrades auf Blue Green Deployments und Canary Upgrades möglich.

Eine weiter Möglichkeit ist es unter Kubernetes quasi "Serverless Computing" oder auch Functions zu ermöglichen. Dies geht z.B. mit der Software Knative. Diese ermöglich es die Skalierung von Pods bei 0 zu beginnen, d.h. es kann auch kein einziger Pod einer Software laufen, was weitere Ressourcen- und somit Geldeinsparung bewirkt. Die Pods werden dann eventbasiert gestartet.

Kubernetes ist mittlerweile so beliebt, dass jeder Cloudanbieter eine eigene Variante anbietet mit einem Befehl einen kompletten Kubernetes Cluster aufzubauen. Dies heißt bei Amazon AWS "EKS", was für "Elastic Container Service for Kubernetes" steht. Bei Microsoft Azure heißt der Dienst "AKS", was für "Azure Kubernetes Service" steht. Und natürlich bietet auch Google, der Erfinder von Kubernetes, ein One-Click Angebot, "GKE", was für "Google Kubernetes Engine" steht. Mit Hilfe dieser Dienste ist der Aufbau eines Kubernetes Clusters in der Cloud in wenigen Minuten erledigt. Man muss nur die Anzahl der Worker Knoten angeben, die Master Knoten werden vom Cloudanbieter automatisch gestellt und auch von ihm betrieben. Somit kann man sich ganz auf seine Anwendungen konzentrieren.

Wir von adARTIS haben schon für eine Reihe von Kunden Kubernetes Cluster in der Cloud aufgesetzt und die Kunden in deren Betrieb geschult. Zudem setzen wir nicht nur den Kubernetes Cluster auf, sondern auch die gesamte CI/CD Chain um in der Cloud containerbasierte Software zu entwickeln. Solche Projekte können wir schlüsselfertig erstellen. Wir besprechen mit unseren Kunden die Anforderungen und bauen dann nach Anforderung die Betriebsumgebung auf. Quasi als Rundum-glücklich-Paket!

Kontaktieren Sie uns per E-Mail und erfahren Sie mehr !  E-Mail: bmueller [at] adartis.de

Cloud Strategie

To Cloud or not to Cloud…

 

dies ist heute keine Frage mehr. Alle wollen in die Cloud und zwar so schnell wie möglich. Die Cloud ist sexy, die Cloud ist 30% billiger und alles ist besser in der Cloud.

Aber, stimmt das auch?

Natürlich nicht! Zumindest nicht ohne dass man seinen bisherigen Modus Operandi signifikant ändert. Aber betrachten wir die Cloud einmal nüchtern und spielen eine typische Cloudmigration durch.

Der erste und einfachste Ansatz ist „Lift-and-Shift“, d.h. dass möglichst 1:1 transferieren der bestehenden Umgebung in die Cloud. Ist das möglich? Ja, meistens. zumindest teilweise. Ist das sinnvoll? Nein, eher nicht.

 

Lift & Shift

Bei einer Lift & Shift Migration soll die bisherige Umgebung möglichst so belassen werden wie sie ist. Keine strukturellen Veränderungen, kein Redesign. Im Grunde eine Migration wie von einer bare-metal auf eine VM-basierte Umgebung. Der Grund hierfür ist dass man möglichst wenig Arbeit in ein Redesign stecken will (oder dafür keine Zeit hat) und auch ein Redesign für zu fehleranfällig hält. Am Ende des Tages ist eine Cloud ja auch nur eine virtualisierte Laufzeitumgebung.

All diese Argumente stimmen und eine solche Migration kann auch gelingen, jedoch sind mehrere Randbedingungen zu beachten. Erstens können meist nicht alle Elemente in die Cloud migriert werden. Das kann daran liegen dass bestimmte Elemente in der Cloud nicht verfügbar sind, wie z.B. eine Hostumgebung, oder dass für bestimmte Dinge die Lizenzsituation so ungünstig ist dass eine Migration sich nicht rechnet, wie z.B. bestimmte Datenbanken (Oracle, DB/2, …)

Daraus ergibt sich dass Teile der Arbeitsumgebung on premise bleiben während andere Teile in die Cloud gehen und das wiederum bedeutet hohe Bandbreitenanforderungen für die Verbindungen zwischen on premise und Cloud sowie größere Latenzzeiten. Dies können in manchen Situationen schon Showstopper sein. Aber es geht noch weiter. Wenn man die Kosten der bisherigen virtualisierten Umgebung on premise ansieht und diese mit einem 24x7 Betrieb in der Cloud vergleicht sind die Kosten in der Cloud deutlich höher. Selbst wenn man die wegfallenden Betriebskosten dagegenrechnet. Dies bringt uns zum 1. Axiom:

 

Cloudbetrieb rechnet sich nur wenn die Betriebszeiten sinken!

 

Wenn man in einer Cloud wirklich Geld sparen will, muss man sich die Vorteile der Cloudumgebung gegenüber der traditionellen IT zu nutze machen. Und der Hauptvorteil ist: dynamische Skalierbarkeit.

 

Dynamische Skalierbarkeit

Traditionelle Umgebungen müssen immer auf den maximalen Lastfall skaliert werden. D.h. wenn man das ganze Jahr über nur die Leistung von 1-2 Servern braucht, zu Weihnachten oder zum Jahreswechsel jedoch 5 Server, dann muss man 5 Server anschaffen und betreiben und zwar das ganze Jahr. Dies nennt man Skalierung auf das Lastmaximum. Natürlich laufen die Server fast das ganze Jahr mit Minimallast und kosten dabei viel Geld, aber anders ist das traditionell nicht zu machen. Anders in der Cloud! Hier skaliert man seine Umgebung auf die Minimallast und baut eine dynamische, lastabhängige Skalierung ein. D.h. die Anzahl Server wächst oder fällt mit der abzuwickelnden Last. Dadurch kann man sehr viel Geld sparen, was uns zum 2. Axiom bringt:

 

Cloudbetrieb rechnet sich nur bei minimaler und dynamischer Skalierung

 

Self-Service

Neben der technischen Komponente gibt es allerdings auch noch eine organisatorische. Ein Kernkonzept von Cloudumgebungen ist der Self-Service Gedanke. D.h. Benutzer sollen über ein Portal in die Lage versetzt werden Cloudkomponenten, VMs, Router, usw. eigenhändig zu bestellen. Dies kann in in-house Workflowsysteme wie ServiceNow integriert werden. Dadurch verringern sich die Bereistellungszeiten drastisch und der organisatorische Aufwand sinkt beträchtlich. Somit sind wir beim dritten Axiom:

 

Cloudbetrieb rechnet sich nur wenn die Organisationskosten und -zeiten durch Self-Service sinken

 

Aber noch weitere Einsparungen lassen sich durch einen intelligenten Cloudbetrieb erreichen. Die nächste Automatisierungsstufe besteht in der Aufspaltung der klassischen monolithischen Anwendungen in Microservices die wiederum containerisiert und in Container-Orchestrierungsumgebungen wie Kubernetes ausgeführt werden. Der Vorteil hierbei liegt darin dass sich die Anwendungen nun feingranulärer skalieren lassen und somit nur die Teile der Software im laufenden Betrieb dupliziert werden die auch gebraucht werden. Dies bedeutet weitere Kosteneinsparungen. Also lautet das vierte Axiom:

 

Cloudbetrieb erreicht weitere Kostenvorteile bei feingranulärem Anwendungsbetrieb mittels Containern und Kubernetes

 

Aber auch hier sind die Einsparungsmöglichkeiten noch nicht ausgeschöpft! Im klassischen Kubernetes Betrieb skaliert man die Container von 1 bis n, d.h. man muss mindestens einen Container von jedem Microservice am laufen halten, selbst wenn dieser nichts tut. Es gibt jedoch auch im Bereich Container den sogenannten „serverless“ Betrieb, d.h. man kann die Container bis auf 0 zurückskalieren wenn keine Last vorhanden ist. Dies setzen wir in unseren Kubernetes Projekten zur weiteren Kostensenkung für unsere Kunden ein. Also heißt das nächste Axiom:

 

Cloudbetrieb lässt sich im serverless Modus nochmals günstiger gestalten

 

Damit ist man schon sehr weit mit den dynamisch erzielbaren Kosteneinsparungen. Aber längst noch nicht am Ende. Es gibt im Cloudbetrieb eine Art von virtuellen Servern die nochmals 60% - 90% billiger sind als die normalen virtuellen Server: sogenannte Spot Instanzen. Diese Spot Instanzen werden quasi zu einem Bietpreis versteigert und haben keine garantierte Verfügbarkeit, d.h. können jederzeit gestoppt werden. Es tritt also sozusagen ein „erwarteter Desaster Fall“ ein. Da man Kubernetes Cluster, z.B. einen AWS EKS Kubernetes Cluster, mittels Autoscaler automatisch an Lasten anpassen kann bzw. Knoten die gestorben sind automatisch neu aufsetzen kann, kann man hierzu auch Spot Instanzen verwenden. Wir empfehlen einen Mix aus regulären und Spot Instanzen, damit eine minimale Clusterverfügbarkeit immer garantiert ist. Aber auch dann kann man immer noch Kostenvorteile von 30% bis 50% erzielen. Das nächste Axiom lautet also:

 

Cloudbetrieb lässt sich nochmals drastisch durch Einsatz von Spot Instanzen verbilligen

 

Wenden wir uns nun wieder der Anwendungsseite zu. Große Geschwindigkeits- und Kostenvorteile lassen sich in der Anwendungsentwicklung in der Cloud erzielen. Das Stichwort heißt hierbei DevOps. DevOps steht für Developer Operations, d.h. die Entwickler übernehmen auch Betriebsaufgaben, die Klassischerweise in einer anderen Betriebsabteilung aufgehängt waren. Hierzu ein Beispiel: Vor DevOps lief der Betrieb typischerweise so: Die Entwicklungsabteilung entwickelte ca. alle 2-3 Monate ein neues Release der Software und übergab diese dann einschließlich Betriebshandbuch, Installationsanleitung und Testverfahren an den Betrieb. Dieser benötigte dann 1-2 Stunden um die Software in Betrieb zu nehmen und diese Inbetriebnahme zu dokumentieren. D.h. der Releasezyklus betrug eine neue Version ca. alle 2-3 Monate. Mit DevOps sieht die Sache so aus: Der Entwickler checkt eine neue Version seiner Software in das Softwarerepository ein, automatisch wird ein Build angestoßen, die Software in einen Container deployed und dieser dann automatisch auf dem Kubernetes Cluster installiert und getestet. Dieser ganze Vorgang dauert ca. 2-5 Minuten, je nach Softwareumfang. Das bedeutet heute ist es möglich 30 bis 50 mal am Tag ein neues Release einzuspielen und auch automatisch zu testen. Dies beschleunigt zum einen die Softwareentwicklung enorm, zum anderen kann Betriebspersonal eingespart und anderswo eingesetzt werden. Dieser automatische Vorgang wird auch durch die Kürzel CI/CD beschrieben: Continuous Integration / Continuous Deployment.

Das nächste Axiom ist somit:

 

Cloudbetrieb verbilligt und beschleunigt die Softwareentwicklung durch Einsatz von DevOps und CI/CD drastisch

 

Preise

Bare Metal Cloud(MaaS)

  • Automatische Erkennung und Registrierung jedes Netzwerk-Devices
  • Deployment von Ubuntu, CentOS, Windows, RHEL und SuSE auf Knopfdruck
  • Konfiguration der Netzwerkinterfaces mit Bridges, VLANs, Bonds und mehr
  • Integration mit DevOpsTools
  • Komplettpreis für bis zu 10 Server
  • Preis: 7.500€
 

Containerisierte private Cloud

  • Private Cloud basierend auf Container Clusterplattformen
    • Kubernetes oder
    • Mesosphere DC/OS
  • Aufbau einer schlüsselfertigen, skalierbaren  Containerplattform mit bis zu 10 Servern
  • Preis: 10.000€
 

OpenStack private Cloud

  • OpenStack Cloud basierend auf Modulen für Networking, Storage und Compute
  • Basierend auf MaaS als Bare Metal Orchestrierung
  • Block- und Object-Storage basierend auf Ceph
  • Komplettpreis für bis zu 10 Server
  • Preis: 17.500€
 

PaaS Plattform auf OpenStack

  • OpenShift PaaS basierend auf OpenStack Cluster
  • Alternativ: CloudFoundry PaaS on OpenStack
  • Aufbau der PaaS und Integration der Java CI/CD
    • Automatisches Jenkins Deployment in Cloud
  • OpenStack muss vorhanden sein
  • Preis: 17.500€
 

Cloud Management

  • Wir betreiben Ihre private Cloud
  • Monitoring, Backup und Restore, Reporting
  • Provisionierungvon VMs
  • Integration in Ihre CI/CD Chains
  • Wartung und Patching
  • Preis: 1.200€ Tagessatz / 150€ Stundensatz
 

Cloud Schulung

  • Wir schulen Sie in allen Cloudtechnologien
    • Metal as a Service
    • Kubernetes
    • Mesosphere DC/OS
    • OpenStack
    • CloudFoundry
    • OpenShift
    • Cloudify
    • Terraform
  • Preis: 1.200€ Tagessatz / 150€ Stundensatz

Kontaktieren Sie uns per E-Mail und erfahren Sie mehr !  E-Mail: bmueller [at] adartis.de