Sveriges Radio

Sveriges Radio tecknar ramavtal med Developers Bay inom fyra olika områden

Developers Bay har vunnit Sveriges Radios upphandling som ramavstalsleverantör av kompetens inom IT. Avtalet gäller de kommande två åren inom områdena “Apputveckling”, “Systemutveckling”, “Uppdrag/förvaltning” samt “Digital produktdesign (UX/UI/Tjänstedesign)”. 

“Vi på Developers Bay är mycket glada och förväntansfulla för att få möjligheten att matcha rätt konsulter till Sveriges Radio de kommande åren och upprätthålla ett kvalitativt och hållbart samarbete.” säger Inti Basantes, ansvarig för Offentlig sektor hos Developers Bay. 

Developers Bay är en agentur och nätverk för Sveriges främsta frilansare inom tech med målet att skapa den bästa konsult upplevelsen för både konsulter och kunder.

Kontaktperson: Inti Basantes / inti@developersbay.se tel. 0738 730383

Missa ingenting.

Prenumerera på vårt nyhetsbrev. Vi lovar att bara skicka relevant information och aldrig spamma dig.


    My Morning Routine - How Successful People Start Every Day

    DevBay

    Skriven av Erik Svensson. Inspirerad av Benjamin Spall and Michael Xander.

    Stapplar du dig ur sängen på morgonen och känner dig överväldigad inför dagen framför dig?

     

    Detta är inget bra sätt att starta en morgon om man ska lita på Benjamin Spall och Michael Xander, författarna av denna bok. Deras forskning visar att en målmedveten och omsorgsfull morgon gör dig redo för dagen framför dig. Förutom förslag på användbara morgonritualer tas även tips från framgångsrika människor såsom OS-medaljörer och VD:ar i framgångsrika bolag upp för att ge inspiration till att utveckla din egen rutin. 

    One-size-fits-(almost)-all 

    Att stressa igenom de första timmarna på morgonen hjälper dig inte att möta dagens utmaningar, så långt är vi nog alla överens. 

    En morgonrutin kommer inte i en one-size-fits-all. Vad som funkar för en annan kanske inte är rätt för dig. Ditt jobb, din personliga rytm eller om du har barn styr hur du startar din dag och hur du kommer att möta dina dagliga sysslor eller inte. 

     

    Kort och gott: den första timmen på dagen, när den nu inträffar, sätter tonen för resten av dagen. 

     

    Att snooza eller inte snooza 

    Om du är en av dem som ej klarar av att vakna tidigt för att utföra dina viktigaste sysslor innan dagen startar så rekommenderar då författarna att steg för steg nå ditt mål för att ge rum för just detta. Ställ väckarklockan fem minuter tidigare varje vecka och upprepa detta tills du har tid att utföra din tänkta morgonrutin. 

    – För att tala om motsatsen till denna teknik så gäller det självklart det gamla(?) ordspråket: ”you snooze you lose” – genom att använda denna funktion på ens väckarklocka så blir man garanterat mer trött och seg än första gången larmet går. Välj alltså hellre att ställa klockan tidigare än att senarelägga ditt uppvaknande nästa gång.

     

    Skulle nu den inkrementella taktiken fallera eller frestelsen för snooze ta över finns det två enkla sätt som garanterar ett tidigt vaknade. Skaffa barn eller hund – eller varför inte båda? 

    Att göra-lista 

    De av oss som kategoriserar sig som morgonmänniskor tycker att de arbetar mest produktivt under dygnets första timmar. Oavsett om du hör till den gruppen eller inte ska denna tid alltid präglas av fokus och en klar intention. 

     

    Skapa en att göra-lista på kvällen inför morgonen därpå. Genom att skriva ner saker så frigör du minnet (tänk datorns motsvarighet – RAM) och kan på så sätt slippa tänka på vad som ska göras härnäst. Författarna rekommenderar vidare att begränsa denna lista till 5-6 saker. Välj de mest kritiska sakerna att göra först och senarelägg mindre tankekrävande uppgifter såsom planering av telefonsamtal och möten till senare på dagen. 

     

    – Här kan jag själv rekommendera Google tasks som fungerat utmärkt för mig. Jag får möjlighet att se mina uppgifter i både mobilen och datorn men även att enkelt skriva ned saker så fort de kommer upp i tankarna. Perfekt för bland annat kundmöten och när man är ute på uppdrag! 

     

    Att inleda morgonen med att kolla mejl är generellt ingen god idé. Detta överlåter din kontroll till att i stället besvara andra personers frågor och behov. Däremot väljer Rafael Reif, presidenten för MIT, att göra motsatsen och menar att detta låter honom svara på viktiga meddelanden som kommit in under natten genom att snabbt kolla igenom sin inkorg. Meningarna går således isär men så länge vi inte har en position med samma globala ansvar som Rafael så kan vi nog ägna vår morgonstund till att fokusera på oss själva – deal? 

    Svettig morgonrutin 

    Att lägga in ett träningspass i din morgonrutin är ett utmärkt val, vissa föredrar hellre att träna senare på dagen men återigen gäller det här att hitta något som passar ens egna dagliga schema. Håll dig till det som funkar för just dig menar författarna. Finessen med att välja ett träningspass i ens morgonrutin ger, oavsett dagens utmaningar, en bekväm känsla av att man säkrat sin träning för dagen och förhoppningsvis känns alla utmaningar under resten av dagen som en baggis. 

     

    Ytterligare ett förslag till din arsenal är meditation. Det förbättrar koncentrationen, höjer fokus och sänker stressen men hjälper dig även att sova bättre. Om du inte gillar den traditionella meditationen kan du även använda guidad meditation. Du kan också öva att vara närvarande när du exempelvis kokar vatten eller brygger kaffet och låta tankarna vila – genom att släppa annat för stunden ger du tankarna en paus och du får alla tänkbara fördelar som nämnts ovan, bra eller hur? Meditation kan ses som ett sätt att sätta problem i perspektiv och framhäva tacksamhet för allt som livet har att erbjuda.

     

     

    Sugen på något nytt? Bli medlem i Developers Bays nätverk för frilansare idag! https://developersbay.se/frilansare/ 

    Ordning och (o)reda

    Alla har inte lediga kvällar, men om du brukar tillbringa kvällarna hemma välj då att använda tiden klokt i stället för att slötitta på TV. Vissa föredrar att arbeta på natten, men även om du är en nattuggla bör du använda en rutin innan läggdags, mer om detta i nästa stycke. Exempel på fördelaktiga rutiner kvällstid inkluderar: välja ut kläder för nästa dag, göra i ordning sina träningskläder, skriv att göra-listor i slutet av arbetsdagen och granska nästa dags schema. 

     

    – Här anser jag att det gäller att inte överväldiga sig själv, kollat enbart på nästa arbetsdag. Att vakna upp till ordning ger lugn, välj därför att städa upp innan du lägger dig och förbered kaffebryggare – om du jobbar hemifrån. Den tid du spenderar med att varva ner på kvällen öppnar möjligheter att fokusera de tysta morgontimmarna på saker som verkligen betyder något, mer om detta längre ned. 

     

    En god natts sömn 

    Något annat som också kanske känns självklart men som är värt att poängtera är vikten av en god natts sömn som ger energi för morgonrutiner och tillåter dig att maximera din dag. Hur uppnår man detta? Enkelt, genom att sova tillräckligt. Något som jag själv tummat på rejält – speciellt när det finns så mycket jobb man enkelt kan bränna av just på grund av tillgängligheten till telefonen – är att hålla sovrummet en digital frizon.

     

    Jag är säker på att alla redan hört detta, men det blåa ljuset är boven i dramat. Den påverkar vår dygnsrytm (circadian rhythm) och aktiverar vår kropp då den misstar ljuset för dagsljus. Vill du läsa mer om detta så rekommenderar jag boken Why We Sleep av Matthew Walker. En bra milstolpe som kan underlätta är att hinna med “midnattståget” som författarna kallar det d.v.s. somna innan midnatt. 

    Laget före jaget 

    När familjen och främst barn kommer in i ekvationen är det lätt hänt att det tummas på rutinerna eller att de helt enkelt kastas bort totalt. För er med barn som läser detta så finns det mycket att vinna på att vakna innan barnen för värdefull egentid enligt författarna. När väl resterande familj vaknar så gäller även här en digital frizon. Hur många gånger har man inte hört föräldrarna säga att uppväxten av barn gick för fort – tänk då hur fort det går när även telefonen tävlar om din uppmärksamhet?

     

    Om du inte redan är såld på detta kan det vara värt att nämna att bland annat en av Twitters medgrundare umgås med sina barn en timme innan jobbet – kanske är detta en rutin värd att prova?

    Tillbaks på ruta ett

    Varje morgon erbjuds möjligheten att påbörja ett oskrivet blad och även en nystart. Genom att just ta hand om dina egna behov innan allt annat på morgonen ger du dig lugnet som behövs för att kunna svara på dagens alla utmaningar. Din egentid på morgonens s.k. tysta timmar är både värdefull och bidrar också till ditt välmående. 

     

    – Här kan jag själv tycka att just tanken att få klart en riktigt klurig uppgift eller ett tungt träningspass innan dagens ens börjat för omgivningen är svårslagen. Det ger även ett försprång och det är inte helt ovanligt att dagens sysslor redan är färdiga innan lunch på grund av ett uppbyggt momentum. 

     

    Detta summerar boken “Morning Routines” men även fördelarna med just rutiner i ett bredare perspektiv. Avslutningsvis kommer här ett citat från Thomas Carlyle som sägs ha kopplingar till rutiner: 

     

    “A man without a goal is like a ship without a rudder.” 

     

    Glöm inte heller att bli medlem på https://developersbay.se/frilansare/ för att ta del av de senaste uppdragen som frilansare! 

     

    Hälsningar, Erik

    Missa ingenting.

    Prenumerera på vårt nyhetsbrev. Vi lovar att bara skicka relevant information och aldrig spamma dig.


      How to use Azure Container Registry in Kubernetes

      DevBay

      Written by Mehrdad Zandi

      What is Azure Container Registry (ACR)

       

       

      Azure Container Registry (ACR) is a private registry service for building, storing, and managing container images and related artifacts like as Dockerhub. ACR is used specially by Enterprises which don’t want to have their containers on a public share.

      ACR comes in three pricing tiers: Basic, Standard, and Premium. The main difference between them is the amount of included storage and the number of webhooks you can use. Additionally, the premium tier supports geo-replication. This means that your images are still available when a data center goes down.

      In this post, I will describe  how to create ACR,  how to upload images to ACR, and how to pull images from ACR by configuring your Microservice and  Azure Kubernetes cluster  to run them in your  Kubernetes cluster.

      Prerequisites

       

      Create Azure Container Registry in the Azure Portal

      I have described in my post Azure Container Registry (ACR) , how to create and how to push image to ACR. You  can create ACR by looking to this post.

      Here I have  created ACR with name: mehzanContainerRegistry with Resource Group: mehzanRSG, in Region: Sweden Central.

      Pushing Image to ACR

      You have two alternative to push image to ACR:

      • Alternative 1: importing the image from Dockerhub.
      • Alternative 2: uploading it from a CI/CD pipeline.

      I am going to describe the both alternatives in this post

      Alternative 1: Import Image from Dockerhub into ACR

      To import the image, use the following Azure CLI commands: (run az login first and then az acr import ..)

      az login
      az acr import --name mehzancontainerregistry --source docker.io/mehzan07/productmicroservice:latest  --image productmicroservice:latest

       

      The first line logs you into your Azure subscription and the second one takes the name of your ACR (name should be lowercase), the source image from Dockerhub, and the image name which will be created in ACR .

      In here I have taken the  productmicroservice  image from my Dockerhub:  docker.io/mehzan07. (Your image should be exist in the your Dockerhub, otherwise you can push it from your local).

      If importing is succeeded then navigate to your  ARC registry in the  Azure portal and select Repositories, then you can see productmicroservice (as shown in the following figure)If you double click it shows tag: latest.

      azure-container-registry-in-kubernetes-22.png
      Importing Image: productmicroservice from Dockerhub to ACR

       Create Azure Kubernetes Service (AKS)

      You have to  create an Azure Kubernetes Service (AKS), To Create AKS look to my post: Azure Kubernetes Service (AKS)

      I have created AKS with name: microservice-aks with Resource group: mehzanRSG in Region: Sweden Central ( in the same Resource group and and same Region for ACR which I have created in this post).

      Note: I haven’t create any Services and Progress yet, I shall create this later on.

      Pulling Image from Azure Container Register to Kubernetes (aks)

      To pull this image from kubernetes we should authorize Kubernetes to pull images from ACR.

      Kubernetes is not authorized to pull the image. This is because ACR is a private container registry and you have to give Kubernetes permission to pull the images.

      Allowing Kubernetes to pull ACR Images

      To allow Kubernetes to pull images from ACR, you first have to create a service principal and give it the acrpull role.

      Service principals define who can access the application, and what resources the application can access. A service principal is created in each tenant where the application is used, and references the globally unique application object. The tenant secures the service principal sign-in and access to resources. For more about  Service Principal.

      Use the following bash script to create the service principal and assign it the acrpull role.

      1- Run the following script on Azure CLi command (start from portal):

       

      ACR_NAME=mehzancontainerregistry
      SERVICE_PRINCIPAL_NAME=acr-service-principal
      
      ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query id --output tsv)
      
      PASSWORD=$(az ad sp create-for-rbac --name $SERVICE_PRINCIPAL_NAME --scopes $ACR_REGISTRY_ID --role acrpull --query "password" --output tsv)
      USER_NAME=$(az ad sp list --display-name $SERVICE_PRINCIPAL_NAME --query "[].appId" --output tsv)
      
      echo "Service principal ID: $USER_NAME"
      echo "Service principal password: $PASSWORD"
      

      Where the mehzancontainerregisry is the ACR name which we have created in the beginning of this post.

      Note: If running of copy of this script is not worked  then you should first copy and paste it to notepad and then take from there to run in the Azure CLI.

      If it is succeed then output will be like as following:

      Service principal ID: f8922aa7-81df-48a5-a8c6-5b158edb6072
      Service principal password: oDm8Q~eVBH-15mE25t3EIqyTt0pc87UWmhVURaIM

      Save these Service principal ID and  Service principal password: and use them in the next step (in the following).

      2- Next, create an image pull secret with the following command  in the command line:

       

      kubectl create secret docker-registry acr-secret  --namespace default --docker-server=mehzancontainerregistry.azurecr.io --docker-username=f8922aa7-81df-48a5-a8c6-5b158edb6072  --docker-password=oDm8Q~eVBH-15mE25t3EIqyTt0pc87UWmhVURaIM

      where  docker- server value (mehzancontainerregistry.azurecr.io) is ACR Service and it is created with creating of ACR in the beginning. namespace: as default,  docker-username: the Service principal ID  value  and docker password f Service principal password value from the step 1.

      If it succeed the output will be: “secret/acr-secret created “

      namespace value can be found from Ks8: dashboard as shown in  the following figure:

       

      azure-container-registry-in-kubernetes-11.png
      Namespace: default on ks8: dashboard on top-right dropdown.

      3- Use the Image Pull Secret in  your Microservice (productmicroservice)
      After the image pull secret was created, you have to tell your microservice to use it.  I  have used the values.yaml  file (under charts:productmicroservice) for values, as  following code:

       

      imagePullSecrets:
        - name: acr-secret

      I have build image and pushed to  my dockerhub before importing of image. The Source code can be found in my Github.

      If you used a different name for your secret in the kubectl create secret docker-registry, then you have to use your name instead of acr-secret.

      4- Copy the following yaml  in somewhere in your local machine and give a file name (like as : acr-secret.yml)

       

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: productmicroservice 
        namespace: default
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: productmicroservice 
        template:
          metadata:
            labels:
              app: productmicroservice 
          spec:
            containers:
            - name: mehzancontainerregistry
              image: mehzancontainerregistry.azurecr.io/productmicroservice:latest
              imagePullPolicy: IfNotPresent       
            imagePullSecrets:
             - name: acr-secret

      And run it in the following kubectlcommand as follow:

       

      kubectl apply -f path\filename.yml

      I have saved the script in acr-secret.yml in the path C:\Utvecklingprogram\Kubernetes\

      And run it as following  command line from my local machine

       

      kubectl apply -f C:\Utvecklingprogram\Kubernetes\acr-secret.yml

      If it succeed the output shall be: pod/productmicroservice created

      where name: productmicroservice is the pod name of productmicroservice in the kubernetes (shall be seen in KS8: dashboard) and containers: name: mehzancontainerregistry   is the ContainerRegistry name we have created in Azure (the name should be lower case). The image: mehzancontainerregistry.azurecr.io/productmicroservice:latest  is the image in the Container Registry Service from Azure which we have imported from my Dockerhub.

      Test the pulling image from Kubernetes (aks).

      Connect to the K8s dashboard (by starting Octant from your local machine) If you have not installed Octant look to the my post: azure-kubernetes-service-aks

      Start Octant from your local machine(start menu) and click on the  Workloads: Pods, the following shall be displayed:

       

      azure-container-registry-in-kubernetes-8
      Pod: productmicroservice is pulling from ACR and Running.

      Look to the Config and Storage: Secret:

       

      azure-container-registry-in-kubernetes-9.png
      Config and Storage: Secrets: acr-secret is ok

      As you see the acr-secret is created in your KS8 service.

      Look to the Events:

      azure-container-registry-in-kubernetes-10.png
      Event shows pod: productmicroservice is created 

      If we check the Services on the KS8: dashboard then we see this part is empty, because we have created only a kubernets (microservice-aks) without any  “Service and Ingress”.  Now we want to have Service and test application (productmicroservice). We can create Service And Ingress as  described  in my post: Azure Kubernetes Service (AKS)   In the section: deploy the first Application.

       

      Now go to the KS8 dashboard : Discovery and Load Balancing: Services then you can see that productmicroservice is created as following image:

       

      azure-container-registry-in-kubernetes-12.png
      Service productmicroservice is created and has External IP: 4.225.208.21

      Open browser with the external IP : 4.225.208.21, then the Swagger UI is displayed for ProductMicroservice as following:

       

      azure-container-registry-in-kubernetes-13.png
      Swagger UI inj the productmicroservice: image pulled from ACR.

      That is all.

      We have created ACR, imported image from dockerhub, created AKS Service and configured, authorized to pull from ACR and tested it with KS8:dashboard.

      In the end Cleanup all resources

      When you are finished,  delete all created resources in your Azure account. AKS creates three additional resource groups. Make sure to delete them too. Delete all resource groups.

      Conclusion

      In this post I have created an Azure Container Registry (ACR) in Azure Portal and Imported image from Dockerhub to ACR. Then I have created an Azure Kubernetes Service (AKS) and Authorized it to access to pull image from ACR. In the end I have tested it in KS8 dashboard (Helm octant), which shows the Swagger UI is uploaded from my application (ProductMicroservices).

      All the Source code is  on my GitHub.

      Read about Alternative 2: Uploading Image to ACR from Azure DevOps Pipelines here. 

      About the author

       

      Mehrdad is Consultant as System developer and Architect in Microsoft stack: .NET Platform, C#, , .NET Core, Micoroservices, Docker Containers, Azure, Kubernetes Service, DevOps , CI/CD, SQL Server, APIs, Websites, and more
      In Frontend: HTML, JavaScript, CSS, jQuery, React, and more.
      In addition I can build Websites by WordPress.

      Missa ingenting.

      Prenumerera på vårt nyhetsbrev. Vi lovar att bara skicka relevant information och aldrig spamma dig.


        Setup a Terraform backend on S3 with AWS CloudFormation and CDK

        DevBay

        Written by Renato Golia

        Terraform is one of the most popular Infrastructure as Code (IaC) tools. Like other IaC tools, it lets you define a descriptive model of your cloud infrastructure and store it in one or more text files. This model describes the desired state of your infrastructure and can be used to reliably deploy, version and update your system.

        It uses persisted state data to keep track of the resources it manages. Most production-grade configurations store this state data remotely allowing multiple people to access the state and work together. Also, remotely storing the state increase security because it avoids relying on the computer of the person working on the cloud infrastructure.

         

        Since Terraform is cloud-agnostic, it supports storing the state data in many different ways. Terraform uses the term backend to refer to the system used to store the cloud resources state data and it supports many providers out-of-the-box. Among the many options, one can choose to leverage AWS to store the state data.

        The backend using AWS requires an S3 bucket and, optionally, a DynamoDB table to enable state locking to avoid collisions between multiple actors.

        We can use the AWS console to create these resources. Once done, we can instruct Terraform to use them by defining a backend element.

         

         

        terraform {
            backend "s3" {
                bucket = "terraform-state"
                region = "eu-north-1"
                key = "path/to/terraform.tfstate"
                dynamodb_table = "terraform-state-lock"
            }
        }
        

        Now we can use the CLI tool to let Terraform initialize our backend.

        $ terraform init
        

         

         

        This will create in our bucket a file containing the state of the system represented in our Terraform application. Now, we can add resources and reliably deploy them in the cloud.

        As usual, I’m skipping the authentication and authorization bits needed to deal with AWS.

         

        So, everything works. We can create new applications and let Terraform take care of creating and configuring the resources and, most importantly, persist the state file in the shared bucket.

        But the more I got used to Terraform or any other IaC tool, the more I got weary of that S3 bucket and DynamoDB table created via the console.

        The Problem

        Can we use Infrastructure as Code to define the infrastructure needed by Terraform to operate?

        Short answer is yes. We can definitely use Terraform to define and deploy a S3 bucket and a DynamoDB table, as shown in this post by The Lazy Engineer.

        This would define an infrastructure of a higher order. The problem is that we don’t have a backend for this application and we would be relying on tracking its state on our computer.

        Staggered deployment

        Looking for a solution, I found this blog post by Shi Han.

        In his post, the author suggests using a staggered deployment approach. They first deploy the S3 bucket, then configure the backend to use it and then reconfigure the application to use the bucket to store the state of the bucket itself.

         

        The name they give to the paragraph, The chicken-and-egg problem, is definitely fitting.

        Even if it works correctly, I’m not really satisfied by this solution.

        Shi Han’s solution is based on a trick that contraddicts one of the corner stones of Infrastructure as Code: your code files should be a valid representation of your system at any given time.

        CloudFormation and CDK

        How do you break a chicken-and-egg problem? You change the context. If Terraform can’t be used to set up the infrastructure it needs, we can look at other tools. At first I was looking at other backend providers to be used for our higher-order architecture but none of the alternatives caught my eye.

         

        I eventually decided to leverage CloudFormation and its CDK (Cloud Development Kit).

        While I am not enthusiastic about using two different techonologies (CloudFormation and Terraform) for the same job (i.e. describe my cloud infrastructure), I am happy enough because:

        • CloudFormation is available to all AWS accounts, with no extra setup
        • The CDK makes it easy enough to work with CloudFormation by hiding all its quirks
        • I consider it acceptable to use different technologies for two different level of abstraction

         

        Careful readers would be wondering if we really solved the chicken-and-egg problem. The answer is yes because CloudFormation takes care of persisting the state of the applications it manages (stacks in CloudFormation’s lingo) in resources already created.

        So, let’s see how we can leverage the CDK to define and deploy the infrastructure needed by Terraform’s backend. Specifically, I’ll be writing a CDK application using the C# template.

        Preparation

        Let’s start by installing the required runtimes needed for working with CDK.

        Let’s assume that the following tools have been installed and configured.

         

        Once these are installed, let’s install the npm tool for CDK. We can then validate that the CDK CLI is correctly installed and configured.

         

        $ npm install -g aws-cdk
        $ cdk --version
        2.51.1 (build 3d30cdb)
        

         

        Finally, before we begin using CDK to deploy CloudFormation stacks, the CDK needs some required tools to be deployed on the receiving AWS account. This process is called bootstrapping.

         

        # Bootstrap CDK for your account using `cdk bootstrap aws://ACCOUNT-NUMBER/REGION`
        $ cdk bootstrap aws://123456789012/eu-north-1
        

         

        You can read more about bootstrapping your account here

        Now everything is ready for us to create our CDK app.

        Creating the CDK app

        Let’s create our CDK app.

        We start creating a folder for the app, and then we use the CDK CLI to create an app based on the C# template.

         

        $ mkdir TerraformBackend
        $ cd TerraformBackend
        $ cdk init app --language csharp
        

        Once the template is generated, we have a .NET solution that can be customized to include the resources we need.

        Customizing the stack

        The solution contains a C# project with mainly two files:

        • Program.cs contains the code needed to initialize the CDK app.
        • TerraformBackendStack.cs contains the class that we will use to add our resources

         

        Let’s start by adding the resources to the TerraformBackendStack. To do so, we simply augment the internal constructor generated by the template.

         

         

        internal TerraformBackendStack(Construct scope, string id, IStackProps props = null)
            : base(scope, id, props)
        {
            var bucket = new Bucket(this, "terraform-state", new BucketProps
            {
                Versioned = true,
                Encryption = BucketEncryption.S3_MANAGED,
                BlockPublicAccess = BlockPublicAccess.BLOCK_ALL
            });
        
            var table = new Table(this, "terraform-state-lock", new TableProps
            {
                TableName = "terraform-state-lock",
                BillingMode = BillingMode.PROVISIONED,
                ReadCapacity = 10,
                WriteCapacity = 10,
                PartitionKey = new Attribute { Name = "LockID", Type = AttributeType.STRING }
            });
        
            new CfnOutput(this, "TerraformBucket", new CfnOutputProps
            {
                ExportName = "terraform-state-bucket-name",
                Value = bucket.BucketName
            });
        
            new CfnOutput(this, "TerraformTable", new CfnOutputProps
            {
                ExportName = "terraform-state-lock-table-name",
                Value = table.TableName
            });
        }
        

         

        In the snippet above, I add a S3 bucket whose name will be generated automatically by CloudFormation and a DynamoDB table.

        Finally, I added two outputs so that I can easily fetch the name of the bucket and of the table.

        Next, I change the Program so that the stack will be protected from any accidental termination that could be initiated by other actors or with a misclick in the Console. Finally, I make sure that all resources are tagged following my company’s policy.

         

        var app = new App();
        var stack = new TerraformBackendStack(app, "TerraformBackend", new StackProps
        {
            TerminationProtection = true
        });
        
        Tags.Of(stack).Add("Project", "TerraformBackend");
        Tags.Of(stack).Add("Environment", "Shared");
        
        app.Synth();
        
        

        With these changes, we’re ready to deploy our stack.

        Deploying the stack

        The CDK makes it very easy to deploy the stack.

        From the root of our CDK project, we simply need to run cdk deploy to intiate the creation or update of the stack on CloudFormation.

        When everything is complete, the CDK CLI will print the outputs that we defined in the TerraformBackendStack

         

        $ cdk deploy
        ...
        Outputs:
        TerraformBackend.TerraformBucket = some-very-random-string
        TerraformBackend.TerraformTable = terraform-state-lock
        

         

        Now we can use the two output values to correctly initialize our Terraform applications.

         

        terraform {
            backend "s3" {
                bucket = "some-very-random-string"
                region = "eu-north-1"
                key = "path/to/terraform.tfstate"
                dynamodb_table = "terraform-state-lock"
            }
        }
        

        Recap

        Infrastructure as Code is becoming more and more of a mindset and we should strive to always follow it. Sometimes the tooling we use has limitations that could stop us.

         

        Terraform’s support for backend infrastructure is one of the many examples. In this post, we explore how we can use AWS CloudFormation and its CDK to circumvent the issue and use IaC to create the infrastructure needed to work with IaC at non-trivial levels.

        About the author

        Renato is an expert in cloud-based distributed software architecture design and construction, with a focus on .NET and AWS. He has extensive experience in designing and building efficient CI/CD pipelines, as well as defining infrastructure-as-code blueprints.

         

        Renato also has significant management experience, having previously served as CTO and leading a team. In addition to his professional work, Renato is dedicated to contributing to the open source community and developing .NET libraries to enhance developer productivity.

         

        You can contact him on his personal blog, GitHub or LinkedIn

        Missa ingenting.

        Prenumerera på vårt nyhetsbrev. Vi lovar att bara skicka relevant information och aldrig spamma dig.


          Del 2: The 6 Critical Practices for Leading a Team

          DevBay

          Recension: Everyone Deserves a Great Manager - The 6 Critical Practices for Leading a Team (Del 2)

          Victoria Roos Olsson, Todd Davis and Scott Miller

          Hej igen! Här kommer fortsättningen av bokrecensionen “Everyone Deserves a Great Manager – The 6 Critical Practices for Leading a Team”. Vi kommer kolla vidare på strategi tre till sex, nu kör vi!

          Strategy Three: Organize your team for productivity; position it to achieve top results.

          Inleder med ytterligare ett citat: ”Om anställda gör sina jobb enbart för att deras chef sa åt dem att göra det, tar det helt och hållet bort engagemanget hos dem”.

           

          Denna strategi är tänkt till att främst sätta stopp för micro management, vid första problem eller motgång så hoppar en chef in direkt och väljer att lösa problemet själv. Detta förgör inte bara produktiviteten men hämmar även kreativitet och initiativ – varför ska den anställda lösa problemet när man ändå vet att chefen kommer hoppa in och ta över? Nu kanske du säger att det visst finns tillfällen då enbart en chef med en bättre kontakt med personer högre upp i organisationen kan lösa problemet, javisst finns det detta, men det ska inte vara det första alternativet. Detta faller tillbaka på det jag nämnde i inledningen – lita på dina anställda men även möjligheten att delegera uppgifter.

           

          Vidare så rekommenderas det att sätta upp så kallade stretched goals som anställda kan jobba på över tid och slutligen, glöm inte att fira framgångar! Mycket viktigt!

          Strategy Four: Make sure everyone on your team is receptive to and values feedback.

          Få aktiviteter är så värdefulla som att ge och ta emot objektiv feedback.  Det är därför du måste ge feedback av högsta kvalitet till dina anställda och be om feedback från dem om ditt arbete som chef och om företaget.  Gör din feedback konstruktiv, handlingsbar, specifik och ibland tuff. Även om det känns jobbigt, undvik inte det sista kravet. Jag anser själv att tuff feedback bör alltid ges på ett stöttande sätt och finns till för att utmana och utveckla den anställda.

           

          Författaren uppmanar även att se feedback som coachning och använd den för att stärka och hjälpa dina anställda. Svik aldrig dem. De måste förstå material såsom uppgifter och förändringar som kanske inte är tydliga för dem. Betona förstärkande feedback vilket nämns ovan som erkänner och bekräftar positivt beteende.

          Strategy Five: No matter what happens, your job is to guide each of your team members through events that affect them.

          Peter Senge från universitetet MIT förklarar att människor inte är emot förändring, de är emot att förändras. Låt oss acceptera det, förändringar i arbetslivet händer hela tiden. Det kan vara befordran, uppsägning, nya chefer, sammanslagning med annat bolag eller omorganisationer.

           

          Om du tidigare varit anställd så har du förmodligen tankesättet att uppnå dina resultat på egen hand, för att lyckas som en chef är det viktigt att istället kunna ställa om hjärnan till att det snarare är de anställda som är det viktiga – att ställa om och acceptera att ditt arbete inte bara handlar om dig längre är därför något av det viktigaste du måste jobba på för att lyckas som chef.

           

          Givetvis när det gäller strategin om förändring nämns fyra zoner enligt FranklinCoveys Change Model som hjälper chefer att förstå stadierna och konsekvenser av förändring när deras anställda rör sig genom dessa fyra ”zoner”:

          • ”Zone of status quo” – Detta är business as usual-zonen. För närvarande är förändringen enbart teoretisk.
          • ”Zone of disruption” – Människor börjar känna sig stressade på grund av att förändringar är på gång.
          • ”Zone of adoption” – På grund av nyligen skedda förändringar måste anställda nu göra saker annorlunda. Zon av acceptans.
          • ”Zone of better performance” – Här är förhoppningen att förändringen och även anpassningen därefter leder till förbättrade resultat.

           

          Vidare gäller det att samtidigt hålla 1-1 som nämnts i tidigare strategi. Glöm inte igen att fira när en förändring framgångsrikt går igenom.

          Strategy Six: As a leader, you have limited time and energy; use them wisely.

          Gallup rapporterar att nästan två tredjedelar av anställda ständigt oroar sig för utbrändhet. Något att hålla utkik för när du börjar märka några toppar och dalar i dina energinivåer, fråga dig då varför.

           

          För att öka din egen energinivå och även dina anställdas, utnyttja som författaren kallar det fem energidrivare. Mängden energi du har under dina vakna timmar beror på dessa fem faktorer:

          • Sömn – Alla behöver minst sju timmars sömn varje natt. För att underlätta detta kan du exempelvis träna yoga eller meditation som en lugnande aktivitet innan sömn för att underlätta att somna in och undvika det icke önskvärda, full aktivitet till omedelbar sömn.
          • Slappna av – Om du är stressad är det svårt att slappna av. Prova något vilsamt under dagen genom att ta fem minuters mental minipaus genom att andas djupt för att syresätta hela ditt system, detta får dig att må bra och bygger upp din energi.
          • Kontakter – Bli proaktiv när det gäller kvaliteten på dina vänner.  Sök efter människor som får dig att må bra, inte dåligt.
          • Rör på dig – Brist på rörelse är ett recept på en energi- och hälsokatastrof.  Att träna blir enklare att få rutin på om du ser det som en lyx, alltså något du får möjlighet att göra – och inte som en obehaglig börda eller något du måste göra.
          • Ät – Undvik bearbetade livsmedel och snabba kolhydrater. Frukt, grönsaker, nötter och bär är bäst för snabb energi. Tillgängligheten till nyttig mat hjälper dig att undvika att istället konsumera skräpmat. Men viktigaste av allt, spåra vad du äter.

           

          Håll koll på alla fem punkter ovan, om du hamnar efter i en så kan det ha en negativ inverkan på de andra områdena. Betygsätt dig själv mot varje faktor och arbeta för att förbättra ditt betyg. Kom ihåg att när du är en chef så är din energinivå inte den enda som räknas. Energinivåerna hos dina individuella anställda är minst lika viktiga. Var en positiv förebild för sunda metoder, nedan följer ett exempel på plan mot detta:

          • Känn efter ditt dagliga energibehov och planera ditt schema därefter.
          • Planera dina veckoaktiviteter.
          • Ägna fem till tio minuter varje dag till att förfina dina aktivitetsplaner.
          • Öka energinivåerna på dina möten.

           

          Ta inte på dig alla omedelbart, arbeta istället med en i taget. Med en samordnad, fokuserad och målmedveten insats kommer du så småningom bemästra var och en och bli den bra chef alla medarbetare vill ha som ledare. Med detta så avslutar jag denna bokrecension. Hoppas minst en av dessa strategier resonerar med dig och att du fann denna läsning givande. Vi hörs i nästa artikel!

           

          Glöm inte heller att bli medlem på https://developersbay.se/frilansare/ för att ta del av de senaste uppdragen som frilansare!

           

          Hälsningar,
          Erik

          Missa ingenting.

          Prenumerera på vårt nyhetsbrev. Vi lovar att bara skicka relevant information och aldrig spamma dig.


            Strategi för hybridarbete

            DevBay

            Developers Bay - Hybridarbete

            Sätt en strategi för hybridarbete

            Trots att det nu var en tid sedan vi behövde isolera oss så har det arbetsliv vi varit vana vid ändrats efter pandemin. Exempelvis är hybridarbete vanligare än någonsin.

            Forsknings- och rådgivningsföretaget Forrester har gjort flera olika studier som visar att den vanligaste modellen är att de anställda ska komma in till kontoret ett visst antal dagar i veckan. Problemet är bara att företagen inte motiverar varför.


            Men J.P. Gownder, analytiker vid Forrester, är övertygad om att hybridarbetet är här för att stanna. Även om det är osäkert vad som händer i den ekonomiska osäkerhet vi är på väg in i.

            “Vi kan inte se på distansarbete som en förmån längre – det måste bli en del av strategin”

            Det vi på Developers Bay märker i dialog med konsulter är just det som beskrivs ovan. Och de flesta ställer sig ändå positiva till att komma in till kontoret – om det finns en bra anledning att göra så. Ofta gör man samma sak som man gjort de senaste två och ett halvt åren och gjort effektivt, men nu ska de åka in på morgonen utan att det finns ett tydligt skäl för det. Det finns rentav de som berättar att de sitter på kontoret och har digitala möten en hel dag.


            Överlag tror man att detta troligen handlar om kontroll då många av de anställda pekar på vissa chefers behov av att övervaka sina medarbetare.  Därmed förlägger gärna företagen lite mer tid på kontoret än vad som faktiskt är nödvändigt.

            Ett sätt att hantera den nya situationen är att börja se på kontoret som en resurs – en plats där man gör sådant man inte kan göra hemma. En plats för kundmöten och samarbete med kollegor exempelvis, dit man kommer när det behövs.

            “…en plats där man gör sådant man inte kan göra hemma.”

            Developers Bay - Hybridarbete

            Välj din strategi för hybridarbete

            Det finns olika strategier för hybridarbete att välja mellan:

            • Bestäm hur många dagar man ska komma in varje vecka, kanske också vilka dagar 
            • Lägg upp det mer flexibelt –  och även om du förväntar dig att de anställda ska komma in till kontoret får de själva välja hur ofta och när
            • ”Anywhere first”.
            • I en mer styrd variant så får de anställda arbeta på distans hur mycket de vill men förväntas ändå bo så att de kan komma in till kontoret vid vissa tillfällen när det behövs. Även här finns en mer flexibel variant där de anställda kan arbeta exakt varifrån de vill – även geografiskt

             

            Inget av ovan sätt är bättre än det andra, utan viktigast är att fundera på och komma fram till:  

            • Hur ser vår strategi ut idag?
            • På vilket sätt ska strategin drivas framåt?
            • Passar strategin med våra affärsbehov?

             

             

            Skrivet av Linda Malmqvist, Konsultansvarig på Developers Bay

            Missa ingenting.

            Prenumerera på vårt nyhetsbrev. Vi lovar att bara skicka relevant information och aldrig spamma dig.


              The 6 Critical Practices for Leading a Team

              DevBay

              Recension: Everyone Deserves a Great Manager - The 6 Critical Practices for Leading a Team

              Victoria Roos Olsson, Todd Davis and Scott Miller

              Hejsan, jag satt länge och funderade på mitt första inlägg för denna blogg och ansåg det lämpligt att börja på toppen med en bokrecension om chefer som jag funnit hjälpsam i min egen resa som egenkonsult. Se denna som en guide för att se om du hittat rätt chef eller varför inte använda den som en handbok för att själv applicera i ett kommande ledarskapsuppdrag?

               

              Författaren till boken Scott Miller, en rutinerad chef som gjort alla tänkbara misstag i sin roll som chef men som lyckas att i denna bok konkretisera sina misstag till strategier så du och jag slipper. Kanske vill du själv bli chef eller undrar just vad du ska leta efter hos en blivande potentiell chef som kan framhäva din fulla potential?

               

              Författaren presenterar sex strategier som både nybörjare och erfarna chefer kan använda för att öka sin produktivitet, visdom och effektivitet. Jag kommer kortfattat att presentera dessa sex strategier sammanvävt med mina egna kommentarer från ett perspektiv som konsult för att förhoppningsvis få dem att fastna något extra.

               

              Nu ska jag däremot inte vara ledsen över att ha gått miste om Scott Miller som chef (…hittills) vilket jag kommer gå in på senare. Men boken kan inte vara en mer lämplig handbok just nu gällande omställningen till ett mer digitalt arbete på distans utan en ständig närvaro av en chef. Detta sätter å andra sidan samtidigt ytterligare nya krav på chefer att leda i en förändrad arbetsmiljö.

              Min egen erfarenhet, speciellt på uppdrag ute hos större kunder, är att det ligger en viss skepsis hos linjechefer och motvilja till att utföra arbete på distans eller hemifrån. Min åsikt där är att de helt enkelt inte litar tillräckligt på sina anställda om att de gör sitt jobb utan minutiös övervakning från chefen. Detta skapar inte bara irritation men är också kontraproduktivt då detta kan ligga till grund för en anställd att se sig om. Inte nog med det, det sänker även självförtroendet hos de anställda. Allt detta blir svårt att motivera när det i dag kryllar av både friare och kanske även roligare uppdrag runt hörnet där chefer förstått vikten av att lita på sina anställda och även anpassat sig till det nya friare arbetssättet som i allt högre utsträckning blir normen på många arbetsplatser. Författaren nämner att han redan vid 27 års ålder i samband med sitt första jobb som chef övervakade sina anställda och noterade när de kom till jobbet och när de gick hem.

               

              -Alla ni som någon gång jobbat med stämpelklocka vet nog vad jag menar, chefen som bara ”råkar” ta kaffe vid 07:58 för att få en översikt över vilka anställda som kommer in när.

               

              Vidare berättar han om förbud för sina anställda att slösa bort minsta minut av arbetsdagen på personliga uppgifter. Han gick även så långt att en anställd skulle granska sin kollegas röstmeddelanden under hennes smekmånad och rapportera allt misstänkt till honom. Sammanfattningsvis nämner han själv att han var en tyrann och mardröm till chef.

               

              -Även om jag förmodligen inte behöver oroa mig för några tjuvlyssningar på mina röstmeddelanden så är det däremot ett ljus i tunneln att även chefer, som kan upplevas uppfylla varje kryssruta för en mardrömschef faktiskt, också har möjlighet att inse sina fläckar och istället välja att bättra sig.

               

              Nu har det blivit dags att dissekera strategierna för en framgångsrik chef!

               

              Sugen på något nytt? Gå med i Developers Bays nätverk för frilansare idag! https://developersbay.se/frilansare/

              Strategy One: Develop a leader’s mentality.

              Se till att dina antaganden är korrekta och realistiska.  Om du upptäcker att du har fel, ändra dig då så snabbt som möjligt.  Det är inte lätt att ändra din åsikt, men du blir aldrig en bra chef genom att hålla fast vid felaktig information eller partiskt tänkande.

              Givetvis finns det en enkel trestegsmetod framtagen enligt följande:

              • ”See” – Sättet du ser saker påverkar ditt beteende. Dina resultat beror på hur du agerar på dina uppfattningar.
              • ”Do” – uppmärksamma ditt beteende, agera enligt ordspråket skynda långsamt. 
              • ”Get” – Identifiera dina mål du vill nå.

              Första komponenten ”See” väger mest enligt författaren. För att uppnå långsiktiga resultat måste du anpassa ditt tankesätt till verkligheten omkring dig. Igen, du måste se situationer tydligt och alltid agera därefter.

              Ytterligare en notering som nämns är att många anställda blir chefer eftersom de uppvisar starka individuella egenskaper. Detta är vanligast för chefer med tidigare erfarenhet inom sälj då de ofta ser det som ett nollsummespel, alltså om jag vinner förlorar de andra. Detta tankesätt fungerar inte för en framgångsrik chef och anledningen är mer eller mindre självklar: En chef måste alltid sätta de anställdas resultat först.

              Strategy Two: Routinely meet with each individual member of your team.

              För att inleda med ett citat som verkligen träffade mig hårt, baserat på egen erfarenhet: ”Anställda nämner ofta att deras relation med sina direkta chefer är den mest meningsfulla relationen i deras yrkesliv och avgör om de stannar hos ett företag eller väljer att söka sig vidare.”

               

              -Här kan jag inget annat än instämma, det ska givetvis inte kännas tvingande att stanna kvar p.g.a. sin personliga relation med chefen men en god sådan bidrar verkligen till större engagemang hos den anställda. Jag kan däremot inte förneka att relationen, eller avsaknaden av relation, med en chef oftast legat till grund till att man sökt sig vidare – för att citera bokens titel: “Everyone Deserves a Great Manager”!

               

              Vidare är det viktigt att inte låta dina 1-1 möten med chefen bli vanliga statusuppdateringar, där rekommenderar Scott att man ska fråga efter feedback. Hur kan man göra mötet mer värdefullt? Eller varför inte ge denna feedback som anställd?

               

              Det vanliga gäller självklart: Förbered i förväg, minst 30 minuters möte, skydda mötet och försök heller inte ändra schemalagd dag eller tid.

               

              Håll utkik för nästa del som hanterar resterande fyra strategier från boken “Everyone Deserves a Great Manager – The 6 Critical Practices for Leading a Team”.

               

              Vi hörs snart igen!

              Hälsningar,
              Erik

              Missa ingenting.

              Prenumerera på vårt nyhetsbrev. Vi lovar att bara skicka relevant information och aldrig spamma dig.


                Andas in, andas ut

                Kommer du ihåg sist dina tankar var tysta? Inget brus, inga tankar om vad du ska göra på jobbet imorgon eller hur budgeten ser ut för nästa månad? Alla måsten och orosmoln som panikslaget väcker dig mitt i natten svettig och med hjärtat i halsgropen.

                Det kallas stress och klassas idag som en folksjukdom och är ett av samhällets största problem. Över 50% av alla sjukskrivningar beror på en reaktion på långvarig stress. På det där lilla eller stora bruset som jagar oss och bryter ner vårt immunförsvar.

                Vi har nog alla varit vid en punkt i livet där vi känner att det är mycket som pågår. Kanske är det just nu? Efter en långvarig pandemi lever vi istället vid sidan om ett krig som känns alldeles för nära. Kanske är det mycket på jobbet, oroliga anställda eller hur ska du förklara vad som pågår i världen för dina barn?

                Då har jag ett tips för dig och det är att börja meditera.  Meditationen har verkligen förändrat mitt liv. Det är onekligen ett uttjatat uttryck men jag vet inte hur jag ska beskriva det annars. Jag kan tillägga att jag hade kunnat stå i spetsen av en motståndsrörelse mot just denna aktivitet i hela mitt liv om det hade funnits. Tur att man får ändra åsikter. 

                Något jag alltid trodde var att meditation var väldigt svårt att komma igång med. Kanske är det fler som känner igen sig? Jag hade en målat upp en bild av att jag behövde ha på mig en viss typ av kläder, det skulle vara morgon eller kväll och på något sätt trodde jag att jag behövde vara 150% hängiven meditationen för att ens kunna prova. Som på ett sätt är sant men samtidigt helt falskt.

                Att meditera är svårt just på grund av den vanemässiga stressen våra kroppar är så acklimatiserade till. Det kan kännas som en omöjlighet att inte låta tankarna sväva iväg. I början kan det vara nästan mer stressande att försöka meditera än att strunta i det och harva vidare i hamsterhjulet. Det känns läskigt att gå så djupt inom oss själva, vilka tankar ska dyka upp, hur kommer jag känna och kommer jag ens att klara det? Det är så mycket mer bekvämt att vara lite stressad och sitta klistrad vid datorn eller telefonen för det är vad våra kroppar är vana vid. Man skulle kunna säga att vi skapat ett beroende av att alltid vara lite stressade, att alltid ligga två steg fram och att faktiskt aldrig befinna oss där vi är; Här och nu.

                Men, det är just det som är en stor del av meditationen. Meditation behöver aldrig vara perfekt för att den är på sitt sätt helt kravlös. Varje gång du mediterar och gång på gång återför tankarna till situationen blir du lite mer uppmärksam på nuet. För varje meditation dövas bruset och de där oönskade tankarna blir färre och färre. Det handlar inte om perfektionen utan om att grunda oss själva och befinna oss här och nu några extra sekunder varje dag. Efter bara en vecka blir dom sekunderna till minuter som blir till timmar. Ni förstår min poäng gissar jag.

                Här är några enkla tips som hjälpte mig när jag började med meditation:

                1. En meditation behöver inte vara lång. Så lite som 2-5 minuter är faktiskt allt som krävs i början.
                2. Var snäll mot dig själv. Det gör inget om dina tankar smiter iväg, för dem bara vänligt men bestämt tillbaka och lägg ingen vidare energi på det.
                3. Du behöver inte vara klädd på ett visst sätt och det behöver inte vara varken morgon eller kväll för att du ska kunna meditera. Att meditera är kravlöst och kan egentligen göras var och hur som helst. I jeans eller underkläder, på en specialdesignad meditationskudde eller i kontorsstolen
                4. Om det känns svårt att veta hur du ska börja så rekommenderar jag  att ladda ner en meditationsapp. Där finns guidade meditationer från nybörjare till proffs och jag tycker fortfarande att det enklare att bli guidad än att kasta mig ut ensam.
                5. I början är det viktigast att vara kontinuerlig. Meditationerna kommer kanske inte vara så kvalitativa och tankarna kommer flyga åt höger och vänster i en rasande fart och det är helt okej. För varje gång du för tankarna tillbaka till mantrat eller andningen blir du lite, lite bättre på att hålla fokuset här och nu.
                6. Sist men inte minst. Av alla moment i ditt liv är detta en av de som ska vara helt kravlöst. Syftet är att få dig medveten om nuet och inte springa till framtiden eller älta gårdagen. Det är bara du och din andning.

                Lycka till och glöm inte att då och då stanna upp och uppskatta här och nu!

                Johanna Grahn
                Marketing Intern


                Running a GraphQL API in .NET 6 on AWS Lambda

                Introduction

                 

                I recently set up a brand new API for a client. AWS and .NET were givens, the remaining choices were up to me. This article is my way of writing down all the things I wish I knew when I started that work. I assume you already know your way around .NET 6C# 10GraphQL and have your ~/.aws/credentials configured.

                Why GraphQL

                 

                GraphQL has quickly become my primary choice when it comes to building most kinds of APIs for a number of reasons:

                • Great frameworks available for a variety of programming languages
                • Type safety and validation for both input and output is built-in (including client-side if using codegen)
                • There are different interactive ”swaggers” available, only much better

                 

                Something often mentioned about GraphQL is that the client can request only whatever fields it needs. In practice I find that a less convincing argument because most of us are usually developing our API for a single client anyway.

                For the .NET platform my framework of choice is Hot Chocolate. It has great docs and can generate a GraphQL schema in runtime based on existing .NET types.

                Why Lambda

                 

                Serverless is all the hype now. What attracts me most is the ease of deployment and the ability to dynamically scale based on load.

                AWS Lambda is usually marketed (and used) as a way to run small isolated functions. Usually with 10 line Node.js examples. But it is so much more! I would argue it is the quickest and most flexible way to run any kind of API.

                 

                The only real serverless alternative on AWS is ECS on Fargate, but that comes with a ton of configuration and also requires you to run your code in Docker.

                 

                Initial application setup

                 

                We start by creating a new dotnet project:

                 

                dotnet new web -o MyApi && cd MyApi

                 

                Add AspNetCore and HotChocolate:

                 

                dotnet add package DotNetCore.AspNetCore --version "16.*"
                dotnet add package HotChocolate.AspNetCore --version "12.*"

                 

                Add a single GraphQL field:

                 

                // Query.cs
                using static System.Runtime.InteropServices.RuntimeInformation;
                
                public class Query {
                  public string SysInfo =>
                    $"{FrameworkDescription} running on {RuntimeIdentifier}";
                }

                 

                Set up our AspNetCore application (using the new minimal API):

                 

                // Program.cs
                var builder = WebApplication.CreateBuilder(args);
                
                builder.Services
                  .AddGraphQLServer()
                  .AddQueryType<Query>();
                
                var app = builder.Build();
                
                app.UseRouting();
                
                app.UseEndpoints(endpoints =>
                  endpoints.MapGraphQL());
                
                await app.RunAsync();

                Running locally

                 

                Let’s verify that our GraphQL API works locally.

                 

                Start the API:

                dotnet run

                 

                Verify using curl:

                curl "http://localhost:<YourPort>/graphql?query=%7B+sysInfo+%7D"

                 

                You should see a response similar to:

                 

                { "data": { "sysInfo":".NET 6.0.1 running on osx.12-x64" } }

                 

                Lambda runtimes

                 

                AWS offers a number of different managed runtimes for Lambda, including .NET Core, Node, Python, Ruby, Java and Go. For .NET the latest supported version is .NET Core 3.1, which I think is too old to base new applications on.

                .NET 6 was released a few months ago, so that’s what we’ll be using. There are two main alternatives for running on a newer runtime than what AWS provides out of the box:

                 

                • Running your Lambda in Docker
                • Using a custom runtime

                 

                Running your Lambda in Docker was up until recently the easiest way for custom runtimes. The Dockerfile was only two or three lines and easy to understand. But I still feel it adds a complexity that isn’t always justified.

                Therefore we will be using a custom runtime.

                 

                Using a custom runtime

                 

                There is a hidden gem available from AWS, and that is the Amazon.Lambda.AspNetCoreServer.Hosting nuget package. It’s hardly mentioned anywhere except in a few GitHub issues, and has a whopping 425 (!) downloads as I write this. But it’s in version 1.0.0 and should be stable.

                 

                Add it to the project:
                dotnet add package Amazon.Lambda.AspNetCoreServer.Hosting --version "1.*"

                 

                Then add this:

                // Program.cs
                ...
                builder.Services
                  .AddAWSLambdaHosting(LambdaEventSource.HttpApi);
                ...

                 

                The great thing about this (except it being a one-liner!) is that if the application is not running in Lambda, that method will do nothing! So we can continue and run our API locally as before.

                 

                Bootstrapping

                 

                There are two main ways of bootstrapping our Lambda function:

                • Changing the assembly name to bootstrap
                • Adding a shell script named bootstrap

                 

                Changing the assembly name to bootstrap could be done in our .csproj. Although it’s a seemingly harmless change, it tends to confuse developers and others when the ”main” dll goes missing from the build output and an extensionless bootstrap file is present instead.

                Therefore my preferred way is adding a shell script named bootstrap:

                 

                // bootstrap
                #!/bin/bash
                
                ${LAMBDA_TASK_ROOT}/MyApi

                 

                 

                LAMBDA_TASK_ROOT is an environment variable available when the Lambda is run on AWS.

                We also need to reference this file in our .csproj to make sure it’s always published along with the rest of our code:

                 

                 

                // MyApi.csproj
                ...
                <ItemGroup>
                  <Content Include="bootstrap">
                    <CopyToOutputDirectory>Always</CopyToOutputDirectory>
                  </Content>
                </ItemGroup>
                ...

                Creating the Lambda package

                 

                We will be using the dotnet lambda cli tool to package our application. (I find it has some advantages over a plain dotnet publish followed by zip.)

                 

                dotnet new tool-manifest
                dotnet tool install amazon.lambda.tools --version "5.*"

                 

                I prefer to install tools like this locally. I believe global tools will eventually cause you to run into version conflicts.

                We also add a default parameter to msbuild, so we don’t have to specify it on the command line.

                 

                // aws-lambda-tools-defaults.json
                {
                  "msbuild-parameters": "--self-contained true"
                }

                 

                Building and packaging the application is done by
                dotnet lambda package -o dist/MyApi.zip

                 

                Deploying to AWS

                 

                The way I prefer to deploy simple Lambdas is by using the Serverless framework.

                (For an excellent comparison between different tools of this kind for serverless deployments on AWS, check out this post by Sebastian Bille.)

                You might argue that Terraform has emerged as the de facto standard for IaC. I would tend to agree, but it comes with a cost in terms of complexity and state management. For simple setups like this, I still prefer the Serverless framework.

                We add some basic configuration to our serverless.yml file:

                 

                // serverless.yml
                service: myservice
                
                provider:
                  name: aws
                  region: eu-west-2
                  httpApi:
                    payload: "2.0"
                  lambdaHashingVersion: 20201221
                
                functions:
                  api:
                    runtime: provided.al2
                    package:
                      artifact: dist/MyApi.zip
                      individually: true
                    handler: required-but-ignored
                    events:
                      - httpApi: "*"

                 

                 

                Even though we are using AspNetCore, a Lambda is really just a function. AWS therefore requires an API Gateway in front of it. Serverless takes care of this for us. The combination of httpApi and 2.0 here means that we will use the new HTTP trigger of the API Gateway. This would be my preferred choice, as long as we don’t need some of the functionality still only present in the older REST trigger.

                 

                runtime: provided.al2 means we will use the custom runtime based on Amazon Linux 2.

                 

                Now we are finally ready to deploy our Lambda!

                npx serverless@^2.70 deploy

                 

                The output should look something like this:

                 

                ...
                endpoints:
                  ANY - https://ynop5r4gx2.execute-api.eu-west-2.amazonaws.com
                ...

                 

                Here you’ll find the URL where our Lambda can be reached. Let’s call this <YourUrl>.

                Calling the Lambda

                 

                Using curl:
                curl "https://<YourUrl>/graphql?query=%7B+sysInfo+%7D"

                 

                You should see a response similar to:

                { "data": { "sysInfo":".NET 6.0.1 running on amzn.2-x64" } }

                Cleaning up

                 

                Unless you want to keep our Lambda running, you can remove all deployed AWS resources with:
                npx serverless@^2.70 remove

                 

                Take me to the summary!

                 

                Bonus: Running on ARM

                 

                AWS recently announced the possibility to run Lambda on the new ARM-based Graviton2 CPU. It’s marketed as faster and cheaper. Note that ARM-based Lambdas are not yet available in all AWS regions and that they might not work with pre-compiled x86/x64 dependencies.

                If we want to run on Graviton2 a few small changes are necessary:

                • Compiling for ARM
                • Configuring Lambda for ARM
                • Add additional packages for ARM

                 

                Compiling for ARM

                 

                Here we need to add our runtime target for the dotnet lambda tool to pick up:

                 

                // aws-lambda-tools-defaults.json
                {
                  "msbuild-parameters":
                    "--self-contained true --runtime linux-arm64"
                }

                Configure Lambda for ARM

                 

                We need to specify the architecture of the Lambda function:

                 

                // serverless.yml
                functions:
                  api:
                    ...
                    architecture: arm64
                    ...

                Adding additional packages for ARM

                 

                According to this GitHub issue we need to add and configure an additional package when running a custom runtime on ARM:

                 

                // MyApi.csproj
                ...
                <ItemGroup>
                  <RuntimeHostConfigurationOption
                    Include="System.Globalization.AppLocalIcu"
                    Value="68.2.0.9"/>
                  <PackageReference
                    Include="Microsoft.ICU.ICU4C.Runtime"
                    Version="68.2.0.9"/>
                </ItemGroup>
                ...

                 

                When adding this the API stops working on non-ARM platforms though. A more portable solution is to use a condition on the ItemGroup, like this:

                 

                // MyApi.csproj
                ...
                <ItemGroup Condition="'$(RuntimeIdentifier)' == 'linux-arm64'">
                  <RuntimeHostConfigurationOption
                    Include="System.Globalization.AppLocalIcu"
                    Value="68.2.0.9"/>
                  <PackageReference
                    Include="Microsoft.ICU.ICU4C.Runtime"
                    Version="68.2.0.9"/>
                </ItemGroup>
                ...

                Building, deploying, and calling it once more

                 

                Build and deploy as before.

                Call the Lambda as before.

                 

                You should see a response similar to:

                 

                { "data": { "sysInfo":".NET 6.0.1 running on amzn.2-arm64" } }

                 

                confirming that we are now running on ARM!

                 

                Clean up as before.

                Summary

                 

                That’s it! We have now deployed a minimal serverless GraphQL API in .NET 6 on AWS Lambda. Full working code is available at GitHub.

                Opinionated take aways:

                • Use GraphQL for most APIs
                • Use Hot Chocolate for GraphQL on .NET
                • Use Lambda for entire APIs, not just simple functions
                • Use dotnet lambda cli tool for packaging
                • Use Amazon.Lambda.AspNetCoreServer.Hosting for custom runtimes
                • Use a simple bootstrap script to start the API
                • Use Serverless framework for deployment
                • Use ARM if you can

                 

                Any comments or questions are welcome!

                Author – Magnus Markling, Freelance Cloud Architect


                6 saker att hålla koll på i ett konsultavtal

                I vår roll så ser vi hundratals versioner av konsultavtal varje år. Det finns så klart många saker att vara uppmärksam på i ett avtal men nedan har vi sammanställt de sex punkter som vi tycker är extra viktigt. 


                Betalvillkor

                Med detta menar vi inte bara att den ersättning man kommit överens om ska stämma utan även att man noterar hur lång tid Kunden har att betala fakturan. I vissa fall så har vi sett att Kunden har upp till 90 dagar på sig att betala. Detta innebär att du som Leverantör får vänta upp till 4 månader från påbörjat uppdrag innan du får din ersättning. Branschstandard brukar vara att betalning sker 30 dagar efter slutförd och fakturerad månad.

                 

                Uppsägningstid
                I de flesta fall så har Kunden och Leverantören ömsesidig uppsägningstid. Den kan variera i längd (oftast mellan 1 och 2 månader) och gör det möjligt för båda parterna att avbryta samarbetet. Men detta är inte alltid självklart. I vissa fall har endast Kunden en uppsägningstid och därmed kan inte Leverantören säga upp avtalet. Det är dock väldigt sällan som Kunden tvingar en Leverantör att vara kvar en längre tid mot sin vilja men vi rekommenderar ändå alltid att lyfta denna punkt för att klargöra var Kunden står i frågan innan man signerar.

                 

                Ansvarsförsäkring
                I alla avtal gällande Konsultuppdrag inom IT så bör det finnas en klausul gällande ansvarsförsäkring som Leverantören bör ha tecknat innan uppdragets start. Det varierar dock vilket belopp denna försäkring förväntas täcka. Branschstandard är cirka 10 miljoner och om Kunden begär att försäkringen täcker ett högre belopp så är det inte orimligt att fråga varför.
                 

                Konkurrensklausuler
                Alla Kunder kommer begära att Konsulten som utför det enskilda uppdraget inte har ett parallellt uppdrag hos en konkurrerande aktör. Detta är fullt normalt. Men det är viktigt att noggrant granska konkurrensklausulers för att vara medveten om hur länge efter uppdraget detta gäller och ifall det även påverkar det AB som Konsulten är knuten till. Om man är oförsiktig med detta så riskerar man att, i onödig utsträckning, begränsa sina affärsmöjligheter.

                 

                Processen för eventuella förlängningar

                Detta är något som kanske inte står i avtalet men ändå är väl värt att fråga kring. Olika Kunder har olika processer kring förlängningar det är viktigt att ha klarhet kring hur, och framför allt när, Kunden brukar förlänga sina konsultavtal. Detta kan variera ifrån att man har ett löpande avtal med 1 månads ömsesidig uppsägningstid (alltså inga förlängningar behövs) till att man förlänger en månad åt gången. Oavsett så är det bra att komma överens om parametrarna för hur långt innan ett befintligt avtal går som en dialog kring förlängning sker så att man inte riskerar missförstånd eller att man hamnar nära slutdatumet utan ett tydligt besked.

                 

                Definiera arbete på plats och / eller på distans i avtalet
                Detta är viktigare än någonsin just nu, hösten 2021. Det är väldigt viktigt att definiera hur mycket man förväntas arbeta på plats i förhållande till distans i avtalet. Framför allt nu när det är så mycket oklarheter kring hur det kommer att se ut och risken för missförstånd och felaktiga förväntningar händer väldigt enkelt. Man kan så klart ha ett spann (t.ex 2-3 dagar på plats) men även det kommer ge en bra grund och säkerställa att alla är på samma blad kring den här högaktuella fråga.

                 

                Skribent: Lubomir Struwe, Senior Account Manager (lubomir@developersbay.se)