The AWS CDK has been presented on reInvent 2018. Its mission is to simplify develop infrastructure as code. There are several other frameworks, as discussed here on the blog in tRick. So there are some competitors… Can you use shiny new CDK also for serverless lambda applications? Big “Yes” from my side, but read for yourself…
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?
