DEV Community: Richard Basson

Sustainable Software Engineering for a greener digital world

Richard Basson — Sun, 23 Jul 2023 16:48:54 +0000

When it comes to sustainability, what can we as software engineers and architects do? It turns out, quite a lot. We have the power 😜 to make a difference, and I'm going to show you how by starting with the core concepts of Sustainable Software Engineering (SSE). It’s a lot easier and more in reach than you might think.

Core concepts and philosophies of Sustainable Software Architecture & Sustainable Software Engineering

Sustainable Software Engineering is built upon two core philosophies and eight core principles. Let's delve deeper into these concepts, understanding this will help with the practical applications later.

Philosophies

Everyone has a part to play in the climate solution:

It might not always seem like it but we can all make a difference. We have a lot more to offer when it comes to the climate solution than we think, and it’s easier to make these changes than we think.

I will talk more about this in the upcoming sections.

Sustainability is enough, all by itself, to justify our work.

This philosophy may seem strange at first glance, but it’s really important to be sustainable to be able to keep on doing what we are doing for generations to come. Hopefully this sets a precedent for how people can easily do this going forward. Sustainable practices can also help financially by reducing waste and increasing efficiency. This can save money and make businesses more profitable in the long run.

Eight Core Principles

Carbon: Minimise the carbon emissions generated by your software and its underlying infrastructure. This includes optimising code, reducing computational complexity, and selecting energy-efficient hardware.

Suggestions:

- Utilise energy-efficient algorithms and data structures.
- Monitor and minimise power consumption of your software.
- Choose cloud providers that prioritise renewable energy sources.

Electricity: Reduce the electricity consumption of your software and hardware by optimising resource utilisation and eliminating waste.

Suggestions:

- Implement techniques such as dynamic voltage and frequency scaling (DVFS) to optimise power usage.
- Use virtualisation and containerisation to optimise resource utilisation.
- Optimise idle times, sleep states, and power-saving modes.

Carbon intensity: Be aware of the carbon intensity of the energy sources powering your software and infrastructure, and prioritise lower-carbon options when possible.

Suggestions:

- Choose data center locations with low-carbon energy sources.
- Work with cloud providers that prioritise carbon reduction strategies.
- Consider carbon offset programs to balance out your emissions.

Embodied carbon: Understand the carbon footprint of your software's entire lifecycle: including production, distribution, and disposal of hardware.

Suggestions:

- Prioritise hardware with lower embodied carbon.
- Implement effective recycling and disposal policies for hardware.
- Promote hardware longevity through software compatibility and modularity.

Energy proportionality: Strive for energy usage that is proportional to the workload, ensuring that idle resources consume less energy.

Suggestions:

- Use auto-scaling features to dynamically allocate resources based on demand.
- Implement energy-efficient workload scheduling.
- Optimise server utilisation through load balancing and resource management.

Network efficiency: Optimise network usage to minimise energy consumption and reduce latency.

Suggestions:

- Minimise data transfer by compressing and caching data.
- Optimise API calls and utilise content delivery networks (CDNs) to reduce latency.
- Use edge computing to move computation closer to the data source.

Demand shaping: Manage and shape user demand to spread it across time, reducing peak loads and energy consumption.

Suggestions:

- Implement features that incentivise off-peak usage.
- Utilise demand forecasting and load management techniques.
- Encourage users to adopt energy-saving settings and behaviors.

Optimisation: Continuously improve and optimise your software's energy efficiency and carbon footprint through monitoring, analytics, and automation.

Suggestions:

- Set up monitoring and analytics to track energy consumption and carbon emissions.
- Implement automated testing and optimisation tools to continuously improve efficiency.
- Encourage a culture of sustainability within your organisation.

Normalising Conversations about SSE

For SSE to become a standard practice in the software industry, it's important to normalise conversations around it. Encourage your colleagues and peers to discuss sustainability, share best practices, and create a culture of accountability for environmental impact.

Cascading Benefits of SSE

Adopting SSE practices not only benefits the environment but also has cascading benefits for businesses and individuals. Sustainable practices can help financially by reducing waste, increasing efficiency, and ultimately saving money. This makes businesses more profitable and supports long-term growth.

Embodied Carbon

Embodied carbon is the carbon footprint of a product or service throughout its entire lifecycle, from production to disposal. By understanding and reducing the embodied carbon of software and hardware, engineers can make a significant impact on overall carbon emissions.

It does not matter in which space you might find yourself, working with cloud services or on-premise. Whether you’re working on the backend or building for devices (including web) you have a role to play.

Practical Applications of SSE

In this section, we will explore some practical applications of SSE in different domains, including cloud services, devices, networking energy usage, and demand shaping.

Cloud Services

The cloud has created an illusion of abundant resources, making it easy to overlook the actual physical resources consumed. Remember that "the cloud is just someone else's computer." The abstraction hides the fact that we still use power from the region where the data centers are located and that hardware components are produced using rare earth metals.

When running a server at only 10% utilisation, the server still consumes static power, resulting in a low power-to-work ratio. By provisioning only the capacity you need and avoiding overprovisioning, you can achieve a higher power-to-work ratio and reduce costs.

Devices

Developers often encounter device compatibility issues. While it may be frustrating to address these problems, consider the carbon footprint of the devices you build for. Devices have a larger carbon footprint during manufacturing than usage over their lifetime. The more often people have to replace their devices, the larger their carbon footprint.

By continuing to support older devices, you can help reduce the overall carbon footprint of your users.

Networking Energy Usage

Network infrastructure consumes power, and the further data needs to travel over a network the more devices are needed and the more power is consumed. When designing software, try to have your data be as close as possible to the consumer. This not only reduces energy consumption but also helps with latency, giving you a double win.

Demand Shaping

In the digital cloud world, demand shaping involves balancing when and how people use online services to avoid overloading servers during peak times. This helps reduce the energy used by the servers and makes the digital world more sustainable.

For example, imagine an online video game company encouraging players to play during off-peak hours when fewer people are online. They could offer in-game rewards or bonuses to incentivise off-peak gaming, helping to spread out the demand for game servers. This way, servers don't have to work as hard and use as much energy all at once.

By implementing similar strategies, you can shape demand to match supply and contribute to a more sustainable digital world.

Sustainable Software Engineering is not just a responsibility for software engineers and architects; it's an opportunity to create a positive impact on our environment. By understanding the core concepts of SSE, normalising conversations around sustainability, and implementing sustainable practices in our work, we can play a crucial role in building a greener world.

GitHub Actions - Azure Container Apps build/deploy

Richard Basson — Tue, 07 Feb 2023 06:59:33 +0000

This is a tutorial on how to deploy Azure Container Apps using GitHub Actions. I will provide examples and step-by-step instructions on how to build custom Github Actions workflows for deploying container apps to Azure. This will show you how to create your own actions for container deployments based on your needs.

Some assumptions:

You have an Azure account.
You have a GitHub account.
You have the Azure CLI.
You have access to create resources and service principles in the Azure subscription you’re going to deploy to.
You have an image repository where you can store container images.
You have code to deploy.

Here is an example of an action workflow that I use to deploy my container apps:

# The name of the deployment
name: Trigger auto deployment for containerapps

# When this action will be executed
on:
  # Automatically trigger it when detected changes in repo
  push:
    # Branched to look out for changes on
    branches: 
      [ main ]

  # Allow manually trigger of the jobs
  workflow_dispatch:      

jobs:
  # Job run image.
    build:
      runs-on: ubuntu-latest

   # Steps that need to happen in this job run.
      steps:
        # Check out the code
        - name: Check out code
          uses: actions/checkout@v2

        # Log in to Azure CLI
        - name: Log in to Azure
          uses: azure/login@v1
          with:
      # Azure CLI credentials
            creds: ${{ secrets.AZURE_CREDENTIALS }}

        # Build and deploy the container app
        - name: Build and deploy Container App
          uses: azure/container-apps-deploy-action@v0
          with:
            appSourcePath: ${{ github.workspace }}
            acrName: <Container-Registery-Name>
            acrUsername: ${{ secrets.REGISTRY_USERNAME }}
            acrPassword: ${{ secrets.REGISTRY_PASSWORD }}
            containerAppName: <Container-App-Name>
            containerAppEnvironment: <Container-App-Environment-Name>
            resourceGroup: <Container-App-Resource-Group>
            imageToBuild: <Container-Registry>/<Image-Name>:<Tag e.g. ${{ github.sha }}>
            dockerfilePath: /Path/to/Dockerfile

This is quite a lot so let’s unpack it.

GitHub Actions File structure

Workflow Name

name: Trigger auto deployment for containerapps

This is the name you want to give your deployment run.

Workflow triggers

# When this action will be executed
on:
  # Automatically trigger it when detected changes in repo
  push:
    # Branched to look out for changes on
    branches: 
      [ main ]

  # Allow manually trigger of the jobs
  workflow_dispatch:

The worflow trigger is how you choose to trigger your deploy. This example creates a trigger based on me pushing code to my main branch; you can set this based on the branch you trigger deploys from. It’s also possible to use wildcards, for example:

branches:
      - main
      - 'releases/**'

The workflow_dispatch allows you to manually trigger the workflow in GitHub actions. I found this particularly useful when I’ve made changes to the infrastructure and I need to trigger a deployment again.

You can read more about workflow triggers here:

Events that trigger workflows - GitHub Docs

Jobs

This is a grouping of steps that need to run. You can have one or multiple jobs.

The example above only has 1 job called "build" which builds and deploys the project and runs on the ubuntu image.

These jobs run in parallel by default but you can create a dependency on other jobs by using the needs: keyword. You can also conditionally run jobs.

jobs:
  review:
    name: Deploy/Review

  staging:
    name: Deploy/Staging

  production:
    name: Deploy/Production
    if: ${{ always() }}
    needs: [staging, review]

In the above image the Deploy/Staging, Deploy/Review and Deploy/Production blocks are jobs.

You can read more about jobs here:

Using jobs in a workflow - GitHub Docs

Steps

These are tasks that need to run as part of the job. In this case, we have 3 steps that need to run as part of the job.

Check out code
Log in to Azure
Build and deploy Container App

These can consist of actions from the marketplace or custom actions, but in this case, we are using standard marketplace actions.

The “Check out code” step checks out the code from the repo you’re running this action from into the container that the build/deploy is running in.

The“ Log in to Azure” step logs you into the azure CLI and gives the deployment an access token to deploy the container app.

The “Build and deploy Container App” builds and deploys the container app in the coming section we’ll get into more detail on what that does.

Credentials and secret setup

We need to first of all, create a service principal in Azure. The best way would be to use this Azure CLI.

Make sure you’re logged into the subscription you want to deploy the container app.

You then run the following command to create the service principle:

az ad sp create-for-rbac --name "myApp" --role contributor \
                            --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group} \
                            --sdk-auth

Replace the {subscription-id} and {resource-group} with the subscription Id and the resource group, you want to deploy to respectively. You should also replace myApp with your service principles name.

This command will create an RBAC (role-based access control) service principle which then has contributor access to the subscription and resource group.

You will then get an output that looks like the one below. You should be careful not to share this as it is sensitive information. You will need to keep this as you will use it soon.

{
   "clientId": "<GUID>",
   "clientSecret": "<STRING>",
   "subscriptionId": "<GUID>",
   "tenantId": "<GUID>",
   "resourceManagerEndpointUrl": "<URL>"
   (...)
 }

Now to create the Secret in GitHub on the repo so it can be used for the action.

Click on the repo you want to deploy.
Navigate to Settings
Then under Security expand Secrets and variables
Click “Actions”
While on the secrets tab click on “New repository secret”
Create a secret called “AZURE_CREDENTIALS”
Make the secret value the value you got above from creating the service principle.

This part is only required if you want to use a container registry.

While you are creating secrets you will need 2 more. The “REGISTRY_USERNAME” and “REGISTRY_PASSWORD”. This can be obtained from your Azure container registry.

REGISTRY_USERNAME is the username of the registry user.

REGISTRY_PASSWORD is the password of the registry user.

The bare minimum

Your first half of the workflow page should look something like this:

# The name of the deployment
name: Trigger auto deployment for containerapps

# When this action will be executed
on:
  # Automatically trigger it when detected changes in repo
  push:
    # Branched to look out for changes on
    branches: 
      [ main ]

  # Allow mannually trigger of the jobs
  workflow_dispatch:      

jobs:
        # Job run image.
    build:
      runs-on: ubuntu-latest

The following steps you add will be based on different scenarios.
So lets start with the first three.

1.) You are deploying an existing container image with public registry access.

steps:

  - name: Log in to Azure
    uses: azure/login@v1
    with:
      creds: ${{ secrets.AZURE_CREDENTIALS }}

  - name: Build and deploy Container App
    uses: azure/container-apps-deploy-action@v0
    with:
      imageToDeploy: mcr.microsoft.com/azuredocs/containerapps-helloworld:latest

2.) You are building and deploying an image.

steps:

  - name: Log in to Azure
    uses: azure/login@v1
    with:
      creds: ${{ secrets.AZURE_CREDENTIALS }}

  - name: Build and deploy Container App
    uses: azure/container-apps-deploy-action@v0
    with:
      appSourcePath: ${{ github.workspace }}
      acrName: mytestacr

3.) You don’t have a dockerfile or built image but you have the runtime stack.

steps:

  - name: Log in to Azure
    uses: azure/login@v1
    with:
      creds: ${{ secrets.AZURE_CREDENTIALS }}

  - name: Build and deploy Container App
    uses: azure/container-apps-deploy-action@v0
    with:
      appSourcePath: ${{ github.workspace }}
      acrName: mytestacr
      runtimeStack: 'dotnetcore:7.0'

With these scenarios if you don’t have the container app, container environment, or resource group created either manually or by a previous run, it will create these resources for you.

The resources will be named as follows:

Container App: github-action-container-app-<github-run-id>-<github-run-attempt>
Resource Group: <container-app-name>-rg
Container App Environment: <container-app-name>-env

I have found this to not be ideal in most cases, so let’s see what we need to give it to not create these.

Additional arguments

So to prevent the action from creating these resources, you will need to give it the name of existing resources or give it names of resources you want to initally create and subsequently re-use.

You can then add these arguments to your “Build and deploy Container App” step.

containerAppName: <Container-App-Name>
containerAppEnvironment: <Container-App-Environment-Name>
resourceGroup: <Container-App-Resource-Group>

If you have a custom Docker image you want to build and deploy, you need to use these arguments to build the image and deploy it. This is if you have an existing Dockerfile

imageToBuild: <Container-Registry>/<Image-Name>:<Tag e.g. ${{ github.sha }}>
dockerfilePath: /Path/to/Dockerfile

You will also need to log into your container registry to push the image, so you will need these below arguments as well. You will also need these if you’re pulling an image from a private image repository.

acrName: <Container-Registery-Name>
acrUsername: ${{ secrets.REGISTRY_USERNAME }}
acrPassword: ${{ secrets.REGISTRY_PASSWORD }}

Some of the other ones I have not used but can be useful are:

environmentVariables A list of environment variable(s) for the container. Space-separated values in 'key=value' format. Empty string to clear existing values. Prefix value with 'secretref:' to reference a secret.
targetPort The target port that the Container App will listen on. If not provided, this value will be "80" for Python applications and "8080" for all other supported platforms.

Well done! You’ve made it all the way to the end.

You’ve now unlocked the skill to deploy Azure container apps using GitHub action

If you like this post consider following me here or on Twitter @bassonrichard

If you want to do some more reading here is the documentation for the GitHub Action

Azure Container Apps Build and Deploy - GitHub Marketplace

AWS Cognito — Client credentials flow .NET 6

Richard Basson — Mon, 30 May 2022 14:55:42 +0000

AWS Cognito User pool creation

Navigate to the AWS Cognito service page

Click on create user pool

Step 1: Configure sign-in experience

Select Email and click next

Step 2: Configure security requirements

Under password policy select cognito defaults
Under Multi-factor authentication select No MFA
Under User account recovery select Enable self-service account recovery and then Email Only
Click next

Step 3: Configure sign-up experience

Keep all selections as default and click next

Step 4: Configure message delivery

Select Send email with Cognito and keep the rest of the configuration as default then click next

Step 5: Integrate your app

Configure the User pool name with your preferred naming convention
Select Confidential client
Configure the App client name
Click next

Step 6: Review and create

Review your configuration
Click Create user pool

User Pools

See your created user pool

Application configuration and resource server creation

Navigate to your created user pool

Navigate to the App Integration tab

Step 1: Create Domain

On the Domain section click on Actions and then click on Create Cogniro domain
Enter a unique domain prefix
Click Create Cognito domain

Step 2: Create Resource server

Click Create resource server
Configure the resource server name and identifier
Create custom scopes for your application to use when authenticating
Click create resource server

Step 3: Configure client application

Select the app client you created
Under Hosted UI click edit
Under Hosted sign-up and sign-in pages select the identity provider cognito user pool
Select Client Credentials OAuth 2.0 Grant type
Select the custom scope you created and want to assign to the application
Click Save changes

Create Weather API

Step 1: Create API

Create a API project if you don’t have one

Step 2: Add NuGet packages

Add the following NuGet packages:

Step 3: Setup auth in Program.cs

Add this block of code to the Program.cs under the builder.

builder.Services.AddCognitoIdentity();

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.Authority = builder.Configuration["AWSCognito:Authority"];
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuerSigningKey = true,
                ValidateAudience = false
    };
});

Add the following under app.UseHttpsRedirection(); in Program.cs

app.UseAuthentication();
app.UseAuthorization();

Add the following using's to the Program.cs

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;

Your Program.cs will end up looking like this when you’re done.

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

builder.Services.AddCognitoIdentity();

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.Authority = builder.Configuration["AWSCognito:Authority"];
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuerSigningKey = true,
        ValidateAudience = false
    };
});

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthentication();
app.UseAuthorization();

app.MapControllers();

app.Run();

Step 4: Setup configuration file

Add this section to the appsettings.Development.json file

This URL for the authority is made up of the following

https://cognito-idp.{region}.amazonaws.com/{userpoolid}


  "AWSCognito": {
    "Authority": "[https://cognito-idp](https://cognito-idp/).{region}.amazonaws.com/{userpoolid}"
  }

You can find the user pool id in AWS on the Amazon Cognito page under user pools

Step 5: Add authorize attribute to GetWeatherForecast endpoint

In the WeatherForecastController.cs add the Authorize attribute to the GetWeatherForecast endpoint and add Microsoft.AspNetCore.Authorization to the usings.

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

namespace AWSCognitoWeatherAPI.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        private static readonly string[] Summaries = new[]
        {
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
    };

        private readonly ILogger<WeatherForecastController> _logger;

        public WeatherForecastController(ILogger<WeatherForecastController> logger)
        {
            _logger = logger;
        }

        [Authorize]
        [HttpGet(Name = "GetWeatherForecast")]
        public IEnumerable<WeatherForecast> Get()
        {
            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Date = DateTime.Now.AddDays(index),
                TemperatureC = Random.Shared.Next(-20, 55),
                Summary = Summaries[Random.Shared.Next(Summaries.Length)]
            })
            .ToArray();
        }
    }
}

Call the Weather Forecast API using Postman

Step 1: Create new collection

Create a new collection for the API
Add new request to the collection for the weather forcast endpoint (https://localhost:7214/WeatherForecast)

Step 2: Setup Collection Auth

Click on the Weather Forcast API collection and navigate to the Authorization tab
From the Type dropdown select OAuth 2.0
In the Configure New Token Section give the token a name
In Grant Type dropdown select Client Credentials
In the app integration section of the user pool in AWS get the domain url
Add the domain to the Access Token URL section in postman and append it with /oauth2/token
Get the client id from the client app in AWS
Get the client secret from the client app in AWS
Get the custom scope form the Hosted UI
Add the clientid, client secret and scope in postman
Click get new access token
Click use token on the pop-up
On the Weather Forecast request under the Authorization tab ensure the Type is set to Inherit auth from parent.

Step 3: Call the Weather API

Click send on the weather forecast request to get the response on the API

It’s as easy as that !🎉

You can have a look at the repo below to find the full codebase.
https://github.com/Bassonrichard/aws-cognito-weather-api

How to deploy to IIS using Azure DevOps YAML pipelines

Richard Basson — Thu, 19 Aug 2021 12:05:32 +0000

This blog is intended as a practical guide on how to deploy to IIS on a virtual machine using Azure DevOps YAML pipelines. If you want to read more about Azure DevOps and the benefits of DevOps check this out:
https://docs.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops

Some assumptions before we start:

You have access to the server you want to deploy on and admin access to PowerShell.
You have access to the internet on the remote server you want to deploy on.
You have admin access to install the .net core hosting bundle on the server.
You can create environments, push code to your repo and create pipelines.
You have a .net core API to deploy.

Creating Environment

Go to Pipelines, and then select Environments.
Select Create environment.
Type the name of the environment, enter the description and
select Virtual machines and click next.

Then select the Generic provider in the dropdown and select Windows as the operating system. You can then copy the registration script using the copy icon.

Open an Administrative Powershell terminal on the windows
machine you want to deploy to, paste the registration script in
the terminal, and run the script. This step usually takes a
while.
When the agent is done downloading you will be prompted if you
want to add a tag to the machine. This is not required if there
is a single machine in the environment but you will need to add
the associated tags if you have multiple machines in the
environment.
You will then be prompted to ask if you want to unzip for each
task, which is not required — so you can say no.
You will then be prompted to enter a user account for the agent
running on the machine. You can leave it as default or create a
new service account under which the agent will run.

When your agent creation succeeds you will be able to go back to Azure DevOps and see your virtual machine added as a resource in the environment!

Creating build stage

Go to Pipelines, and then select Pipelines.
Select Create Pipeline and connect to your application's source
code.

Choose to show more on the configure pipeline step then select ASP.NET Core.

You will then have a base pipeline for ASP.NET Core applications, you can then add the build stage by adding the following code snippet:

trigger:
- master

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: 'Release'

  #Replace these variables to suit your application
  projectName: 'WeatherService'
  websiteName: 'WeatherService'
  appPoolName: 'WeatherService'

stages:
- stage: 'Build'
  displayName: 'Build'
  jobs:
     - job: 
       steps:  
        - task: DotNetCoreCLI@2
          displayName: 'dotnet restore'
          inputs:
            command: 'restore'
            projects: '*.sln'

        - task: DotNetCoreCLI@2
          displayName: Build
          inputs:
            command: 'build'
            projects: '*.sln'
            arguments: --configuration Release

        - task: DotNetCoreCLI@2
          displayName: Test
          inputs:
            command: test
            projects: '*.sln'
            arguments: '--configuration $(BuildConfiguration)'

        - task: DotNetCoreCLI@2
          displayName: 'Publish the project - $(buildConfiguration)'
          inputs:
            command: 'publish'
            projects: '**/*.csproj'
            publishWebProjects: false
            arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
            zipAfterPublish: true

        - publish: '$(Build.ArtifactStagingDirectory)'
          artifact: drop

Replace the variables at the top to suit your application by replacing the app pool name, website name, and project name with your project’s details.
You can then click Save and run to have a pipeline to build that creates your application.

Create release pipeline

Go to Pipelines and select Pipelines.
You will see the pipeline that you have created, on the left- hand side of your pipeline select more options and then select edit.
Your pipeline will load then you can append the following YAML code to your pipeline:

- stage: 'Dev'
  displayName: 'Dev'
  dependsOn: 'Build'
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
  jobs:
   - deployment: Dev
     displayName: Dev
     environment: 
       name: 'Dev'    
       resourceType: VirtualMachine
     variables:
     - name: websitePhysicalPath
       value: '%SystemDrive%\inetpub\wwwroot\$(websiteName)'

     strategy:
      runOnce:
        deploy:
          steps: 
          - task: IISWebAppManagementOnMachineGroup@0
            inputs:            
              IISDeploymentType: 'IISWebsite'
              ActionIISWebsite: 'CreateOrUpdateWebsite'
              WebsiteName: '$(websiteName)'
              WebsitePhysicalPath: '$(websitePhysicalPath)'
              WebsitePhysicalPathAuth: 'WebsiteUserPassThrough'
              CreateOrUpdateAppPoolForWebsite: true
              AppPoolNameForWebsite: '$(appPoolName)'
              DotNetVersionForWebsite: 'No Managed Code'
              PipeLineModeForWebsite: 'Integrated'
              AppPoolIdentityForWebsite: 'ApplicationPoolIdentity'
              AddBinding: true
              Bindings: |
                  {
                      bindings:[
                          {
                              "protocol":"http",
                              "ipAddress":"",
                              "hostname":"",
                              "port":"80",
                              "sslThumbprint":"",
                              "sniFlag":false
                          }
                      ]
                  }
          - task: IISWebAppDeploymentOnMachineGroup@0
            inputs:
              WebSiteName: '$(websiteName)'
              Package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/$(projectName).zip'

After adding the script select Save and run you will be able to release it to the environment you created earlier.

Recap

When you are done your script it should look something like this:

trigger:
- master

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: 'Release'
  projectName: 'WeatherService'
  websiteName: 'WeatherService'
  appPoolName: 'WeatherService'

stages:
- stage: 'Build'
  displayName: 'Build'
  jobs:
     - job: 
       steps:  
        - task: DotNetCoreCLI@2
          displayName: 'dotnet restore'
          inputs:
            command: 'restore'
            projects: '*.sln'

        - task: DotNetCoreCLI@2
          displayName: Build
          inputs:
            command: 'build'
            projects: '*.sln'
            arguments: --configuration Release

        - task: DotNetCoreCLI@2
          displayName: Test
          inputs:
            command: test
            projects: '*.sln'
            arguments: '--configuration $(BuildConfiguration)'

        - task: DotNetCoreCLI@2
          displayName: 'Publish the project - $(buildConfiguration)'
          inputs:
            command: 'publish'
            projects: '**/*.csproj'
            publishWebProjects: false
            arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
            zipAfterPublish: true

        - publish: '$(Build.ArtifactStagingDirectory)'
          artifact: drop

- stage: 'Dev'
  displayName: 'Dev'
  dependsOn: 'Build'
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
  jobs:
   - deployment: Dev
     displayName: Dev
     environment: 
       name: 'Dev'    
       resourceType: VirtualMachine
     variables:
     - name: websitePhysicalPath
       value: '%SystemDrive%\inetpub\wwwroot\$(websiteName)'

     strategy:
      runOnce:
        deploy:
          steps: 
          - task: IISWebAppManagementOnMachineGroup@0
            inputs:            
              IISDeploymentType: 'IISWebsite'
              ActionIISWebsite: 'CreateOrUpdateWebsite'
              WebsiteName: '$(websiteName)'
              WebsitePhysicalPath: '$(websitePhysicalPath)'
              WebsitePhysicalPathAuth: 'WebsiteUserPassThrough'
              CreateOrUpdateAppPoolForWebsite: true
              AppPoolNameForWebsite: '$(appPoolName)'
              DotNetVersionForWebsite: 'No Managed Code'
              PipeLineModeForWebsite: 'Integrated'
              AppPoolIdentityForWebsite: 'ApplicationPoolIdentity'
              AddBinding: true
              Bindings: |
                  {
                      bindings:[
                          {
                              "protocol":"http",
                              "ipAddress":"",
                              "hostname":"",
                              "port":"80",
                              "sslThumbprint":"",
                              "sniFlag":false
                          }
                      ]
                  }
          - task: IISWebAppDeploymentOnMachineGroup@0
            inputs:
              WebSiteName: '$(websiteName)'
              Package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/$(projectName).zip'

You should also have an environment to deploy your pipeline to called Dev.

When you navigate to pipelines it should look something like this:

You can have a look at this example repository as well:
https://github.com/Bassonrichard/azure-devops-iis-deploy

When you release this you will have a DevOps pipeline setup using YAML pipelines, making your solution ready for the future with the ease of deployment of your solution.

When is it a good choice to use Azure serverless functions?

Richard Basson — Wed, 04 Nov 2020 19:10:21 +0000

What is serverless?

Let’s start by going into what serverless really is. No, it’s not the absence of servers but rather the abstraction of servers where you don’t have to deal with operating systems or infrastructure. This is all managed for you by Azure or your respective cloud provider.

How do Azure serverless functions work?

Let’s start by saying Azure functions serverless scales very well, it is one of its big features in fact.
So as the load becomes more, functions spin up and as the load decreases, the functions shut down. The Azure functions scale all the way down to 0 Azure functions. This means you don’t get billed at all for the time that there are no functions because there is no resource consumption.

This is great so it’s super cost-effective and saves a lot of power but, this also means there are no functions running. So what happens when a request comes in? Azure will have to allocate server resources, load your function into memory and spin up a new instance of your function for it to be able to use the function. Now you’re possibly thinking but won’t it take long for this function to spin up? Actually, it will! It will, in fact take time to spin up. This is called cold start. You can read more about it here: Understanding serverless cold start.

The consumption plan is billed in two different ways:

The function can get billed based on the number of executions, and you will get the first million executions free. From there you will be charged per million executions.
The second type of billing is based on resource consumption measured in gigabyte seconds. This is an average of the memory usage of your function and the time it takes to execute.

How do you get around cold starts?

There are a couple of ways to get around cold starts, but they aren’t without their drawbacks.

You could use the Dedicated (App Service) which means that you won’t have cold starts and possible execution time is much longer. This means though that you will have to configure the resources. It does not auto-scale and you will manually have to add virtual machines to scale out. This option is also a lot more expensive than the standard consumption plan and means you don’t get the benefits from serverless anymore.
You can keep your Azure functions up 24/7 by calling it on a trigger every 15 minutes. You can also achieve the same results by calling the function before it shuts down. This means that you are using resources of your consumption plan that could have gone to valuable compute.
You could optimize your code for the startups. This won’t get rid of cold starts, it will just reduce the time it takes to start up.

If you choose to call the function before it shuts down you might want to consider using app service plans since it will be cheaper in the long run.

When should I use Azure serverless functions?

Now that we’ve gone through how it works, let’s get to the interesting part. When is it a good idea to use Azure functions?

The word function in the software development world means a piece of code that performs a specific well ... function. This is also true for Azure functions: it's a piece of code written for a specific function. This is what serverless was built for and does its best in. Doing small pieces of work. When writing functions you should think of them as bite-sized pieces code with a dedicated job.

They perform at their best if you have small jobs that can be triggered, run in the background, and be completed fairly quickly. If you wish to run long tasks or larger pieces of code this will probably not work for you.

Think of Azure functions as your local handyman, coming to fix something small in your house. When you call the handyman it takes time for the handyman to come out - they aren’t going to rebuild your house - and you pay for the time he helped you.

That said, you will be able to create functions that run larger pieces of code and longer tasks but you will have to weigh the benefit of serverless to the time it takes to create all the workarounds you have to do to get it to work. I have found in many cases that these workarounds were not worth it and I would have been better off simply using other services.

So next time you want to use Azure functions, have a look at what you want to accomplish and see if it will be possible to do what you want in a bite-size piece of code that does not run for long and is not time-sensitive.

How to set up a Raspberry Pi K3s cluster

Richard Basson — Tue, 10 Mar 2020 08:55:21 +0000

The why

Why would you use K3s on a Raspberry Pi and not plain Kubernetes? The short answer is that Kubernetes was not developed with your small Raspberry Pi processor and memory in mind.

The longer answer is that K3s has everything you need for your Raspberry Pi from Kubernetes. It was developed for small servers without all of the unnecessary extras that Kubernetes has. This allows the memory footprint to be smaller on your Raspberry Pi and uses less than 40mb of space on your SD card so no wasting space.

So now that you know the why, let’s get started!

What you need to get started.

(2+) x Raspberry Pi (please note raspberry pi zero won’t work with K3s)
USB cable/charger (make sure it can support 3A output if you don’t use the
official charger)
Fly leads — as many as you have raspberry pi’s
Micro SD cards — preferably class 10. Here are more tips on how to choose a micro SD card
Network Switch (or router with open ports)

Nice to haves

Case(s) for the raspberry pi(s) with fans to keep the raspberry pi(s) cool
A USB hub with 3A output for all ports
Micro SD card reader

Now you need to setup Raspbian OS on the Raspberry Pi.

Download the latest version of Raspberry Pi Imager and install
it.
Connect an SD card reader with the SD card inside.
If you used the card for another project you will first need to
clean the micro SD card by using the erase option on the
Raspberry Pi Imager.
Open Raspberry Pi Imager and choose the Raspbian lite from the
list presented.
Choose the SD card you wish to write your image to.
Review your selections and click ‘WRITE’ to begin writing data
to the SD card.

You can find the official guide here

When you are done writing to the SD card, add a file named SSH to the card in the root folder (boot). The file does not have to contain anything, it can just be a plain text file.

Now to boot up your Pi’s.

When you finally finish writing the image to the SD card, plug in your SD card. You can plug in the fly lead and the USB-C cable and power the Pi(s) up!

The default setup of the Raspberry Pi.

When you connect for the first time you can use the following command to access the Raspberry Pi:

ssh pi@raspberrypi.local

It will then prompt you for a password which by default is: raspberry

When you’re done with that you should be in and ready to set up some defaults. First, let’s change the default password. Use the following command to access the Raspberry Pi config:

sudo raspi-config

Change the password to a secure password that you can access again. If you struggle to think of a password you can use the following tool to generate one:
https://passwordsgenerator.net/

Please keep this password safe as you will need it to be able to access the Pi again.

Once you’ve changed the password a good next step would be to change the hostname of the Raspberry Pi. You can get to the hostname by choosing network options on the main raspberry pi config menu then choosing the hostname. I like to change the hostname to pi0 for the master node and then the worker nodes pi1, pi2 etc…(or Blueberry Pi, Pecan Pi, Lemon Meringue Pi).

Getting to the clustering

You will need to start by enabling container feature. You can do this by exiting the /boot/cmdline.txt file by using your favorite editor: I prefer to use nano.

Run the following command to edit this file:

sudo nano /boot/cmdline.txt

Then append the following to the top line of the file:

cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory

Then save it to the file and reboot your Raspberry Pi by running

sudo reboot

Repeat the above on all of your Raspberry Pi’s

On your master node:

SSH back into the Raspberry Pi. You will need to download the latest version of K3s by using the following command on the Raspberry Pi :

curl -sfL https://get.k3s.io | sh -

You can run the following command to see if K3s started up correctly

sudo systemctl status k3s

If all went well you will see your master node up and running when you run the following command:

sudo k3s kubectl get nodes

Do the following on your worker nodes

You will first need to run the following command to get the K3s server token so that you can later use it to register the worker nodes. Once you have the token, keep it safe so you can use it later. If you lose the token you can always run the command again on the master node to get the token again.

sudo cat /var/lib/rancher/k3s/server/node-token

You will need to replace ‘myserver’ with the IP of your master node and xxx after K3s_TOKEN to the token on your master node which you can obtain by running on your master node.

sudo curl -sfL https://get.k3s.io | K3S_URL=”https://myserver:6443” K3S_TOKEN=XXX sh -

When you’re done doing that on all your worker nodes you can run the below command on your master node again to get all the nodes.

sudo k3s kubectl get nodes

(optional)
K3s comes standard with containerd and not Docker to save space. If you want to use Docker you can install it by running the following command on your Raspberry Pi’s.

curl -sSL https://get.docker.com | sh

Then run the following command so you don’t have to run docker as sudo:

sudo usermod -aG docker pi

If you want to find out more about docker I wrote an article you can find here

There you have it, you’re done setting up your K3s cluster!!!

Feel free to let me know how it goes, you are welcome to dm me on twitter if you get stuck somewhere @bassonrichard.

Resources for some further reading:
https://github.com/rancher/K3s
https://passwordsgenerator.net/
https://www.raspberrypi.org/documentation/installation/installing-images/README.md
https://www.raspberrypi.org/downloads/
https://www.makeuseof.com/tag/5-mistakes-avoid-buying-next-microsd-card/
https://medium.com/@bassonrichard/what-is-docker-and-why-is-there-such-a-big-hype-around-it-13badc312c28

Code review and the importance of it!

Richard Basson — Mon, 07 Oct 2019 19:18:26 +0000

I’m here to tell you about code review (or as some may know it peer review) is, where it came from and how to effectively implement code review, without removing the important factor of psychological safety, and also share my experiences along the way.

What is code review?

Code review is a system where your team members critically look at the code you wrote then give you feedback on things like readability, quality, or perhaps business cases that you could have missed in your code. Your peers either learn from what you have done or help you correct your code and find bugs you might have missed.

How reviews began and how it evolved into what we have now?

The initial reason for code review was to help the whole team take ownership of the software that was being created, so each person would personally have a hand in the quality of the software that was written.

So not so long ago, but what feels like ages ago, in the magical world of Software any updates were not as streamlines as we have today. This meant there was less room for error, so these systems were built with no room for error. We still have systems like this even in today's time, for example, the firmware in your toaster.

One of the ways they prevent errors from happening in these systems was by using a code review system. This is probably not the same as what you have in mind that we use these days, but rather a meeting room with developers that all have a printed version of your code critically evaluating every line. This I could only imagine would drive the project manager mad in these days with the tight deadlines we have in this strick ‘Agile’ world we live in today.

So as the magical world of programming that we live in today changed and evolved over time so did the Code review system. We got the magical pull request system added to our version control. This means that as part of our source control we can also review the code that goes into our code, this helps prevent the code from being contaminated with code smells.

Why code review is important?

We need code review to share knowledge on the features that are being worked on and to help your team catch bugs before the code even goes out to be tested. The team will also be able to learn of different ways to write code because one person might be using language functions that you didn’t even know existed for example. This especially helped more junior developers as they might have some fundamentals that they don’t understand yet.

When we do code reviews, the problem could be caught at the lowest point of invested time, and as they say, time is money. So having code reviews is like having a extra test environment without all the hardware costs in my opinion. The people doing the reviews might catch bugs the same as what would happen at a testing level, in the same breath I don’t think code reviews would ever replace testing environment.

So code reviews will be another quality assurance gate that your code has to pass through which would be evaluated at a lower level, so the code will be evaluated at a maintainability level as well.

Code reviews also allow you to enforce code standards of the team on the project you are working, creating a more readable codebase which could help future developers understand better as to what they are reading without too much effort, letting your code live on.

Code review tools

There are tons of amazing and free tools to use when you do code review, the best tool to use will mainly depend on the source control that you are using. Most of the source control providers have features where you can apply policies to branches that require you to make a pull request before you can merge your branch in and then allows you to specify how many reviewers are required to review your code before you can merge in your code.

My takebacks from using code review

I tend to write much better code if I know someone is going to review the code that I have written so just the fact that someone is going to look at ti helps already.
I find it much easier to collaborate with people even if they are off-site as I see what new features have been added and what they are working on meaning I don’t duplicate code.
I have learnt lots of good practices from looking at the code that the people around me write and I have gotten lots of constructive criticism.
It has added an extra safety net to development processes tending to keep me from committing that bug whack-a-mole code I wrote late at night.

Merge!

Thanks for taking the time to read my take on code reviews. Now I will leave you the same way I leave all my PR’s, with a wonderful puppy gif:

What is Docker and why is there such a big hype around it

Richard Basson — Thu, 26 Sep 2019 19:41:12 +0000

What is Docker, and why is there such a big hype around it 🐋?

Well, I am here today to tell you what docker is, and more specifically containerisation. So just like you get SaaS (Software as a Service), PaaS (Platform as a Service) and IaaS (Infrastructure as a Service) you now get CaaS (Containers as a Service) which is a service provided by Docker.

Docker is the main containerisation platform that allows you to develop, run and deploy your applications using containers! So now I am going to tell you more about this amazing technology.

What is a Container?

Before I can answer this question I first have to explain what a Docker image is.

An image is an executable package that includes everything needed to run an application: the code, libraries, environment variables, and configuration files. So you have everything you need all boxed neatly together and ready for shipping.

Image Source

A container contains all the dependencies that you need to be combined with the needed operations to install and run your application on the desired environment compiled into a runtime version of your Image. This includes commands that you can run to prepare your environment for all the nitty-gritty needs that your application might have.

Why should I use Docker 🐳 ?

Have you ever had the situation where your code runs on your dev environment and as soon as you publish your code on the server it all fall apart and you get all these unexpected errors that you have no idea why you are getting them, then you get to scramble to save the release all just to find out a dependency was missing? So let’s be honest here, even with releases you still get swamped with future work and honestly we’re all humans so we tend to forget one or two things.

Well, I can tell you with Docker you won’t ever have these problems. With the containers all your dependencies will be identical from the environment you are deploying from, so you will never have a problem with missing dependencies on your QA environment if you choose to use Docker. You also won’t need to worry about forgetting something, because you will be able to set this long beforehand and test it easily.

Using Docker will also make it much simpler to set up a new dev environment, so you won’t have to worry about installing all the necessary dependencies and your app working with a specific version like Node or Python. So not only does Docker help with the deployment of apps but also development.

Image Source

Docker will allow you to encapsulate legacy projects, so the dependencies that you require will always be available. So you can set up servers that require older software and packages easily without having to worry about getting specific versions which aren’t available anymore. I have had this problem, where I needed a specific version of Devexpress which seemed to be impossible to find, so to make life easier: Dockerise.

You can use Docker to provision boxes in the cloud, and with Docker Swarm or services like Kubernetes, you can then orchestrate your clusters. I might write about this sometime, but for now, this is out of this blog post’s scope.

What is the difference between Docker and a Virtual Machine's

Docker is not OS (Operating System) dependent whereas a VM (Virtual Machine) is OS-dependent: this means you can run the same container in Windows, Mac OS (OSX) and Linux. This means your OS-dependent technology will run on any OS in a Docker container. You could run a .Net project on a Linux server! So now you can save money on your infrastructure by getting a Linux server instead of on a windows server, which I am sure is a win for everyone. You can also work on your preferred operating system and then deploy to any operating system as needed.

Image Source

Docker manages the sharing of resources like memory and CPU between the host machine and the Docker containers where a Virtual Machine virtualises the resources of the host machine. This is why any container can run on any machine.

Docker Hub

Docker has an amazing tool, it is called Docker Hub. It’s like GitHub but for Docker images, so you could find prebuilt images for your tech stack and if you can’t find one you can always create your own and share it with the Docker community for the next person that might need it!

Docker is portable

This means you can build and run your container to your dev environment and then you can ship your built container to your server and it will work perfectly as is! You can spin up your application on your app on your local machine or hosting environment in a matter of minutes!

Docker Cheatsheet

Here is a list of all the basic commands that you will need for docker to get started:

## List Docker CLI commands
docker
docker container — help
## Display Docker version and info
docker — version
docker version
docker info
## Execute Docker image
docker run <Container NAME>
docker run -p 4000:80 <Container NAME>
## List Docker images
docker image ls
docker image rm
## List Docker containers (running, all, all in quiet mode)
docker container ls
docker container ls — all
docker container ls -aq
docker container stop <Container NAME or ID>

How can I get started?

You can find more on https://docs.docker.com/get-started/ so you can start learning how to use this amazing technology and build better software. Docker has an official hello-world image that you can pull and run to get a hang of how it works, you can find it at https://hub.docker.com/_/hello-world/. One other thing I would suggest you can do to get yourself more familiar with Docker would be to host a simple Nginx website using a Docker image you can find here → https://hub.docker.com/_/nginx/.

Now that you have an overview of why Docker is such a big hype hopefully you’re as hyped up about it as the rest of the dev community. So go out there now and try the thing and make some happy whale containers, and more importantly write better software!

Serverless, because who needs servers anyways

Richard Basson — Thu, 26 Sep 2019 19:28:01 +0000

You probably came to this blogpost wondering how is this possible, what kind of sorcery
allows you to have an application work without servers? Well, in this post I am going to show
you how this is possible!

One of the main things that come up when you look up serverless is JAM stack, and no this is not just a bunch of jam jars stacked on top of each other, but an equally yummy stack of JavaScript, API’s and Markup. This is the basis of what serverless is built on.

What is the JAM stack ?

According to the official definition, it is a modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.

Serverless allows you to build applications without the use of servers. The JAM stack does not refer to specific languages, databases or operating systems, but rather the way you build the website or app: by not using servers as described in the name. So this means there are many options for databases and frameworks you can use for JAM stack.

So now that you know about the JAM stack I can tell you what makes it so awesome!

What makes JAM stack so great?!

Better performance

With JAM stack the sites files are hosted over a CDN (content delivery network)
which means that it can be hosted across multiple servers all over the world. This decreases loading time and gives minimal latency, so you can have better performance on your site!

Higher Security

The server-side processes are handled by microservice APIs. This means you leave
most of the security in the expert hands of the people who wrote these services so
between your crazy deadlines and coffee addiction, this is one less thing you have to
worry about.
Cheaper and easier scaling

With your files being hosted over CDN it means you already have load balancing covered. So your JAM stack site will be able to keep up no matter how many users connect to your website concurrently. The services that you use with JAM stack are
very cheap to use and depending on the number of operations and size of the app
most of these services are free.
Better developer experience

Yes, it is developer-friendly: you will not have to worry about keeping servers up and running, which is a big plus point. You can leave this up to the API services that you
are consuming, which makes it easier for devs to sleep at night without having to worry about the server being down.

Image Source ~(https://storage.googleapis.com/cdn.thenewstack.io/media/2017/12/537f29bc-42350470-jamstack.jpg)

My experience using JAM stack

When I heard about this I had the need to explore this further and experience firsthand what all the hype is about. I came across a bunch of tutorials on JAM stack. There were so many it was quite hard to choose so I ended up going with the one that covered most of what the JAM stack has to offer.

With JAM stack you have a lot of open-source frameworks and languages to choose from. This helps you to choose a framework you might be familiar with and decrease the learning curve that you have to learn JAM stack.

The tutorial that stuck out the most for me was a tutorial from J-Bytes, who had to create a POC (Proof Of Concept) for a project where he compared the serverless stack to one with a Node server. This was perfect to see if using this technology would be worth it. The tutorial guides you to make a Twitter/email campaign page using serverless technology. This is a very simple site and running a server for this seems like overkill. The clouds are already full of them so why add another one, right? You can follow the tutorial here
(http://robsherling.com/jbytes/index.php/2017/01/08/serverless-backends-with-aws-cloud-installs/)

When I began this, I realised how important a role AWS plays in this tutorial which uses lots of AWS services like IAM for authentication, S3 for the site hosting, API gateway for the API calls, AWS lambda for lambda functions, and dynamodb for saving the emails. You can practically handle all of your server-side operations on AWS and at a very reasonable cost. You can also use other platforms like Azure, Google cloud platform and IBM for these services.

Learning lambda was not too steep of a learning curve and I could get the hang of it in a day. I already had experience with JavaScript wich was very beneficial so if you don't have experience it might take you a bit longer but it was pretty straightforward to grasp. So in the ever-learning dev world, you can take a slight break from having to learn everything from scratch.

One of the important things I learned is to have static configuration files for each of your environments so you can easily set up a CI (Continuous Integration) pipeline to publish to your production environment and staging environments (oh yes all the buzzwords). It was a fun experience, and I encourage you to try it out as well. Below is a map of how all the services are connected with the serverless stack from the tutorial.

Image Source ~ (https://i0.wp.com/robsherling.com/jbytes/wp-content/uploads/2017/01/LamdaTwitter.png?w=625)

The tech that I found to be useful when building a serverless application

While doing this I came across a lot of tech that you can use to create your serverless application, so here is a list of tech that I found to stand out:

Lambda:

Lambda expressions allow you to run code without having a server and scales as you need to make more requests, The free tier, depending on the service that you use, ranges from 1-2 million requests per day which seem to be plenty, considering that there are 86400 seconds in a day -- you will need to invoke a function way more than once every second to reach this cap. Lambda supports Node.js, Java, C#, Go and Python, so you should be able to find a language that you might know.
Cloud-hosted NoSQL DB:

Your cloud-hosted NoSql DB will allow you to have a database without the hassle of having a server, which is the point of serverless, and they are quite cheap. These databases are easily scalable so you don’t need to worry about how much data you are storing.

Storage and content delivery:

Your website is hosted through a CDN (Content Delivery Network) when using serverless which allows you to get the lowest latency for the people who access your website. This decreases the loading times and makes your website a lot faster! So all-round awesome to use. You get about 5GB of storage for free on average, depending on the service you use.

API Gateway:

This will help you handle incoming and outgoing API requests and authorisation, and just make your life easier all-round when handling API requests. This is free for the first million requests each month on average so again this is quite cheap and not easy to deplete.

IAM:

This provides identity and access management services., If you want to have users log in on your site, this will help you manage your users mostly.

What would I create using Serverless?

What I have seen and experienced from serverless is that it is great for small projects that aren't incredibly complex. You can build a simple website to gather people's information or you can use it for your pet projects. The cost of this is very attractive if you want to make something simple and still need some server-side services - like storage for example. So if you have a low-budget simple website or app that you want to create, JAM Stack would be perfect.

There are a lot of frameworks using serverless that have specific templating for blogs, with CMS so you can easily create a blog with a CMS running client-side which cuts the servers out of the picture. This cuts costs, especially for someone who wants to create a very custom blog site, but does not want to spend a lot of money on the maintenance of their blog’s hosting. I have also seen serverless sites being used for documentation, knowledge bases, manuals and wikis. The possibilities are endless.

Now go out there and try things!

Yes, now that you know a little more about serverless, I encourage you to go try creating something using the JAM stack - and no I don’t mean Jam sandwich - but I hope you know this by now and I hope I to have sparked some interest into the JAM stack. If you would like to check out some of the frameworks you can use you can go here:
(https://www.netlify.com/blog/2017/05/25/top-ten-static-site-generators-of-2017/)
they compiled a list of the top 10 serverless frameworks of 2017 that you can try. Don’t be scared to get your creative juices flowing.

So now go out there and stop polluting the clouds with Linux servers - use serverless instead!