Die Lambda-Architektur in der Praxis

In der IT ist es kaum noch möglich, dem Word „Lambda“ zu entgehen: Die Lambda-Ausdrücke in Java 8, Amazons AWS Lambda für Cloud-Berechnungen und auch im Big-Data-Bereich ist die Lambda-Architektur ein zentrales Architektur-Pattern für datengetriebene Systeme.

Was eine Lambda Architektur genau ist und vor allem mit welchen Tools aus dem blogPicHadoop Ökosystem sie realisiert werden kann, erfahren Sie in unserem Whitepaper „Lambda-Architektur in der Praxis“. Im Whitepaper demonstriere ich des Weiteren den Aufbau einer Lambda Architektur im Anwendungsfall eines Automatenherstellers.

Für Unternehmen bieten wir außerdem einen eintägigen Workshop an, in dem sich alles um die Themen Hadoop, NoSQL, In-Memory Stream Processing und Big Data dreht. Mehr dazu in unserem Factsheet „Mit Big Data in die Digitalisierung starten“.

PS: Und wen auch die anderen ebenfalls erwähnten Lambdas interessieren, der sei nach hier und hier verwiesen.

Veröffentlicht unter Analytics & BigData, Cloud & Infrastructure, IoT & Industry 4.0, Uncategorized | Verschlagwortet mit , , | Kommentar hinterlassen

AWS News KW 37

EC2 Instanzen mit 4 TB Arbeitsspeicher verfügbar

Anfang des Jahres gab Amazon bekannt, das geplant ist EC2 Instanzen mit bis zu 16 TB Arbeitsspeicher anzubieten. Seit letzter Woche ist die nächste Ausbaustufe für dieses Ziel verfügbar.

Die neuen x1e.32xlarge Instanzen haben 4 TB Arbeitsspeicher und 4 Intel Xeon E7 8880 v3 Haswell Prozessoren mit 2,3Ghz (128 vCPUs). Damit sind die Instanzen bestens gerüstet für SAP/HANA sowie andere Arbeitsspeicher intensiven Anwendungen wie Apache Spark.

Die x1e.32xlarge Instanzen sind in den Regionen EU (Irland), US East (Northern Virginia), US West (Oregon) und Asia Pacific (Tokyo) verfügbar.

Weitere Informationen zu EC2 Instanztypen hier.

AWS CodeBuild unterstützt Secrets

AWS CodeBuild ist ein fully managed Buildservice der Code compiliert, Tests ausführt und deploybare Artefakte erzeugt.

Ab sofort können Geheimnisse wie Datenbank Credentials etc., die während des Builds benötigt werden  aus dem Systems Manager Parameter Store bezogen werden. Der System Manager Parameter Store stellt eine sichere Speicherung von Konfigurationsparametern dar.

Weitere Informationen zu AWS CodeBuild hier.

 

 

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

Cloud Application Development

I visited the Oracle Summer Camps in Lisbon. First of all: Thanks to all who were responsible for organizing and actually running the event. It has been a great time and I took more than a lot of new Ideas back home with me.

So what was it about: I have been listening to the slot Cloud Application Development: JET + DevCS, ACCS, Stacks + CCS, Wercker as Docker centric DevOps tool & Management Cloud Service. A lot of stuff right?

The first two days we were told what Oracle JET is. To summarize: Oracle JET is mainly a UI Library using a lot of KnockoutJS and requireJS. And we’re hitting the main point here. It’s absolutely important to know knockoutJS, if you want to learn OracleJET, first do some knockoutJS Tutorial. Apart from that, OracleJET is pretty cool. Especially when you’re using the new ojet CLI. It makes it really easy to get started. So go and try it!

My personal highlights of the Oracle Cloud Service Hands on Labs have been the lift and shift option of the JCS (Java Cloud Service) and especially the OCCS (Oracle Container Cloud Service).

You could pull directly from your Docker Repository, build some Wercker Workflows and wrap it up together as a Stack in OCCS. That is a really cool feature!

JCS should be considered a possibility in every WLS migration project. The point about it: You get, for example, a preconfigured, scalable, load-balanced WLS environment where you can host your formerly on premise-application easily.

DevCS (Developer Cloud Service) is a nice possibility to organize your Development Process. It is possible to create Tasks, Sprints and watch the Burn-down chart when you finish the Tasks. But when you are using the Atlassian Stack in your organization you will miss some of the features like the commit to Task connection. A pretty cool feature I have often used in my Projects and deliver a great benefit to the poor fellow who has to review the Code changes. But apart from that, it is a good solution that covers the DevOps circle almost completely. Other benefits are: You can either use the hosted Git repository or bring your own repository; you can easily create a continuous integration process because a Hudson instance is integrated in the Service. If you want more information just visit: https://cloud.oracle.com/en_US/developer-service

Except for the monitoring part, DevCS delivers all features you need for the DevOps circle. The Monitoring part is covered in the Management Cloud Service and in more detail Application Performance Monitoring (APM). In APM you have a lot of metrics you can watch and configure to monitor your Application Performance. In the Hands on Labs we got a quick introduction in installing APM and watched some metrics of an Application that has been deployed using DevCS. If you ask me, the installing and configurations process could be improved, but the information you get out of APM is very detailed. So it is a really good extension to DevCS! More information about APM you get here: https://cloud.oracle.com/en_US/application-performance-monitoring

At last I want to thanks the trainers Maciej Gruszka, Geertjan Wielenga, Volker Linz and Peter Nagy and congratulate them all: You have been doing a great Job! If I forgot to mention something, please do not be offended, it was a lot of amazing stuff you guys presented! Looking forward to see you again!

Veröffentlicht unter Cloud & Infrastructure, Uncategorized | Kommentar hinterlassen

CA Policy Manager. How can you activate CORS?

Opitz Consulting started to cooperate with CA in the API management area a few months ago (more can be found here: https://thecattlecrew.net/2017/07/07/opitz-consulting-und-ca-zwei-starke-partner-in-sachen-api-management/) and therefore it is straight-forward to use the CA API Policy Manager to secure the access to our new internally developed canteen system. The new solution includes apps for Android, IoS but our API’s can also be accessed by web browsers. In the latter case CORS needs to be taken into account. In this blog post we will explain what CORS actually stands for and how its usage was implemented in our CA policies.

What is CORS?

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources (e.g. fonts) on a web page to be requested from another domain outside the domain from which the first resource was served. A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos. Certain „cross-domain“ requests, notably Ajax requests, however, are forbidden by default by the same-origin security policy. CORS defines a way in which a browser and server can interact to determine whether or not it is safe to allow the cross-origin request. It allows for more freedom and functionality than purely same-origin requests, but is more secure than simply allowing all cross-origin requests. (Source: Wikipedia)

Lets try to explain CORS by an easy example.

If a.com makes a request to b.com it means that they have a different origin.

1

For security reasons these types of requests have been prohibited by browsers. However to improve web applications, webdevelopers asked browser vendors to allow cross-domain requests.

  1. Client a.com sends a GET request b.com/foo to server b.com
  2. b.com answers with code response 200 {foo: ‘bar’} Header: Access-Control-Allow-Origin (ACAO): a.com

Access-Control-Allow-Origin is correct and because of that b.com sends a right answer. CORS (Cross-Origin Resource Sharing) is a way for the server to say “I will accept your request, even though you came from a different origin.”

We are using the CA Policy Manager Application to manage access to our new canteen API. We built our WebApp using Angular2 so we occurred very easily to the CORS problem. Let us see how to switch on the CORS settings in the CA Policy Manager.

There are some rules you need to follow:

  • The service (i.e. the API) must have the OPTIONS method enabled.
  • The “Process CORS Request” assertion has to appear before any authentication assertions in our policy.
  • There should be some policy logic that returns HTTP status 200 immediately upon all successful CORS preflight requests.

Let us go into further detail on those three topics:

I. The service must have the OPTIONS method enabled.

1. Open your CA Policy Manager

2. Find your API’s service properties

2a

3. In the HTTP/FTP tab additionally choose “OPTIONS” as an allowed HTTP Method

3a

The OPTIONS method is not allowed by default in the CA Policy Manager. If you don’t switch on this feature you might encounter an error like this when receiving an API web request:

It is important to enable this because without access for the „OPTIONS method“ you won’t be able to execute preflight requests (point III).

II. the Process CORS Request assertion must appear before any authentication

1. It is  crucial that “Process CORS Request“ is placed before any authentication  policy

11a

2. Do not check the “Require CORS“ option in the properties of the assertion to ensure that other clients (as Android or IoS apps) will also be able to work with your API.

5a

3) The OPTIONS method must also be allowed in the scope of the assertion (Process CORS Request Properties -> Allowed Methods. It is a last tab in the image above).

III. There should be policy logic that returns HTTP status 200 immediately upon all successful CORS preflight requests.

1)    According to the CORS standard, a browser sends a „preflight“ request to determine whether it has permission to perform the action. Only when the backend server approves, the browser will send the actual request with the HTTP request method, so you need to add a “Compare Expression” Policy. Variable ${cors.isPreflight} needs to return „true“ if the request is a preflight. Please use settings as shown below:

6a

2) API Policy Gateway must answer with 200 HTTP status. To achieve this aim choose a policy “Return Template Response to Requestor”. You can also define a response body as we have done.

7a

After those simple 3 steps you can use your API with IoS, Android and web clients.

 

Veröffentlicht unter Cloud & Infrastructure, IoT & Industry 4.0, News | Verschlagwortet mit , , , | Kommentar hinterlassen

Opitz Consulting @ Oracle PaaS Summer Camp 2017

In the last week of August the 7th annual Oracle PaaS Summer Camp (formerly known as the Oracle Fusion Middleware Summer Camp) took place – once again close to the beautiful city of Lisbon. More than 100 participants attended the event involving six different tracks covering the full range of PaaS offerings by Oracle.

This year a group of four people from Opitz Consulting attended the event; these are the tracks we visited:

  • API Cloud Platform Service & Integration Cloud Service
  • Cloud Application Development: JET + DevCS, ACCS, Stacks + CCS, Wercker as Docker centric DevOps tool & Management Cloud Service
  • Chatbots, Mobile Cloud Service & JET

Quite a number of different services, right? My colleagues Verena Otter-Grail, Jan Winkels and Waldemar Kubassa will tell you more about the particular trainings and their experience of the Summer Camps in separate blog posts to be published within the next few days.

In case that you have any questions on one (or more) of those products or plan to improve your business by using them, feel free to contact us at any time!

And last but not least: special thanks to Jürgen Kress for the excellent organization of the event! It’s always a pleasure to return for the Summer Camps – it was already my third time there and I’m already looking forward for the fourth one…

Veröffentlicht unter BPM & System Integration, Cloud & Infrastructure | Verschlagwortet mit , , , | 1 Kommentar

Neuer Cloud-Trend auf dem Prüfstand: Ist Serverless-Computing ein Vendor Lock-In?

Die Entwicklung, dass sich immer mehr Verwaltungsaufgaben zum Cloud Anbieter verlagern, ist bereits seit einiger Zeit zu beobachten. Die aktuellste Weiterentwicklung in diesem Bereich wird als „Serverless“ bezeichnet und ist derzeit in aller Munde. Der bekannteste Serverless-Computing-Dienst ist dabei wohl „Lambda“ von Amazon Webservices (AWS). Das Pendant dazu von Microsoft heißt „Azure Functions“. Serverless-Computing bietet dabei einige Vorteile gegenüber dem „klassischen“ Entwicklungsmodell. Hier wird die komplette Umgebung (Physikalische Maschinen, Betriebssystem, Laufzeitumgebung, …) durch den Cloud Anbieter verwaltet. Dies erlaubt es dem Entwickler, sich voll auf die Implementierung seiner Anwendung zu konzentrieren. Bei der Entwicklung von Anwendungen in diesem Umfeld stellt sich jedoch auch die Frage, wie stark man sich bei der Entwicklung einer Anwendung in diesem Umfeld, vom jeweiligen Cloud Anbieter abhängig macht und ob eine Migration zu einem anderen Anbieter (mit vertretbarem Aufwand) möglich ist. Gründe für einen Anbieterwechsel könnten zum Beispiel Kostenvorteile oder sich ändernde rechtliche Rahmenbedingungen sein. Dieser Frage nach der Anbieter(un)abhängigkeit bin ich im Rahmen meiner Bachelorarbeit bei OPITZ CONSULTING nachgegangen, indem ich ein kleines Beispielprojekt von AWS zu Azure migriert habe. Ein Teil der Ergebnisse soll im Folgenden kurz vorgestellt werden.

Kompatible Programmiersprache

Zunächst einmal fällt bei einem Vergleich auf, dass Azure Functions und AWS Lambda nicht die gleichen Programmiersprachen unterstützen. Derzeit werden nur diese Programmiersprachen von beiden Anbietern unterstützt: JavaScript bzw. NodeJS, Python und C#. Verwendet man eine andere Programmiersprache bleibt einem im Falle einer Migration nichts anderes übrig, als den kompletten Code neu zu schreiben. Daher empfiehlt es sich eine dieser Sprachen zu verwenden. Das Angebot wird jedoch stetig ausgebaut.

Der Functionhandler

Des Weiteren unterscheiden sich die Functionhandler, also die zu implementierende Schnittstelle, der beiden Anbieter leicht voneinander. Dies sind jedoch hauptsächlich Unterschiede in der Namensgebung der Attribute bei  Objekten, welche beim Aufruf übergeben werden. Hier müssen im Falle einer Migration die Namen entsprechend abgebildet werden. Eine von Beginn an saubere Trennung der Implementierung der Schnittstelle von der eigentlichen Geschäftslogik erleichtert diesen Schritt enorm. Vereinzelt unterscheidet sich auch die Formatierung der Werte, zum Beispiel der Pfad der aufgerufenen HTTP-Schnittstelle, falls man die Funktion über eine solche aufruft. Diese müssen dann ebenfalls angepasst werden.

Integration weiterer Dienste

Anders sieht es hingegen aus, wenn man spezielle Dienste von AWS wie DynamoDB oder S3 verwendet. Abgesehen von der Migration des jeweiligen Dienstes müssen dann nämlich sämtliche API-Calls in Lambda angepasst werden (also jeder Zugriff auf einen angebundenen Dienst!), wenn man das gesamte Projekt migrieren möchte. Auch hier kann eine saubere Kapselung dieser API-Calls im Falle einer Migration viel Aufwand vermeiden und die eigentliche Geschäftslogik unberührt lassen. Abhilfe kann hier das Verwenden von anbieterunabhängigen Services wie MongoDB zur Datenspeicherung anstelle von DynamoDB schaffen, da man dann die jeweiligen API-Calls nicht weiter anpassen muss. Dies bringt aber wiederrum den Nachteil mit sich, dass man auf die Vorteile des vollständig verwalteten Datenbankservices DynamoDB verzichtet. Hier gilt es im Einzelfall abzuwägen ob man dies in Kauf nehmen möchte. Um eine Migrationsfähigkeit des Gesamtprojektes sicherzustellen, muss natürlich jeder verwendete Dienst mitbetrachtet werden.  Im Falle des Beispielprojektes stellte der Dienst „Cognito“ ein Vendor Lock-In dar, da es (zu diesem Zeitpunkt) nicht möglich ist, das Nutzerverzeichnis zu exportieren oder auf andere Art zu migrieren.

Fazit

Die Serverless-Computing-Dienste AWS Lambda und Azure Functions stellen grundsätzlich kein Vendor Lock-In dar und  die entsprechenden Funktionen lassen sich aus Entwicklersicht relativ leicht migrieren. Das Problem bilden vielmehr herstellerspezifische Dienste, auf die man aus der Funktion heraus, über die API, zugreift.

 

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

Oracle Data Integration Cloud Service

Hi everyone,

in May and June I wrote my Bachelor thesis in cooperation with the OC|Lab about „Nutzung einer Datenintegrationsplattform am Beispiel einer Cloudlösung“ (utilization of a data integration platform cloud service).

Within this thesis I did research about data integration itself, the concept of data integration platforms, Cloud computing overall and the existing synergies when using these platforms as cloud service. Furthermore I focused on the challenges of data integration in companies with various data sources all over the complex system landscape especially when facing Big Data scenarios.

After finishing the theoretic part I looked at the “Oracle Data Integrator” as data integration platform. Afterwards I used the on-premise ODI to implement a mapping that integrates data from different sources into a target database to show some of the functionalities of the tool. Then I started to examine the Oracle Cloud to provide the ODI Cloud Service. In this part I focused on the requirements and the provisioning on the different layers to implement the tool as Cloud Service.

If you’re interested in the Oracle Data Integration Cloud Service or the provisioning of Cloud Infrastructure stay tuned! I’m currently working with some colleges on a Webcast and Factsheet about these topics. The content will include the findings of this thesis e.g. the comparison of the on-premise ODI and the Cloud Service or the setup of the Cloud Stack.

Here is a Link if you want to sign up for a Newsletter: http://www.opitz-consulting.com/einzelseiten/newsletter-anmeldung.html

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