ChatbotConf 2017: Chatbots, Startups und Walzer

Veröffentlicht am 13. Oktober 2017 von

Mit dem rechten Fuß nach vorne. Der linke Fuß wandert schräg nach links. Und der rechte zieht hinterher. Ich bin in Wien und tanze Walzer. Passt ja irgendwie. Aber war ich nicht auf der ChatbotConf 2017? Stimmt… Ich starte wohl besser von vorne. Weiterlesen →

Veröffentlicht unter News | Verschlagwortet mit , , , , , | Kommentar hinterlassen

Autonomous databases, Blockchains and Cloud-native architectures – an OOW 17 recap

Veröffentlicht am 9. Oktober 2017 von

Oracle Open World (OOW) 2017 just ended on thursday last week. As usual, it was a great and inspiring conference, which nevertheless felt slightly different than the years before.

Why does it felt different?

A different spirit seemed noticeable, because Oracle starts to put more focus on the developer community – more power to the developers! For the first time, an Oracle Code track took place as part of Java One. Oracle Code was established between last years OOW and this years conference and was run at several locations all over the world. This promising new format explicitly addresses developers, so the tracks are more technical and are not necessarily focusing Oracle products and technologies, but are also covering Open Source technologies, like Kafka, etc.

With respect to Open Source it is also interesting to see that Oracle integrates, uses and thrives respective technologies in their platform services, which will be discussed in the following.

News and worth mentioning

Autonomous Database

One of the most polarizing announcements was a new version of Oracle flagship, the database Oracle 18c. This version implements a new and revolutionary concept, of a self-driving autonomous database, which needs less human interactions; typical DBA tasks like patch, tune, back up, and upgrade are done by the database autonomously.

„This is a big deal, by the way. No one else does this. This is the most important thing we’ve done in a long, long time.” (Larry Ellison, Oracle Executive Chairman and CTO)

The autonomy of the database is achieved by leveraging Machine Learning (ML) algorithms. A very exciting and outstanding development, which will of course changes the role of DBAs in the future. But DBAs will not become superfluous; they need to rethink their roles.

Container native app development of the future

Oracle announced their new development platform for Cloud-native applications, which consists of

  • Container Pipelines, a.k.a. as Wercker for managing container builds and deployments,
  • Container Registry Service, implemented as a full Docker v2 comptabile private registry
  • Container Engine, which is a Fully-managed Kubernetes Service; This service was announced to be available soon.

I addition, a new Serverless platform based on Fn (http://fnproject.io), which is a Open Source container native serverless platform, was announced. The main advantage of this approach is that serverless functions can be developed and tested locally before deploying it to a runtime. The target runtime the so defined Serverless functions is the Managed Kubernetes Service (Container Engine), which is capable to execute Containers and Serverless functions.

Blockchain – the next big thing in IT

A topic, which was impressively present at this years OOW was Blockchain. The corresponding sessions were always completely packed. The sessions where covering different aspects beginning with an introduction, what Blockchain is and how it can be implemented. Furthermore it was shown, how Oracle will approach the topic with a new fully-managed Blockchain Cloud Service. This upcoming service is based on Hyperledger, which is hosted by the Linux Foundation, where Oracle recently joined.

„Blockchain hold the promise to fundamentally transform how business is done, making business-to-business interactions more secure, transparent, and efficient.“ (Amit Zavery, Senior Vice President Oracle Cloud Platform)

So, let’s stay tuned for more and see, if Blockchain becomes significantly game changing as discussed nowadays.

Simplified Cloud adoption through improved subscription model

In the past, Oracle’s subscription model was not flexible enough, since customers need to specify what kind of Cloud Services are needed. Now, Oracle introduces so called Universal credits, which makes life easier. Customers, buy credits and have access to all IaaS and PaaS offerings. More flexibility at lower costs that is the key promise – sounds great!

In addition, a new Bring your own licence (BYOL) model has been introduced which allows customers to use existing on premise licenses for respective Cloud Services. Another interesting offering to existing on premise licenses, to get started with Cloud.

Further interesting facts

Besides the aforementioned points, it was also noticeable that the Oracle Cloud offerings become more and more integrated. In the near future Cloud Services will be grouped in reasonable packages. Examples for that are:

  • Oracle Mobile Cloud enterprise (OMCe)
    • Mobile Cloud Service
    • Intelligent Bots
    • Customer Experience Analytics
  • Oracle Integration Cloud (OIC)
    • Integration Cloud Service (ICS)
    • Process Cloud Service (PCS)
    • Visual Cloud Builder Service (VBCS)
    • Analytics
  • Deeper integration of Oracle API Platform Cloud Service and Apiary to allow a full API Management

Further relevant topics, which were dominating the conference were:

  • Machine Learning and Artifical intelligence (Oracle Analytics Cloud)
  • Chatbots (Oracle Intelligent Bots Service)
  • API Management

Summary

As it can be seen from this article, there was again tons of new information, which can be taken home from the conference. It again showed the relevance of OOW for daily business, because learning about newest products, roadmaps and concepts is essential. It is important to sharpen the view on diverse topics and how the way, to position Oracle’s portfolio at customers can be improved and how those can add significant value by implementing Oracle Cloud solutions.

 

 

Veröffentlicht unter Cloud & Infrastructure, News, Strategy & Methods | Verschlagwortet mit , , , , , , | Kommentar hinterlassen

Reduzierte Big Data Kosten mit AWS Spot Instanzen

Veröffentlicht am 1. Oktober 2017 von

Wer sich heutzutage mit Big Data Themen kombiniert mit Amazon Web Services (AWS) beschäftigt, benötigt in der Regel schon ein eigenes kleines Wörterbuch für die ganzen Abkürzungen und Toolnamen aus beiden Welten. Ein weiteres Thema ist die eigene Problemstellung in dieser neuen Welt zu implementieren. Das sich dieser Weg durchaus auf verschiedenen Ebenen lohnt, möchte ich in diesem Blogartikel aufzeigen.

Was ist AWS EMR

Amazon bietet eine eigene Big Data Distribution an. Diese hat neben dem Resourcen Manager (Yarn), einem Hadoop File System und Spark noch einige andere Tools wie Sqoop, Oozie und Zeppelin.

Durch den Elastic Map Reduce (EMR) Dienst wird ein Big Data Cluster komplett erzeugt, inklusive ausgewählter Hardware und Software. Wenn das entsprechende „Create Cluster“ Kommando verwendet wird dauert es ca. 7 Minuten bis der neue Cluster Einsatzbereit ist und alle Instanzen den Status „running“ haben.

Der Cluster kann beispielsweise über die AWS Console (AWS Webseite) konfiguriert werden oder über das AWS Kommandozeilentool. Das zuletzt genannte Tool stellt eine spannende Option für Automatisierungen dar.

AWS EMR kostet ein einen kleinen Betrag extra zu den anfallenden Kosten für die Instanzen.

In diesem Beispiel werden m4.large Instanz Typen in der Region EU(Frankfurt) verwendet.

Diese kosten in diesem Moment 0,12 US Dollar pro Instanz und Stunde. Der EMR Aufschlag beträgt 0,03 US Dollar pro Stunde und Instanz. Dies ist exklusive der Mehrwertsteuer. Es gibt zwar noch Transfer und Storage Gebühren und vieles mehr, aber die genannten Kosten und die Mehrwertsteuer stellen den absolut größten Teil der Kosten dar und können für eine grobe Kosteneinschätzung verwendet werden. Weitere Informationen hierzu können direkt auf der AWS Pricing Webseite nachgelesen werden.

Aufgerundet exklusive Mehrwertsteuer kostet jede Instanz pro Stunde 0,15 US Dollar.

 

Spot Instanzen

AWS bietet Spot Instanzen an. Die Idee ist, dass Kunden statt einem fixen Preis, wie bei den bisher hier verwendeten On-Demand Instanzen (m4.large 0,12 US Dollar pro Instanz pro Stunde), wie bei einer Auktion ein Gebot für die Nutzung der Instanzen abgeben. Dies kann dazu führen, dass Instanzen 90% unter dem On-Demand Preis zur Verfügung gestellt werden können. Daraus können bei richtiger Nutzung großartige Mehrwerte gezogen werden. Es muss nur definiert werden, was das Ziel sein soll. Eines könnte die Reduzierung der Kosten sein.

Änderung der Abrechnungseinheiten von Stunden auf Sekunden

Eine aktuelle Änderung in der Preisgestaltung von AWS ist die Umstellung der Abrechnungsintervalle zum 02.10.2017. Bisher wurden alle Instanzen Stundenweise abgerechnet, wenn eine Verarbeitung 125 Minuten dauert, dann wurden 3 Stunden für jede Instanz im Cluster berechnet. Dies wird jetzt auf sekundengenaue Abrechnung umgestellt. Nachlesen können sie die Details bei AWS direkt new-per-second-billing-for-ec2-instances-and-ebs-volumes.

Es gibt eine Mindestabnahmezeit pro Instanz von 60 Sekunden, danach wird sekundengenau abgerechnet. In unserem Beispiel (125 Minuten Verarbeitung) alte Berechnung:

Prei pro Instanz pro Stunde: 0,12 $ (Instanz) + 0,03 $ (EMR) (Steuern entfallen als Vereinfachung)

Preis in $ Instanzen Stunden Gesamtsumme in $  %
Alte Berechnung 0,15 3 3,00 1,35 100,00
Neue Berechnung 0,15 3 2,08 0,94 69,43

Natürlich ist beim Beispiel mit 125 Minuten der Effekt fast maximal. In diesem Beispiel wurden über 30% Kosten eingespart, durch die Veränderung der Abrechnungseinheiten

Was für Gruppen gibt es im EMR: Master, Core, Task

Das AWS EMR bietet durch die verwendete Hadoop Technologie basierend auf dem Hadoop File System (HDFS) und dem Resourcen Manager (YARN) eine perfekte Umgebung, um AWS Spot Instanzen zu verwenden.

Sowohl Instanzen aus der Master Gruppe, wie auch aus der Core Gruppe, sollten nicht mit Spot Instanzen verwendet werden. In der Master Gruppe laufen in der Regel die Master Prozesse von Anwendungen, also zum Beispiel der HDFS NameNode oder den Applications Manager, welcher einen Teil des Yarn Resource Manager ist. An dieser Stelle müssen On-Demand Instanzen verwendet werden, da die Instanzen nicht wegfallen dürfen.

Auch in der Core Gruppe sollten keine Instanzen wegfallen. In dieser Gruppe liegen die DataNodes des HDFS. Wenn von diesen DataNodes zu viele wegfallen, kann es trotz impliziter Replikation zu Datenverlusten kommen.

Die Task Gruppe und ihre Instanzen sind optional und haben weder NameNode noch DataNode Prozesse. Es werden hier also keine HDFS Daten persistiert sondern lediglich Resourcen für die Verarbeitung zur Verfügung gestellt. Aus HDFS Sicht sind die Task Nodes also nicht existent, für Yarn stellen sie jedoch zusätzliche Verarbeitungs-Resourcen zur Verfügung.

Dies hat zur Folge, dass vorhandene Task Instanzen die Verarbeitung beschleunigen. Sollten diese Instanzen mitten in der Verarbeitung nicht mehr verfügbar sein, wie es bei Spot Instanzen der Fall sein kann, ist dies kein Problem. Der Resourcen Manager stellt fest, dass Verarbeitungs-Resourcen weggefallen sind und verteilt deren Aufgaben an andere Instanzen die verfügbar sind und Kapazitäten frei haben. Dies kann sich nur auf die Laufzeit nicht aber auf den Erfolg der Verarbeitung auswirken.

Beispielsetup mit einer Task Gruppe die aus Spot Instanzen besteht

Dies ergibt spannende Möglichkeiten. Wenn die Verarbeitung mit einer Master und 8 Core On-Demand Instanzen durchgeführt wird und 125 Minuten dauert, berechnen wir die EC2 und EMR Kosten für diese Verarbeitung. Wenn weitere 8 Task Spot Instanzen hinzukommen reduziert sich die Laufzeit auf 65% von 125 Minuten (2,08 Stunden) ergibt 81,25 Minuten (1,35 Stunden) Laufzeit.

Der Preis pro Instanz pro Stunde für On-Demand setzt sich zusammen aus (0,12 $ Instanz, 0,03 $ EMR).

Der Preis pro Stunde für Spot Instanzen setzt sich zusammen aus (0,03 $ Instanz und 0,03 $ EMR).

Preis in $ Instanzen Stunden Gesamtsumme in $  %
1 Master 8 Core 0,15 9 2,08 2,81 100,00
1 Master 8 Core 0,15 9 1,35 1,82
8 Task 0,06 8 1,35 0,65
Summe neu 2,47 87,98

 

Durch das Hinzufügen von 8 Spot Instanzen als EMR Task Gruppe wurde die Laufzeit der Verarbeitung um 35% reduziert und das zu etwa 12,02% reduzierten Kosten.

Im Positivfall wurde sowohl Geld gespart als auch eine deutlich kürzere Verarbeitungszeit benötigt. Der Negativfall, wir bekommen die Spotinstanzen nicht zu dem gewünschten Preis, bedeutet 100% Laufzeit und 100% Kosten wir haben also den Status Quo.

Dies stellt nur ein einfaches Beispiel dar, was mit etwas Kreativität möglich ist. Natürlich skalieren verschiedene Daten und Programme unterschiedliche und der geneigte Leser muss eigene Tests durchführen, welches Setup das Passende ist. Dabei sind nicht nur Kostenoptimierungen, sondern auch Laufzeitoptimierungen als Ziel möglich. Wie verschiedene Instanz Typen (M4.Large in diesem Beispiel) zu der eigenen Verarbeitung passen wurde ebenfalls komplett ausgeblendet. Auch hier bietet sich noch einiges an Optimierungspotential.

 

Veröffentlicht unter Analytics & BigData, Cloud & Infrastructure | Kommentar hinterlassen

IT|espresso – 10 unterschätzte Kriterien für eine Mobile Strategie

Veröffentlicht am 29. September 2017 von

Nativ, Web, Hybrid oder Cross Compiled? Im Rahmen unserer zahlreichen Beratungskontexte haben wir bisher 48 Kriterien für die Auswahl der richtigen Mobile-Strategie ausgemacht. 10 davon die häufig unterschätzt bzw. sogar komplett vergessen werden, wollen wir Ihnen im Rahmen als Impulsvortrag auf unserem IT|espresso  vorstellen. Danach freuen wir uns, Sie zu einem hervorragenden Stück Kuchen einzuladen und lebhaft mit Ihnen über das Thema zu diskutieren.

Ihre Anmeldung können Sie unter folgenden Link durchführen: Anmeldung.

Für mehr Informationen zu den Angeboten von Opitz Consulting zum Thema Mobile kontaktieren Sie gerne Karsten Will (karsten.will@opitz-consulting.com) oder Philipp Leinius (philipp.leinius@opitz-consulting.com).

Wir freuen uns auf Ihre Teilnahme!

Quellen & Weiterführende Informationen:

https://thecattlecrew.net/2017/07/07/mobile-team-as-a-service/

https://thecattlecrew.net/2017/07/27/managed-services-engagement-modelle/

Veröffentlicht unter Frontend Development, Managed Services, Software Engineering | Kommentar hinterlassen

Apache Kafka – im Detail (Teil 2)

Veröffentlicht am 28. September 2017 von

Schaut man sich Kafka im Detail an, wird der Aufbau schnell komplex. Dort gibt es dann Broker, Partitionen, Replica, Leader, Follower und die aus Teil 1 schon bekannten Topics. Aber der Reihe nach: Kafka selbst läuft auf sogenannten Brokern, oft auch Nodes genannt, wobei ein Broker im Prinzip ein Kafka Server ist. Ab zwei oder mehr Brokern spricht man auch von einem Broker Cluster bzw. Kafka Cluster.

Kafka Cluster

Im Prinzip speichern die Broker die Nachrichten oder Daten einfach nur, sodass die Consumer sich diese dann abholen können. Diese Daten werden dazu in Topics unterteilt, sodass nicht jeder Consumer jede Nachricht bedenken muss. Der Producer bestimmt dabei, welche Nachricht in welchem Topic landet. Die Topics müssen dafür vorher manuell erstellt werden.

Kafka Aufbau - Page 1

Abbildung 1 – Darstellung eines Kafka Clusters

Interessant wird es, wenn man betrachtet wie die Broker die Nachrichten speichern. Dazu werden die Topics in Partitionen unterteilt. Die gespeicherten Nachrichten in jeder Partition sind nach zeitlichem Eingang sortiert und diese Reihenfolge ist unveränderbar. Die zeitliche Reihenfolge der Nachrichten ist dabei nur per Partition, nicht aber pro Topic sichergestellt. Es sei denn ein Topic hat nur eine Partition. Zur Identifizierung bekommt jede Nachricht eine eindeutige ID, das sogenannte Offset. Dadurch können Consumer ganz gezielt bestimmte Nachrichten abfragen. (siehe Abbildung 2)

Kafka speichert alle Nachrichten über einen einstellbaren Zeitraum und da es eine konstante Skalierung in Bezug zur Datenmenge aufweist, ist auch das Speichern großer Datenmengen über einen längeren Zeitraum kein Problem, zumindest nicht für Kafka.

topicKafka

Abbildung 2 – Darstellung eines Topics (kafka.apache.org/documentation/)

Ein großer Vorteil der Partitionen ist es, dass die Datenmenge eines Topics größer werden kann als die Speicherkapazität des Brokers. Dies ist in Abbildung 1 in Topic 1 veranschaulicht.

Ausfallsicherheit

Um die Ausfallsicherheit zu gewährleisten, können von den Topics bzw. von den Partitionen Kopien, sogenannte Replicas, erstellt werden. Das ergibt natürlich nur Sinn, wenn es mindestens so viele Broker wie Replicas gibt. Unter allen Brokern, die Kopien einer Replica haben,  wird mit Hilfe von Zookeeper bestimmt, wer der Leader wird. Da in Zookeeper die Informationen über den Aufbau des Clusters gespeichert werden. Der Leader bekommt die Nachrichten von den Producern und wird von den Consumern angefragt, wenn sie Nachrichten haben wollen. Außerdem sorgt er dafür, dass die Follower aktuelle Kopien des Leaders haben.  In Abbildung 1 sind die Leader die grün umrahmten Partitionen und die schwarzen sind die Follower. Die Partitionen aus Topic 1 haben dabei nichts mit denen aus Topic 2 zu tun.

Consumer

Der letzte hier noch nicht weiter erläuterte Teil von Kafka sind die Consumer. Alle Anwendungen, die Nachrichten von Kafka empfangen, werden als Consumer bezeichnet. Es ist möglich, dass ein einzelner Consumer alle Nachrichten aus einem bestimmten Topic oder aber nur aus bestimmten Partitionen eines Topics lesen kann. Letzteres Szenario entspräche dann eher einer klassischen Message Queue. Mit dem Unterschied, dass auch in diesem Fall der Consumer Nachrichten mehrmals lesen könnte und nicht zwangsweise die Nachrichten in der Reihenfolge lesen muss wie sie auf den Partitionen gespeichert sind.

Dieses Szenario hat allerdings ein Problem. Angenommen wir haben einen Producer, der schneller Nachrichten an das Topic sendet, als unser Programm verarbeiten kann. In diesem Fall würde unser Consumer weiter und weiter beim Konsumieren der Nachrichten zurückfallen und ein merkbarer Lag zwischen Senden und Empfangen würde entstehen, der nicht mehr aufgeholt werden könnte. Hier hätte man jetzt zwei Möglichkeiten. Entweder man optimiert den Consumer (Bessere Hardware oder besserer Code) oder aber man schaltet einen zweiten Consumer dazu, der parallel zum Ersten auch Nachrichten empfangen kann. Um Letzteres implementieren zu können, gibt es bei Kafka die sogenannten Consumer Groups.

Consumer Groups

Ein Consumer kann einer Consumer Group beitreten, die immer einem Topic zugeordnet ist. Innerhalb einer solchen Consumer Group werden eine oder mehrere Partitionen genau einem Consumer zugeordnet. Das heißt ein Consumer kann mehreren Partitionen zugeordnet sein, eine Partition aber immer nur genau einem Consumer. Der Vorteil hierbei liegt in der Parallelität. Je mehr Partitionen ein Topic hat, desto mehr Nachrichten können parallel von einer Consumer Group empfangen werden.

Ein weiterer Vorteil Kafkas ist es, dass während der Laufzeit Consumer die Consumer Group verlassen oder hinzukommen können. Jedes Mal wenn dies passiert führt Kafka ein sogenanntes rebalancing aus und verteilt die Partitionen auf alle verfügbaren Consumer. Dabei ist die Parallelität durch die Anzahl der Partitionen beschränkt. Gibt es mehr Consumer als Partitionen, sind diese überschüssigen Consumer solange im Leerlauf.

Im normalen Use Case von Kafka gibt es daher viele Producer (Datenproduzierende Systeme), die in viele verschiedene Topics  schreiben. Diese Topics werden dann von Consumern abgerufen, und die Daten werden analysiert, verarbeitet und abgespeichert. Kafka erlaubt hierzu eine extrem hohe Durchsatzrate, kann aber auch als Puffer dienen, falls bei den Consumern mal etwas schief läuft.

Veröffentlicht unter Analytics & BigData, IoT & Industry 4.0, Software Engineering | Kommentar hinterlassen

Solve digital transformation challenges using Oracle Cloud

Veröffentlicht am 27. September 2017 von

Digital transformation is an omnipresent topic today, providing a lot of challenges as well as chances. Due to that, customers are asking about how to deal with those challenges and how to leverage from the provided chances. Frequently asked questions in this area are:

  • How can we modernize existing applications?
  • What are the key elements for a future-proven strategy IT system architecture?
  • How can the flexibility as well as the agility of the IT system landscape be ensured?

But from our experience there’s no common answer for these questions, since every customer has individual requirements and businesses, but it is necessary to find pragmatic solutions, which leverage from existing best Practices – it is not necessary to completely re-invent the wheel.

With our new poster „Four Pillars of Digitalization based on Oracle Cloud“ (Download it here) , we try to deliver a set of harmonized reference models which we evolved based on our practical experience, while conceiving modern, future-oriented solutions in the area of modern application designs, integrative architectures, modern infrastructure solutions and analytical architectures. The guiding principle, which is the basis for our architectural thoughts is: Design for Change. If you want to learn more, you can refer to our corresponding Ebook (find the Ebook here, only available in German at the moment).

Usually the technological base for modern application architectures today is based on Cloud services, where the offerings of different vendors are constantly growing. Here it is important to know which Cloud services are the right ones to implement a specific use case. Our poster „Four Pillars of Digitalization based on Oracle Cloud“ shows the respective Cloud services of our strategic partner Oracle, which can be used to address specific challenges in the area of digitalization.

Veröffentlicht unter Cloud & Infrastructure, Strategy & Methods | Verschlagwortet mit , , | Kommentar hinterlassen

API Platform Cloud Service & Integration Cloud Service @ Oracle PaaS Summer Camp 2017

Veröffentlicht am 25. September 2017 von

The PaaS Summer Camp 2017 in Lisbon was a great experience! Especially for me as a former Oracle employee it felt a bit like ‚coming home‘. The whole event was very well organized with six different PaaS training tracks to chose from.

In the area I had chosen – API Platform Cloud Service (APIPCS) & Integration Cloud Service (ICS) – we had the opportunity to get some hands on to the latest and greatest release of APIPCS:

We tested to

  • design
  • implement
  • secure
  • deploy
  • document

and register an API to an application.

Also in the area of ICS we simulated real world use cases, e.g. an integration of an ERP system.

The aim was not to follow step-by-step instructions but to try things out, play around and ask questions to gather some feeling for and experience with the product. As the training was delivered by the Product Managers themselves it was a great opportunity to grow your network to be able to contact the relevant people for future projects in this area.

Besides that we had great company of colleagues, Oracle partners and Oracle employees themselves in a wonderful city.

I can really encourage everybody to take part in this great event!

Veröffentlicht unter Cloud & Infrastructure | Verschlagwortet mit , , | Kommentar hinterlassen