Recent Articles on the tecRacer AWS Blog

Note: An updated version of this post is available here Building Lambda Functions with Terraform Introduction Many of us use Terraform to manage our infrastructure as code. As AWS users, Lambda functions tend to be an important part of our infrastructure and its automation. Deploying - and especially building - Lambda functions with Terraform unfortunately isn’t as straightforward as I’d like. (To be fair: it’s very much debatable whether you should use Terraform for this purpose, but I’d like to do that - and if I didn’t, you wouldn’t get to read this article, so let’s continue)

Vergleich Infrastructure as Code (IaC) Frameworks - tRick Ein Toolvergleich für Infrastructure as Code. Um effektiv AWS oder generell Cloud Ressourcen zu erzeugen, verwendet man zur Erhöhung des Automatisierungsgrades “Infrastracture as Code”, d.h. die Server, Datenbanken usw. werden in einer Sprache kodiert. Dieser Vorgang wird sinvollerweise über ein Framework, welches Tools dafür zur Verfügung stellt unterstützt. Aber für welches Tool/Framework entscheidet man sich? Hier werden wir mit Dimensionen für den tRick Benchmark Entscheidungshilfen geben.

Heute haben wir den aws-blog.de auf serverless migriert. Dabei haben wir Geschwindigkeit und Stabilität gewonnen!

Lambda - breaking Update - testen Sie Lambda mit binären Bibliotheken jetzt auf Kompatibilität! AWS hat gestern am 14.Mai angekündigt, dass die Laufzeitumgebung von Lambda aktualisiert wird auf Amazon Linux AMI 2018.03. Upcoming updates to the AWS Lambda and AWS Lambda@Edge execution environment | AWS Compute Blog Das bedeutet, wenn Sie Lambda Funktionen verwenden, die mit binären Bibliotheken arbeiten, kann es sein, dass Sie diese neu kompilieren müssen. Reine Scriptsprachen und die meisten Funktionen sollten problemlos weiterlaufen.

Jenkins als Build Server erfreut sich einer großen Verbreitung. Die architekturelle Frage, die sich dabei stellt ist: Wie groß lege ich den Server aus, damit er neben des Management der Build Projekte auch die Builds selber verarbeiten kann? Die einfachste Antwort darauf ist ja: AWS CodeBuild verwenden, aber wenn das nicht geht? Dann bietet das EC2-Plugin eine dynamische Lösung mit AWS Mitteln: Die Worker Knoten werden vollautomatisch dynamisch als EC2 Instanzen erzeugt und wieder abgebaut.

tl;dr - asynchrone Programmierung ist sehr viel schneller als sequentielle Aufrufe. Insofern stimmt das Pferdebild gar nicht, aber ein einzelnes Pferd sieht halt nicht so spannend aus… Außerdem bin ich selber über die Unterschiede in der Ausführungszeit überrascht… Eine Analyse am Anwendungsfall “wie bekomme ich den Überblick über AWS Resourcen über alle Regionen mit minimaler Ausführungszeit. Am Rennen nehmen teil: node, python und go. Und - um die Aufschreie der jeweiligen Fans vorwegzunehmen - es geht mehr um das Paradigma asynchron als um die Sprache. Ganz nebenbei seht ihr die AWS SDKs im Vergleich! Aber lest selbst

AWS hat Chef als Technologiepartner. Da nicht nur AWS Chef in ihren Services wie OpsWorks oder OpsWorks Chef Automate nutzt, sondern auch wir, möchte ich eine kurze Einführung von Chef und Test-Kitchen geben. In diesem Teil werden wir feststellen, wie schnell es geht, ein Testsystem mit den richtigen Mitteln zu erstellen. Im nächsten Teil werden wir das Ganze noch weiter verfeinern. Chef Cookbooks und Kitchen Warum Chef und was hat das mit AWS zu tun?

Lambda: Node 6.10 End of Lifetime - welche Funktionen sind betroffen? Heute kam eine Abkündigung für die Unterstützung von node 6.10 per Mail von AWS. “AWS Lambda: Node.js 6.10 will soon be EOL, please migrate your functions to a newer runtime version [AWS Account: 123456789012] " Da stellt sich mir doch die Frage: “Was ist die effektivste Methode die Runtime von Lambda Ressourcen herauszufinden?” Dazu will ich mal ein paar Methoden vorstellen. Es sind auch ein paar (noch) unbekannte dabei… Aber lest selbst