From Jekyll to Hugo, from Travis to Gitlab: a time for changes

         · ·      · · · · ·

Intro In the last 50 days I had to work a lot for many… many different reasons. The main ones: I was accepted as a Speaker at FullStackConf19 in Turin, talking about coding in mobility. You can find the slide of my speech here and the material I prepared the talk in this Github repo. By the way, I was truly inspired by some of the talks during the conference, and I started brainstorming around the next post; I moved back to Italy and trust me -> it was a pretty complex goal to achieve, with particular regards to my car; I joined Enerbrain and I’m really having fun with theme building smart-energy solution as a Devops Engineer; I joined a softball team - yes, it’s mixed, but it’s officially played also by men hahe.


My team run VSC in the browser and they are just fine - Part II

         · ·      · · · · · · ·

Introduction In the first part of this series - I run VSC in the browser and I was just fine - I wrote many stupid things around the possibility of having a VSC server instance running inside AWS over a simple, immutable, ec2 instance. The template {that can be easily deployed by a Lambda function [that can be easily deployed behind a route53 record (that can be easily placed as the endpoint of a custom Slack action)]} let you start your IDE and code from wherever you would like to.


I run VSC in the browser and I am just fine - Part I

         · ·      · · · · · ·

Introduction Serverless and managed things are the best choices if you don’t want to deal with infrastructure (3 2 1: fight) buuuuut…even immutable things are not so bad for this purpose - at least, if they are immutable for real ๐Ÿคฃ Today I wanna talk about a useful way to run an instance(s) of VSC server in AWS and code from everywhere (yes, even your iPad): let’s start! This time I will go native: so no CDK, I’m sorry, but pure Cloudformation instead.


A serverless OCR with Polly and Rekognition unveils the power of stack inheritance in CDK

         · ·      · · · · · ·

Introduction In the last two weeks, I released a few CDK stacks: I made some experiments around API Gateway and service integration that came out in two serverless forms, the Contact Form and the Upload Form, read to be deployed in your static web page ๐Ÿ˜Ž. Actually, with CDK you can do so much more and so much more easily. The last stack I released - a producer-consumer chain presented here - it was a way I used to introduce how you can leverage Typescript inheritance to recycle an old stack and build on top of it.


SQS Extended: a serverless producer/consumer chain

         · ·      · · · ·

Introduction A few days ago I wrote about a simple stack that leverage API Gateway and Lambda-proxy integration to create a safe upload endpoint to let unknown users push inside a bucket of your choice. The stack I will present today is can be used to build a producer-consumer chain, by implementing the SQS Extended pattern you can find in AWS exams. For the most curious, here you can find the core code.


Build an upload form with 45 lines of Typescript

         · ·      · · · ·

Introduction The AWS CDK is becoming day by day pretty easy to use. I use Typescript, and today I will talk about a common use case: a simple Upload Endpoint for your API Gateway than like a LEGO can be built with a few instructions and of course…without the need of any server. For the most curious, here you can find the core code. Scenario You want to provide an endpoint to upload object: where?


How to deploy a serverless contact form with API Gateway, DynamoDB and SNS

         · ·      · · · ·

Introduction Hi everybody, thanks for the claps, it was a great month - rain rain rain again - now I’m back. The only GOOD THING of this terrible May is that AWS CDK came to simplify our life and I started using it (just a little) bit - still, enough to say, sincerely: it’s awesome. I used the Typescript version, everything is broken 2 release out of 3 but the time you save exploring the interfaces instead of looking for Cloudformation documentation online worths the time spending in troubleshooting the ongoing changes.


From Cloudformation to CDK: the good, the bad and the evil

         · ·      · · · · ·

Prelude As you know might be aware of, AWS has quite recently delivered - but it’s still in beta - the AWS Cloud Development Kit (CDK). Indeed, you should also know that I more recently migrated my blog to AWS as part of my migration strategy to the clouds - where my head already sits since 1991. Since I was using a Cloudformation stack though together with one of my colleagues, and since I did some manual changes to it - breaking the rules, I know - I decided it was a good moment to give a chance to CDK.


A serverless blog using CodePipeline, s3 and CloudFront

         ·      · · · ·

Goodbye old blog ๐Ÿ˜ญ๐Ÿ˜ญ I disapperead for a while because as you should notice, first of all - I have a new domain. HAHA. It’s not the first one I own, but to be honest it’s the first time I use a domain for myself. So as I was saying yes, this post is about a migration. Morever, since this is the very first cross platform cross domain blog post - I want to share with you what I learnt and what is still missing, how I did what I did but mainly how someelse did what I didn’t.


DRY, immutable, opinionated, agnostic

         · · ·      · · · · · · · · · ·

Prelude As far as I know there are many ways to create today in IT. What is becoming more difficult is doing it properly and taking the right decisions but (spoiler)... But... I'm starting feeling that my repository is on the right direction to be self.deployable and agnostic. Above the infrastructure, which is provisioned by terragrunt and terraform, one or more actor(s) is placed (i.e. Jenkins, but whoever it is), the actors will be redeployed, the pipelines restored and they will start redeploy applications (even pieces of infrastructure with dependencies) on their behalf to the various parts of the infrastructure.