Showing posts with label Python. Show all posts
Showing posts with label Python. Show all posts

Securing Your APIs with Python Jose

Learn how to secure your serverless APIs with AWS Lambda Authorisers and Python Jose. We'll walk you
through the mechanics of OAuth and show you how to build a proof-of-concept with Terraform and Python.

When it comes to building serverless APIs, security is always a top concern. One way to ensure that only authorised users can access your APIs is by using an AWS Lambda Authoriser. An authoriser is a Lambda function that you can use to authenticate and authorise incoming requests to your API Gateway.

we will show you how to use AWS Lambda Authorisers in combination with Python Jose, a library for handling JSON Web Tokens (JWTs), to secure your serverless APIs. We'll start by discussing the basics of OAuth, the standard for authorisation on the web, and then move on to building a proof-of-concept with Terraform and Python.

First Steps!

First, let's take a look at the mechanics of OAuth. OAuth is an open standard for authorization that enables third-party applications to obtain limited access to an HTTP service. It works by allowing users to authenticate and authorize a third-party application to access their resources, without having to share their credentials.

There are three main actors in the OAuth flow: the resource owner (the user), the client (the third-party application), and the resource server (the API). The client sends a request to the resource server for access to the user's resources. The resource server then redirects the user to an authorization server, where the user grants permission for the client to access their resources. Once permission is granted, the resource server sends an access token to the client, which can then be used to access the user's resources.

Now that we understand the mechanics of OAuth, let's take a look at how we can use AWS Lambda Authorisers and Python Jose to secure our serverless APIs.

AWS Lambda Authorizers are Lambda functions that you can use to authenticate and authorize incoming requests to your API Gateway. They can be configured to use various authentication mechanisms, such as JWTs, OAuth tokens, or custom authentication. In this example, we'll use Python Jose to verify JWTs.

Going Deeper

First, you'll need to create a new Lambda function and add it as an authorizer to your API Gateway. Here's an example of a simple Lambda authorizer written in Python:

import json
import jose
def lambda_handler(event, context):
    # Get the JWT from the request
    jwt = event['authorizationToken']
    # Verify the JWT
    try:
        jwt_obj = jose.jwt.decode(jwt, 'secret_key', algorithms=['HS256'])
    except jose.exceptions.JWTError:
        raise Exception('Invalid JWT')
    # Return the user's email address
    return {
        'principalId': jwt_obj['email'],
        'policyDocument': {
            'Version': '2012-10-17',
            'Statement': [
                {
                    'Effect': 'Allow',
                    'Action': 'execute-api:Invoke',
                    'Resource': '*'
                }
            ]
        }
    }



This is a simple example of a Lambda function that can be used as an authorizer for your API Gateway. The function takes an incoming request and extracts the JWT from the authorizationToken field. It then uses the jose library to verify the JWT. If the JWT is valid, the function returns the user's email address as the principal ID. If the JWT is invalid, the function raises an exception.

You'll need to replace 'secret_key' with the secret key that you've used to sign the JWT. The 'email' field should be the field that holds the user's email address in your JWT.

Once you have created your Lambda function, you can add it as an authorizer to your API Gateway. To do this, you'll need to go to the API Gateway console and select your API. Then, select the Authorizers option from the sidebar, and click the Create button. You'll then be prompted to select the Lambda function that you want to use as an authorizer.

With your Lambda Authorizer set up, any incoming requests to your API Gateway will be passed through the Lambda function for authentication and authorization.

Refining the idea

To take this a step further, you can use Terraform to build out a proof-of-concept environment that includes an API Gateway, a Lambda function, and an IAM role for the Lambda function. Here is an example of a Terraform configuration that creates an API Gateway, a Lambda function, and an IAM role for the Lambda function:

resource "aws_api_gateway_rest_api" "example" {
  name = "example"
}
resource "aws_api_gateway_resource" "example" {
  rest_api_id = aws_api_gateway_rest_api.example.id
  parent_id = aws_api_gateway_rest_api.example.root_resource_id
  path_part = "{proxy+}"
}
resource "aws_api_gateway_method" "example" {
  rest_api_id = aws_api_gateway_rest_api.example.id
  resource_id = aws_api_gateway_resource.example.id
  http_method = "ANY"
  authorization = "CUSTOM"
  authorizer_id = aws_api_gateway_authorizer.example.id
}
resource "aws_api_gateway_authorizer" "example" {
  name = "example"
  rest_api_id = aws_api_gateway_rest_api.example.id
  type = "TOKEN"
  identity_source = "method.request.header.Authorization"
  authorizer_uri = aws_lambda_function.example.invoke_arn
}
resource "aws_lambda_function" "example" {
  filename = "lambda_function.zip"
  function_name = "example"
  role = aws_iam_role.example.arn
  handler = "lambda_function.lambda_handler"
  runtime = "python3.8"
}
resource "aws_iam_role" "example" {
  name = "example"
  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF
}
resource "aws_iam_role_policy" "example" {
  name = "example"
  role = aws_iam_role.example.id
  policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "logs:*",
      "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}
EOF
}

This Terraform configuration creates an API Gateway, a Lambda function, and an IAM role for the Lambda function. The API Gateway is configured to use the Lambda function as an authorizer, and the Lambda function is configured to use the IAM role.


Wrap Up!

AWS Lambda Authorizers provide a powerful way to authenticate and authorize incoming requests to your serverless APIs. By using a Lambda function to authenticate and authorize requests, you can add an extra layer of security to your APIs without having to manage servers or infrastructure.

When building a Lambda Authorizer, it is a good idea to use a JWT library such as Python Jose, to handle the JWT verification. The library provides a simple and secure way to handle JWTs and it's available in multiple languages.

Automating Compliance with Prowler with Lambda

Compliance monitoring is a critical aspect of maintaining a secure and well-managed infrastructure. Prowler, an open-source tool written in Python, allows you to automate compliance scanning and monitoring for AWS environments. In this blog post, we'll explore how to use Prowler on AWS Lambda using Terraform, eliminating the need for an EC2 instance and simplifying the compliance monitoring process.


Setting up the Infrastructure


To get started, we'll use Terraform to provision the necessary infrastructure components on AWS. Here's an example of the Terraform code required:

provider "aws" {
  region = "eu-west-2"
}
resource "aws_cloudwatch_event_rule" "prowler_schedule" {
  name                = "ProwlerSchedule"
  description         = "Scheduled rule for running Prowler"
  schedule_expression = "rate(1 day)"
}
resource "aws_cloudwatch_event_target" "prowler_target" {
  rule      = aws_cloudwatch_event_rule.prowler_schedule.name
  target_id = "ProwlerLambdaTarget"
  arn       = aws_lambda_function.prowler_lambda.arn
}
resource "aws_lambda_function" "prowler_lambda" {
  filename      = "prowler.zip"
  function_name = "ProwlerLambda"
  role          = aws_iam_role.prowler_lambda_role.arn
  handler       = "lambda_function.lambda_handler"
  runtime       = "python3.8"
  memory_size   = 128
  timeout       = 300
  source_code_hash = filebase64sha256("prowler.zip")
}
resource "aws_iam_role" "prowler_lambda_role" {
  name = "ProwlerLambdaRole"
  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF
}
resource "aws_iam_role_policy_attachment" "prowler_lambda_policy_attachment" {
  role       = aws_iam_role.prowler_lambda_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess"
}

Let's break down the Terraform code:

We define the AWS provider and specify the region.

The aws_cloudwatch_event_rule resource creates a CloudWatch Event Rule to schedule the Prowler scan. In this example, we set it to run once a day, but you can customise the schedule as needed.

The aws_cloudwatch_event_target resource associates the CloudWatch Event Rule with the Lambda function. This ensures that the Lambda function is triggered based on the defined schedule.

The aws_lambda_function resource creates the Lambda function. We provide the Python code for the Lambda function, as well as the necessary configuration such as the runtime, memory size, and timeout.

The aws_iam_role resource creates an IAM role for the Lambda function, allowing it to access the required AWS services.

Finally, the aws_iam_role_policy_attachment resource attaches the necessary IAM policies to the IAM role. In this example, we attach the "AmazonEC2ReadOnlyAccess" policy to allow the Lambda function to start the Prowler scan on EC2 instances.

Once you have the Terraform code ready, run terraform init, terraform plan, and terraform apply to provision the infrastructure on AWS. Make sure you have the AWS CLI configured with the appropriate credentials.

Writing the Lambda Function

The next step is to write the Python code for the Lambda function. Here's an example code snippet:

import prowlerlib


def lambda_handler(event, context):
    # Define the Prowler configuration
    config = prowlerlib.Config(config_file='my_config_file.yml', no_color=True)
    try:
        # Run Prowler with the specified configuration
        prowlerlib.run_prowler(config)
    except Exception as e:
        # Handle any errors that occur during the execution of Prowler
        print(f"Error executing Prowler: {e}")

Let's break down the Python code:

We import the boto3 library, which allows us to interact with AWS services.

The lambda_handler function is the entry point for the Lambda function. It receives an event and context object as parameters.

Inside the lambda_handler, we create an EC2 client using boto3.client('ec2').

We use the describe_instances method to retrieve the instances with the "Prowler" tag. You can customise this filter to match your specific requirements.

For each instance returned, we extract the instance ID and use the start_instances method to start the instance. This triggers the Prowler scan on the EC2 instance.

Finally, we print a message for each instance started, and return a success message.

You can customise this Python code to include additional functionality, such as sending scan results to an S3 bucket or notifying stakeholders via SNS.

Deploying and Running Prowler on Lambda

To deploy and run Prowler on AWS Lambda, follow these steps:

Package the Python code and any dependencies into a zip file. For example, create a file called prowler.zip and include the lambda_function.py file and any additional Python modules required by Prowler.

Run terraform init, terraform plan, and terraform apply to provision the infrastructure and deploy the Lambda function. Make sure to have the AWS CLI configured with appropriate credentials.

Once the infrastructure is provisioned and the Lambda function is deployed, the Prowler scan will be triggered based on the schedule defined in the CloudWatch Event Rule.

Monitor the CloudWatch Logs for the Lambda function to view the scan results and any logs generated by Prowler.

Remember to adjust the region, schedule, and other configurations as needed to match your requirements.

Note: This is a simplified example to demonstrate the concept. In production environments, consider adding error handling, logging, and security measures as necessary.

Wrap Up!

Automating compliance monitoring with Prowler on AWS Lambda can greatly simplify the process and help ensure the security and compliance of your AWS environment. By leveraging Terraform and Python, you can easily set up the infrastructure and deploy the Lambda function. This enables you to run Prowler scans on a regular schedule without the need for an EC2 instance.

You should experiment with different schedules, customise the Python code, and extend the solution to meet your specific compliance monitoring needs.

Happy compliance monitoring!

Pythonizing our Web App!

Ok, you asked for it! You all wanted an update for the lambda functions to use another language and
luckily, my favourite one! Python!

So let's get started!

Update the Lambda function to fetch and store data

The first step is to update the Lambda function that fetches data from an external website and stores it in a serverless database. Here is an example of the same function written in Python:

import boto3
import requests
dynamo = boto3.client('dynamodb')
def lambda_handler(event, context):
    # Fetch data from external website
    response = requests.get('https://example.com/data')
    data = response.json()
    
    # Store data in DynamoDB table
    item = {
        'id': {'S': data['id']},
        'data': {'S': data['data']}
    }
    dynamo.put_item(TableName='your-table-name', Item=item)
    return {
        'statusCode': 200,
        'body': json.dumps({'message': 'Data stored in DynamoDB'})
    }

This example uses the boto3 package to interact with DynamoDB and the requests package to fetch data from an external website, similar to the previous example. Note that the function uses python json module to parse data instead of JSON.parse() function in node.js

Update the Lambda function to retrieve data

The next step is to update the Lambda function that retrieves data from the serverless database and makes it accessible through the API Gateway. Here is an example of the same function written in Python:


import boto3
import json
dynamo = boto3.client('dynamodb')
def lambda_handler(event, context):
    # Retrieve data from DynamoDB table
    data = dynamo.scan(TableName='your-table-name')
    # Return data to user
    return {
        'statusCode': 200,
        'body': json.dumps(data)
    }

This function uses the boto3 package to interact with DynamoDB and returns the data to the user as a JSON string using json.dumps()

Re-Creating a Lambda Authorizer

A Lambda authorizer is a Lambda function that you build to authorize access to your API Gateway APIs using bearer token authentication, such as OAuth or JWT.

Here's an example of a simple Lambda authorizer function that can be used to authenticate a user using a bearer token. This function will use the Okta library to validate the token and return the appropriate policy allowing or denying access to the API Gateway endpoint.

import json
from okta.framework import OktaAuth
def lambda_handler(event, context):
    auth = OktaAuth(event)
    claims = auth.verify_token()
    if claims:
        auth_response = auth.get_auth_response(claims)
    else:
        auth_response = auth.get_auth_response(None, 'Unauthorized')
    return auth_response

This example uses the okta library to validate the token passed in the Authorization header and return the appropriate policy allowing or denying access to the API Gateway endpoint.

Updating Terraform Configuration

For the terraform configuration to use the python function in the Lambda function resource the runtime attribute needs to be updated from nodejs14.x to python3.8. Additionally, in order to link the newly created Lambda authorizer function to the API Gateway, we need to update the authorization attribute of aws_api_gateway_method resource to CUSTOM and add authorizer_id to it pointing to our newly created Lambda function.

resource "aws_api_gateway_method" "example" {
  rest_api_id = aws_api_gateway_rest_api.api_name.id
  resource_id = aws_api_gateway_resource.example.id
  http_method = "GET"
  authorization = "CUSTOM"
  authorizer_id = aws_lambda_authorizer.authorizer_lambda.id

  request_parameters = {
    "method.request.header.Authorization": true
  }
  integration {
    type = "AWS_PROXY"
    uri = aws_lambda_function.data_lambda.invoke_arn
    http_method = "POST"
    request_templates = {
      "application/json" = "{\"statusCode\": 200}"
    }
  }
}

Even Re-Create a Hello World Lambda Function

To create a simple "Hello World" Lambda function, you can use the following code:

def lambda_handler(event, context):
    message = 'Hello World!'
    return {
        'statusCode': 200,
        'body': json.dumps(message)
    }

This function returns a JSON object containing the message "Hello World!"

Verify the Deployment

To verify that everything is set up correctly, you can test the API Gateway endpoint using a tool like Postman and check the logs of all Lambda functions and the DynamoDB table to ensure that the data is being fetched and stored correctly, accessible when the user is logged in, and that the authorizer is properly handling token validation.

Additionally, you can test the "Hello World" lambda function by invoking it from the AWS Lambda console or by making a request to it via an API Gateway endpoint.

Wrap Up!

There you have it! You wanted it you got it, but by updating these Lambda functions and the Terraform configuration to use Python instead of Node.js, you can continue to use the same functionality as before but with a different programming language.

Despite updating the dependencies and language, the function code and dependencies together, remains ready for deployment with Terraform to create the same product demonstrating how modular we can make these websites!

Playing with AWS SAM

Let's take a break and play with something fun and new! In this blog post, we will go over how to use
AWS Serverless Application Model (SAM) templates to build and deploy a serverless application that includes multiple Lambda functions, an Amazon DynamoDB table, and an API Gateway. Hilariously, SAM has a squirrel for it's mascot... because the inventor likes squirrels... Ok!

Creating your SAM templates

Of course it all starts with the template!

History Lesson!

AWS SAM is an extension of AWS CloudFormation and uses the same template format. To create a SAM template, you need to define the AWS resources needed for your serverless application, including Lambda functions, DynamoDB tables, and API Gateway.

Example Template/Code

Here's an example SAM template that defines a Lambda function to fetch and store data, another Lambda function to retrieve data and make it accessible through an API Gateway, an DynamoDB table, and an API Gateway endpoint:

AWSTemplateFormatVersion: '2010-09-09'

Transform: AWS::Serverless-2016-10-31
Resources:
  DataFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: data_function
      Handler: data_function.lambda_handler
      Runtime: python3.8
      Events:
        Timer:
          Type: Schedule
          Properties:
            Schedule: rate(1 hour)
  API:
    Type: AWS::Serverless::Api
    Properties:
      StageName: Prod
      
  RetrieveFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: retrieve_function
      Handler: retrieve_function.lambda_handler
      Runtime: python3.8
      Events:
        GetResource:
          Type: Api 
          Properties:
            Path: /items
            Method: get
            RestApiId: !Ref API
  
  DataTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: myTable
      AttributeDefinitions:
        - AttributeName: id
          AttributeType: S
      KeySchema:
        - AttributeName: id
          KeyType: HASH
      ProvisionedThroughput:
        ReadCapacityUnits: 1
        WriteCapacityUnits: 1

Package and deploy your application

Once you have created your SAM template, you can use the AWS SAM CLI to package and deploy your application to the AWS Cloud.

sam package --template-file template.yaml --output-template-file packaged.yaml --s3-bucket my-bucket
sam deploy --template-file packaged.yaml --stack-name my-stack --capabilities CAPABILITY_IAM

The sam package command creates a new template file (packaged.yaml) that includes the location of your function code artefacts in an S3 bucket.

The sam deploy command deploys your application using the CloudFormation stack defined in the template. This process provisions all the necessary resources defined in the template and sets up the required permissions and triggers.

Test your application

You can use the AWS Management Console, the AWS CLI, or the AWS SDKs to test your application, for example by invoking the Lambda functions, making GET requests to the API Gateway endpoint, or querying the DynamoDB table.

Another way we can sneakily test our lambda functions is by using the in-built test feature for AWS SAM.

sam local start-api

Which will deploy the lambdas inside docker containers and allow us to interact with them with the sam cli as well as with the port we are hosting the containers on. 

Adding an Authorizer

In order to test the Lambda authorizer created in the previous blog post we will have to update the SAM template accordingly. Specifically, we'll need to create another AWS::Serverless::Function resource for the authorizer, and another AWS::Serverless::Api resource for the custom authorizer. The following example shows how to create a Lambda authorizer function and how to link it to an API Gateway using SAM template.

Resources:
  Authorizer:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: authorizer_function
      Handler: authorizer_function.lambda_handler
      Runtime: python3.8
      
  AuthorizerAPI:
    Type: AWS::Serverless::Api
    Properties:
      StageName: Prod
      DefinitionUri: authorizer_swagger.yaml
     
  RetrieveFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: retrieve_function
      Handler: retrieve_function.lambda_handler
      Runtime: python3.8
      Events:
        GetResource:
          Type: Api 
          Properties:
            Path: /items
            Method: get
            RestApiId: !Ref AuthorizerAPI
            AuthorizerId: !Ref Authorizer

This example creates a new Lambda function resource for the authorizer and another for the RetrieveFunction. Additionally, it creates an new API resource which references the Authorizer and swagger definition file authorizer_swagger.yaml.

Deploy your application with the authorizer function

Once you have updated your SAM template, you can use the AWS SAM CLI to package and deploy your application, including the authorizer function, to the AWS Cloud in the same way as before.

sam package --template-file template.yaml --output-template-file packaged.yaml --s3-bucket my-bucket
sam deploy --template-file packaged.yaml --stack-name my-stack --capabilities CAPABILITY_IAM

Verify the Deployment

To verify that everything is set up correctly, you can test the API Gateway endpoint using a tool like Postman or curl and check the logs of all Lambda functions and the DynamoDB table to ensure that the data is being fetched and stored correctly and that the authorizer is properly handling token validation.

Wrap Up!

That was fun, using AWS SAM templates you can define your serverless application resources and their configuration in a simple YAML or JSON file, and use the SAM CLI commands to package, deploy and even run and test the application, as well as test it, which can be more convenient than using Terraform. Additionally, you can include an authorizer function, created as described in the previous blog post, in the stack, with a simple addition of the necessary resources in the template and referencing them accordingly in the rest of the resources.

Quantum Programming

Quantum computing is a relatively new field and while some modern languages have added some support
for quantum programming, there is no one universally accepted standard or language for quantum programming yet. The most common languages used for quantum programming are those developed by the big cloud providers such as Microsoft's Q#, IBM's Qiskit, and Amazon's Braket, Google's Cirq, Rigetti Forest.

A Simple? Example

Here is an example of a simple quantum program using Qiskit, one of the most popular open-source frameworks for quantum computing:

 

from qiskit import QuantumCircuit, QuantumRegister, execute, Aer

# Create a 2-qubit quantum register
q = QuantumRegister(2)
# Create a quantum circuit
circuit = QuantumCircuit(q)
# Apply the Hadamard gate to the first qubit
circuit.h(q[0])
# Apply the controlled-not gate between the two qubits
circuit.cx(q[0], q[1])
# Measure the qubits
circuit.measure(q, [0, 1])
# Execute the circuit on a quantum simulator
backend = Aer.get_backend("qasm_simulator")
result = execute(circuit, backend).result()
# Print the measurement results
print(result.get_counts())

This program creates a 2-qubit quantum register, applies a Hadamard gate to the first qubit and a controlled-not gate between the two qubits, then measures the qubits and prints the results. The program uses Qiskit's QuantumCircuit class to create and manipulate the quantum circuit, and its Aer class

The above quantum program is a simple example of a quantum circuit that demonstrates the basic principles of quantum computing. In particular, it demonstrates the use of quantum gates to manipulate qubits and the use of measurements to extract information from qubits.

One practical use for this type of quantum circuit is in quantum teleportation. Quantum teleportation is a phenomenon in which the state of a quantum system can be transferred from one location to another, without any physical movement of the system itself. This is achieved by creating an entangled pair of qubits, performing a set of quantum gates on one qubit, and then measuring both qubits. The measurement results are then used to reconstruct the state of the original qubit on the receiving end.

In this example, the initial Hadamard gate on the first qubit creates a superposition state which is the first step to enable entanglement and the controlled-not gate on the second qubit is the entanglement gate, which creates the entanglement between the two qubits. The two qubits now are in an entangled state , and the state of the first qubit can be transferred to the second qubit by measuring both qubits. This measurement will also collapse the entanglement state.

It is worth noting that while this circuit is demonstrating a simplified version of quantum teleportation, this procedure is mainly a theoretical concept and a lot of advancements need to be done to be able to perform it with current technology and resources.

Let's try and go a bit deeper

A more advanced code example of a quantum program might involve using more qubits, more quantum gates, and more complex quantum algorithms. For example, Shor's algorithm is a quantum algorithm for factoring integers that has exponential speedup over classical algorithms. Here's an example of Shor's algorithm implemented again with Qiskit:

from qiskit import QuantumCircuit, QuantumRegister, ClassicalRegister, execute, Aer
from qiskit.quantum_info.operators import Operator
from math import gcd
def shor(n):
    a = 2
    while gcd(a, n) != 1:
        a += 1
    q = QuantumRegister(3)
    c = ClassicalRegister(3)
    circuit = QuantumCircuit(q, c)
    # Perform modular exponentiation using the quantum circuit
    circuit.x(q[2])
    circuit.h(q[0])
    circuit.barrier()
    for i in range(1, len(bin(n - 1)) - 2):
        circuit.barrier()
        circuit.cx(q[0], q[1])
        circuit.barrier()
        circuit.cu1(2 * 3.14159 / 2**i, q[0], q[1])
        circuit.barrier()
        circuit.cx(q[0], q[1])
        circuit.barrier()
        circuit.cu1(2 * 3.14159 / 2**(i + 1), q[0], q[2])
    circuit.barrier()
    circuit.h(q[0])
    circuit.barrier()
    circuit.measure(q[0], c[0])
    # Perform the Quantum Fourier Transform on the output
    circuit.barrier()
    circuit.h(q[1])
    circuit.u1(3.14159, q[1])
    circuit.cx(q[1], q[2])
    circuit.u1(-3.14159, q[2])
    circuit.cx(q[1], q[2])
    circuit.u1(3.14159, q[1])
    circuit.h(q[1])
    circuit.barrier()
    circuit.measure(q[1], c[1])
    # Measure the third qubit
    circuit.barrier()
    circuit.measure(q[2], c[2])
    backend = Aer.get_backend("qasm_simulator")
    result = execute(circuit, backend, shots=1000).result()
    counts = result.get_counts()
    # Extract the period of the function
    for state in counts:
        if state[-1] == '1':
            r = int(state[: -1], 2)
            if r % 2 != 0:
                continue
            else:
                break
    factor = gcd(a**r % n, n)
    return factor

In this example, the function shor() takes an integer n as an input, and returns one of its factors. The function starts by selecting a random a such that gcd(a,n) = 1 and creates 3-qubits quantum register, then applies a sequence of gates, measures the qubits, to perform the moduler exponentiation and the Quantum Fourier Transform,

The shor() function takes an integer n as an input and returns one of its factors. The function starts by selecting a random a such that gcd(a,n) = 1 and creates a 3-qubits quantum register.

Then the function performs a sequence of gates on the qubits to perform the modular exponentiation and the Quantum Fourier Transform. The modular exponentiation is used to calculate a^r mod n and the QFT is used to find the period of the function, which is required for the calculation of the factor.

After the sequence of gates is applied, the function measures all the qubits, and counts the results.

Then it goes through the result and looks for a state that has a 1 at the third bit and if so, it considers the first 2 bits as r, which represents the period of the function.

Then it applies the gcd formula with (a^r % n, n) to find the factor of the input n

It is worth noting that this algorithm has exponential speedup over classical algorithms, meaning it takes significantly less steps to find the factor of large integers. However this specific example is just a simulation and real-world implementations have a lot of constraints and limitations, such as noise, error-correction etc.

Wrap Up!

Does your brain hurt a bit after that? Mine sure did, hopefully these examples give a brief insight into the quantum leap we are likely to take in the near future, coupling these technologies with that of AI and once again streamlining our code bases to make them more efficient and scaleable... It's an exciting time!

The most efficient Python program... probably

"There's only one way to write Hello World!" I have once called out when "borrowing" code from another developer. However, how many ways can someone actually write the basic Hello World?

Hello-Wah?! 

Writing the "Hello World" program is a classic first step for many programmers learning a new language. Python, in particular, offers several ways to display the text "Hello World" that consume less CPU cycles than using the built-in print() function. In this blog post, we'll explore some of the most efficient ways to write the "Hello World" program in Python.


Using the sys.stdout.write()

The sys module provides a stdout attribute that is an instance of the file object representing standard output. By using the write() method of this attribute, we can display the "Hello World" text without the need for an additional function call.

import sys
sys.stdout.write("Hello World")

This method is relatively efficient, as it eliminates the overhead of calling the print() function and is an optimised way to write the string in the buffer of stdout

Using the print()

Ok this one is a cheat, the idea of the post was to remove the print() function, wasn't it? Well this is a slightly different use of the print function.

The print() function in Python adds a newline character by default at the end of the text. This can be removed by setting the end parameter to an empty string. This way the print function will use the default value of end parameter which is '\n'

print("Hello World", end="")

This approach reduces the overhead of the newline character and is slightly more efficient than the default behaviour of the print() function.

Using a C-extension:

Another way to optimise the "Hello World" program in Python is to use a C-extension to directly write to the standard output. This can be done using the ctypes module, which allows you to call C functions from Python. Not exactly like the program we might recognise on the right, we would write it a little differently:

from ctypes import *
libc = CDLL("libc.so.6")
libc.puts(b"Hello World")

This method is even more efficient than the previous methods, as it eliminates the overhead of the Python interpreter and uses the underlying C libraries for output.

Using the os.write() method

os.write() method of python provides a low-level way to write data to a file descriptor. It is faster than the print() and sys.stdout.write() method since it does not have the overhead of a function call.

import os
os.write(1, b'Hello World')

This is considered as the most efficient method of displaying "Hello World" in Python, this method is even faster than the method 3 as it uses OS's low-level function to perform write operation.

Wrap Up!

Well, who would have thought? here are several ways to display the "Hello World" text in Python that are more efficient than using the print() function. The methods discussed in this post include using the sys.stdout.write() method, the print() function with the end parameter set to an empty string, a C-extension, and os.write(). Each method has its own trade-offs and it's worth considering the specific requirements of your application when choosing the most efficient approach.

Don't worry you may borrow any sample from the above - Can you imagine if you owned the patent on "Hello World"? 

Getting Started with Python Logging

On top of our series on the ELK stack we have a small primer with Python to make our code a little more professional and give us something to work with as we test out our Logging stack and play with the various tools we have available to us within the Technology.

The Python logging library is a powerful tool for adding logging to your Python applications. With the logging library, you can log messages to a file, the console, or a remote logging server, and you can control the level of detail that is included in the logs. In this post, we'll look at how to use the logging library, with examples of code and pictures of the terminal.

On top of this we can make our Python code look more professional by removing the print() statements and giving our software a more formalised way of telling the user what is going on.

A very VERY basic Example

First, let's take a look at a simple example of using the logging library to log a message to the console:

import logging
logging.warning("This is a warning message")

When you run this code, you should see the following output in the console:

This is a warning message

Python logging example

As you can see, the logging library includes the log level (in this case, "WARNING") and the log message in the output. You can also specify a logger name, which will be included in the log output:


import logging 
logger = logging.getLogger("logger")
logger.warning("This is a warning message")

This will produce the following output:

This is a warning message

Python logging example with logger name


In addition to logging to the console, you can also log messages to a file. To do this, you'll need to create a logger with a FileHandler:


import logging 
logger = logging.getLogger("file_logger")
logger.setLevel(logging.INFO) 
# create a file handler
handler = logging.FileHandler("log.txt")
handler.setLevel(logging.INFO) 
# create a logging format
formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s 
handler.setFormatter(formatter)


add the file handler to the logger:

logger.addHandler(handler)

log some messages:

logger.debug("This is a debug message")
logger.info("This is an info message")
logger.warning("This is a warning message")
logger.error("This is an error message")
logger.critical("This is a critical message")


This code will log messages to the file "log.txt" at the specified log level (in this case, info and above). The log file will contain the log level, logger name, and log message, along with the timestamp.

In addition to logging to the console and to a file, you can also log messages to a remote logging server. To do this, you'll need to create a logger with a SocketHandler:

import logging
import socket  
logger = logging.getLogger("remote_logger")
logger.setLevel(logging.INFO) 
# create a socket handler
handler = logging.SocketHandler("localhost", 514)
handler.setLevel(logging.INFO) 
# create a logging format
formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s")
handler.setFormatter(formatter) 
# add the socket handler to the logger
logger.addHandler(handler) 
# log some messages
logger.debug("This is a debug message")
logger.info("This is an info message")
logger.warning("This is a warning message")
logger.error("This is an error message")
logger.critical("This is a critical message")


The above code, when run will log messages to a remote logging server at the specified host and port (in this case, "localhost" and 514). This could be adapted to point towards our LogStash configuration from previous blog posts. The remote logging server will receive the log level, logger name, and log message, along with the timestamp and this data can be stored in Elastic Search and then viewed with Kibana.

Wrap Up!

There is a Practical example of this in the Python Tutorials Blog talked about previously that deals specifically with this subject, you can have a play for yourself in this Repository.

In conclusion, the Python logging library is a powerful tool for adding logging to your Python applications. Whether you're logging to the console, a file, or a remote logging server, the logging library makes it easy to control the level of detail included in your logs and to customize the log output. With the examples provided in this post, you should be able to get started with the logging library in your own projects. 

a "Hypothetical" future proofed company

Could this be the beginning of something new?
A New way of looking at things?

One thing for certain is the future of technology is dynamic and changeable. In our very hands, the only thing that hinders it is the motivation for the technology to be created, to be used! 

The key lesson from all these trends is we’re entering an era of continual and rapid evolution, where multiple tech trends combine and feed into each other to deliver huge changes. For businesses, this means the days of incremental tech upgrades are gone forever. Continual change is the way of the future.

We are currently witnessing unprecedented rates of innovation across many industries, and experts predict that the ways that we work, communicate, and travel will radically transform over the next 15 to 20 years. Paradigm shifts always entail challenges, but it’s important to remember that they also bring an abundance of opportunity.

Moreover, technology is not a static concept. It is always evolving, dynamic, and volatile. This is bringing about a paradigm shift in the way we think, act, buy, and make a decision. BE it genomics and advanced DNA for spousal choices or autonomous vehicles, the world is fast embracing digital. If you too want in on this high impact sphere of technology then the first step would be to know the different trends that will propel the digital transformation pace in 2002 and beyond. Read on to know what these trends are

Companies need to embrace change.

Those companies that don’t change can stagnate and not develop. We can see case studies ranging from large companies such as Kodak not adhering to this and facing the consequences. Our current world is constantly evolving in terms of technology and many other challenging but innovative ways. Having the ability to face these new challenges head-on will not only develop the company as a whole but also those who work within it.

Today’s younger workers have no qualms in changing jobs if their expectations are not met. Future generations are going to need to adapt to persistent new technologies and have developed a mindset that embraces autonomy, purpose and motivation. Employee’s value growing their skills and building career currency through experiences, rather than climbing the corporate ladder.

Executives must be able to play the long game because what we’re talking about is not simple. In some cases, there’s significant cost to making the type of change we’re talking about. But the long-term payback is ensuring that your organisation has the technological capabilities to be competitive.

Technology will continue to drive the future.

It is clear that technology is coming up in a big way to drive customer experience. If you are not taking initiatives for digital transformation then you are bound to be outpaced by forwarding looking enterprises with a focus on stellar customer experiences.

It’s easy to focus on the fear or to think of technology as the enemy. But this kind of mindset is the quickest path to becoming obsolete. To remain relevant in this digital world, we have to embrace technology solutions and be open to change. To future-proof your career, you need to prepare yourself for a changing, technology-dependent workforce.

Future-proof your company with Serverless technology.

As technology is exponentially growing and bringing new challenges for maintaining the dependencies, Serverless will become a great solution. Although this technology is new, it will be more and more crucial in the coming decades.

Serverless is a very promising solution for edge applications as it allows to perform tasks on-site instead of a inside a core network (Virtual or Physical), it is usually cheap and light and speed up transactions while lowering operating costs by only the required resources. For example, some operations like verifying a signature, hashing data, or even performing a simple media transformation require faster response times and do not necessarily require a lot of computing power; they can therefore be run on Content Delivery Networks where some of the data is replicated.

Serverless architecture provides a way to keep the business focused on itself and its own core application. and therefor, you don’t have to worry about having an entire team of infrastructure engineers, platform engineers, admins, etc. The application team could be strictly in charge of that since the hosts handle everything else.

Use software as a service to save time and money.

Although, there can be a paradigm shift to get there, the journey might not be a simple lift and shift. For example, if you have certain customisied workloads that you require from an infrastructure level, you may have to re-engineer your solution to enable to function to be ported across. A classic example of this will always be older technology adopted that cannot be ported to the virtual and unstable world of the Cloud and requires a whole Operating System underlying to function.

Saying that, if you have a versatile workload that is movable you can gain a lot from this paradigm. You may be able to evaluate the older technology and use, Software as a service, another company that is providing the technology in a Cloud based way that you can consume.



Integrate DevOps and security operations to improve efficiency and safety.

As you integrate security into your DevOps pipeline, remember that people are still your greatest asset. In the traditional waterfall model, the development, security, and operations teams are siloed. As you move into the DevOps world, teams may still operate that way for a while; breaking down those traditional barriers can be the first and most important catalyst to your DevSecOps journey. Try to identify and remedy those silos quickly, create shared goals within DevSecOps teams, and drive a culture of innovation that consists of openness, transparency, ownership, and accountability. While the human resource hierarchy may remain separated, the development culture should be product-based and therefore lead by product teams. Each responsible party (dev, sec, ops) owns a portion of the product success.

If your company already does DevOps, then it’s a good idea to consider shifting toward DevSecOps. At its core, DevSecOps is based on the principle of DevOps, which will help your case for making the switch. And doing so will enable you to bring together proficient individuals from across different technical disciplines to enhance your existing security processes.

Unlike in collaborations between development and security, complexities arise when bringing together ops and security. In the former pair, you simply have to teach your developers about security best practices and have them work closely with your security team. Although this arrangement does change some things for developers, usually not many significant changes are found.

Wrap Up

Albeit the above is just fluffy principles (for now) in future threads of this blog we can begin to start to look towards how the small elements that build up a company from the ground up can be harnessed in greater detail and maybe with some case study material if time permits.

Communication (and Automation) are Key!

Introduction to ChatBots

One thing that I've learned over the years is that communication is key. Whether it's with your boss, co-workers, or family members, the best way to get things done quickly and efficiently is by having a good grasp on what's going on around you. This can be achieved through various means: status updates from project managers, meeting agendas from event planners - but there are a few other ways to make sure you're always in the know.

ChatOps?

Yes! The idea of using the communication platforms to mull over the problem and it's solution, write some code together if required but ultimately ask the bot listening in on the slack room to carry out the working tasks or report on the issues, bringing many brains and ideas to a given problem with the fastest team member at the helm... the computer! But how can we even start to build this world?

Automation

Automation is a key part of DevOps, and it's also a key part of ChatOps. Automation can be done in many different ways, but it all boils down to saving time and effort by reducing the need for human intervention. In this section we'll look at some common types of automation, as well as how you can implement them using your favourite chatbot tool.

Communication is Key

Communication is the key to any successful team. Teams need to communicate with each other in order to work effectively and efficiently. Communication ensures that all members of your team are on the same page, which results in a better working environment for everyone.

You might be thinking “But I already have a lot going on! Why would I want more work?” Well, there’s no need to worry about that! Automating communication within your organisation can actually help take some of the stress off of your plate by taking care of some tasks automatically for you. By automating communication within your organisation, you will be able to:
  • Be more organised
  • Save time
  • Decrease costs

Going further and saving Time (and Money) with automated replies

Automation is a key part of DevOps, ChatOps and Slack. It is also a big component of the Teams platform. Automation can save time by executing tasks on your behalf—and more importantly it frees you up to focus on what matters most for your business.

I’ve been using automation for years now, but I’ve also noticed that many people don’t know much about it—or how they can use it in their day-to-day lives.

Smaller Modular Pieces are Key!

There are many other little things that I can do to make my life at the office easier. But I started small.

Given what I've said so far, it might seem like I'm a big fan of automation. But that's not the case. If you're anything like me (and if you're in my office, there's a good chance that you are), then you probably don't have the time or energy to spend on automating your communication. And even if you did, there are plenty of reasons why it might not be worth your while:

  • You're not technically-inclined enough to pull off any kind of technical solution
  • Your boss has a vested interest in having more than one human on his team
  • Your co-workers might resent seeing their responsibilities automated

Tuning the Symphony

For example, if someone adds me to a channel that they created at work, it will mark it as read immediately. And if anyone messages me directly and mentions the word _"status"_ it would reply with a link to a website with our current status.

I’m sure you get the idea – I automated all of my communication so that I wouldn't have to waste any time reading what other people were saying or replying to them when I didn't want to.

Some other ideas that I came up with (which I might implement in the very near future), could be anything from automatically changing my presence depending on what application I'm using, maybe even integrating HipChat with my Calendar so people can see when I'm busy/not busy, etc.
Integrate HipChat with your calendar

  • Automatically change presence when you're busy
  • Automatically reply to messages mentioning a keyword
  • Automatically add people to channels based on keywords in their message (or another channel or group)
  • Automatically mark messages as read

The possibilities are endless!

So now that you have a better sense of how automation can be used, let's talk about some of the possibilities. You could automate almost anything! Maybe you want an email sent out each morning when you arrive at work; maybe you want to set up an automatic reminder for the first day of each month to pay all of your bills. Or perhaps you want to create a notification on Facebook every time someone tags one of your posts in Instagram—it's up to you!

The only limit here is your imagination (and perhaps technical limitations). To start small and then build up, try creating one automated task per week as part of your routine maintenance. This will give you enough time to master each step before moving onto another thing that needs automation. You'll also find that it gets easier as time goes by because once these tasks are automated they'll become habits and less thought-intensive than they once were (which means more space for creativity).

Since most of our communication is done online through various chat applications at work, it was an interesting experiment to see how far I can push automation in order to save time and effort.
As most of our communication is done online through various chat applications at work, it was an interesting experiment to see how far I can push automation in order to save time and effort.

I started off by creating a bot that would reply to messages containing the words "automate" or "automated". Then, I added another trigger for my bot: the word "test". When anyone sends me a message with either one of these words in it, my bot automatically starts sending them responses from some examples provided by IBM Watson. It turns out that there are lots of interesting articles about different ways you can use machine learning technology in your daily life. Some examples include: recipes for dinner tonight based on what's in your fridge and what you're craving; recommendations for books based on your favourite authors; or even finding new music artists whose style fits your tastes better than Taylor Swift's music!

Wrap Up!

As you can see, there are many possibilities when it comes to automating your communication. It's not just limited to Slack or HipChat either; there are other products out there that do similar things like FlowDock (which I think is awesome!). So if this type of thing sounds interesting to you, why not give it a try? Who knows where it could lead?

Serverless technology is the future

Serverless is a great option for many organisations. It limits the number of things your development

teams need to think about while still freeing them to develop whatever custom application functionality you need. As well as this without the administrative burden of servers, your other operational teams like security can get down to securing the product as a
 cloud provider usually carries out the routine work of provisioning, maintaining, and scaling the server infrastructure for you!

Saying this, Serverless just shouldn’t be thought of as the only solution. It needs to be applied selectively and within contexts where it makes sense. Serverless is a very promising solution for edge applications as it allows the performance of tasks on-site instead of from the data centre, as is usually the case, using only the required resources.

For example, some operations like verifying a signature, hashing data, or even performing a simple media transformation require faster response times and do not necessarily require a lot of computing power; they can therefore be run on Content Delivery Networks where some of the data is replicated. 

Infrastructure as Code

Infrastructure as Code (IaC) is a process that uses a high-level descriptive coding language to automate the provision of IT infrastructure. Infrastructure as Code is one way of improving the standard of infrastructure management and time to deployment. By using tools, languages, protocols, and processes, IaC safely helps create and configure infrastructure elements in a matter of seconds. With IaC, configuration files are created. These contain your infrastructure specifications, and this makes it easier to edit and distribute configurations. It also makes sure that you service the same environment every time. 

This is further promoted with the power of Serverless technology with functions that are executed in stateless containers with compute resources for running a function are provisioned only when invoked. No data is persisted in RAM or written to the disk. Once the request has been fulfilled, the state of the app is reset and there is no memory of the transaction. Making a new request calls for the resources to be provisioned from scratch and the code is executed without any reference to the previous invocation.

Serverless technology is the future of cloud computing. In the past, developers had to use virtual machines and install server software in order to host their applications. However, with serverless technology, developers can deploy applications without having access to any infrastructure or managing servers. This article will explain how serverless differs from traditional architectures and why it can be a great fit for enterprise-level projects.

Serverless Definition

Serverless technology is a software development model, or way of building and deploying applications that does not require servers. The basic idea of serverless computing is that you don't have to manage your own servers or worry about scaling since all the required resources are provided by the service provider.

Serverless platforms like AWS Lambda (the most popular one) abstracts the infrastructure layer from developers since they only need to focus on writing code for their application and then deploy it using those platforms' APIs.

What is a serverless model?

Serverless is a model for building and running applications. Serverless applications do not require you to provision or manage any servers. All you need to run your code is an API Gateway, which provides access to all of the services needed by your functions as well as authentication and authorization. Serverless also abstracts away machine maintenance so that you can focus on writing code while Amazon Web Services handles machine management tasks such as function execution, load balancing, auto-scaling and more.

The fundamental architectural style of serverless applications is event-driven: every time something happens (an instagram photo gets posted), it triggers an event (e.g., “photo posted”). These events are then processed by stateless functions or microservices (which could be either managed or self-hosted). This can dramatically reduce maintenance costs since you don't need someone maintaining any servers 24/7; instead we take advantage of the elasticity provided by cloud providers like AWS Lambda which lets us run thousands of parallel instances depending on how many users we expect at any given time which means our resources are always being used optimally - there's no need for overprovisioning or underutilization which would otherwise result in wasted money spent on unused capacity

How does serverless differ from other cloud-based architectures?

Serverless differs from other cloud-based architectures in that it is event-driven. In contrast to the traditional client-server model, serverless applications can be built and deployed without needing to manage infrastructure or provision servers. This allows developers to focus on their code and the user experience rather than worrying about scaling, security patches, failovers, etc. It also means you pay only for what you use—you don't have to pay for idle servers or capacity you aren't using.

Serverless architecture will be the next big thing in cloud computing because it allows us all to build and deploy applications faster than ever before while also giving developers more freedom over how they write their code.

Architectural considerations for serverless

  • You should architect your serverless application in a way that makes sense for the type of application you're building, as well as the capabilities of the services.

  • For example, if you want to build an API Gateway-based application, then Lambda functions will be ephemeral and stateless, which means they can't store any data. This can be inconvenient since many modern applications require some form of state management (for example, session storage). In this case, you'll need a consistent data storage solution that works with API Gateway and Lambda.

  • Alternatively, if you're building a multi-tenant app where each tenant has their own dedicated resources (such as databases), then there's no need for additional services such as API Gateway or Lambda. You could just use DynamoDB directly without having to worry about other architectural considerations associated with using those services together with DynamoDB.

Why go serverless?

Serverless has many benefits and is a great choice for a diverse set of use cases.

  • Save money on the cloud. Serverless computing is an easier way to pay for only what you need. You don't have to spend time managing servers or worrying about capacity planning, because the cost of running your application is based on usage rather than provisioned capacity.

  • Use resources more efficiently with serverless technologies like Amazon Lambda, Azure Functions, App Engine, OpenWhisk and more. These services automatically scale up or down as needed to meet traffic demands without incurring large expenses during off hours or periods when there’s little activity in your app (like weekends). This can save money over time by lowering your monthly fees compared with traditional hosting models that may require keeping machines parked most of the week (or month).

  • Automate common operational tasks using event-driven architectures such as those found with AWS Lambda functions or Azure Logic Apps that trigger actions based on events such as webhooks from other applications like Salesforce CRM integration; email notifications sent by Mailgun; etc.)

Serverless advantages and benefits

Serverless advantages and benefits

There are many advantages to using serverless technology. Some of the most important benefits include:

  • Cost savings - Serverless functions are billed only for the time they run, so you don’t have to pay for idle instances. If a function runs less frequently than anticipated, you will likely save money on your bill.

  • Scalability - Your application can scale as needed without managing servers or adding more infrastructure, which reduces costs even further. For example, if there is an increase in traffic after a company promotion it can be scaled quickly without adding any new hardware or hiring additional staff members.

  • Reduced downtime - With traditional cloud hosting providers like Amazon Web Services (AWS), downtime would occur if there was an issue with their infrastructure such as losing power or experiencing network issues! This is not an issue with serverless because it doesn’t use dedicated servers; instead each function runs independently from other functions within the same region so there is no risk of downtime due too someone else having problems elsewhere on AWS's network."

Advantages of the AWS Lambda + API Gateway stack

The AWS Lambda + API Gateway stack has many advantages over other serverless platforms:

  • Cost savings. It's cheaper to run functions on AWS Lambda than it is to run them on a traditional server. This particularly benefits startups that need to scale up their products quickly and don't have the funds to make large capital investments in servers and infrastructure.

  • Scalability. With AWS Lambda, you can easily scale up or down your application based on demand—something that would be difficult or impossible with a traditional web server setup (where scaling requires adding more hardware).

  • Speed of development. With no need for servers or infrastructure, there's also less time required for development; you can build your app faster without having to worry about configuring anything first!

  • No need for managing servers/infrastructure - A lot of time spent building apps is spent setting up and managing the underlying systems that power them instead of actually creating something valuable for users! Serverless technology enables developers who want freedom from this burden so they can focus solely on their code instead - which means faster development cycles overall!

Challenges of the serverless model

While serverless technology is promising, it’s not all rainbows and butterflies. The model has its challenges that developers need to be aware of before adopting it.

  • Cost: Serverless comes with trade-offs in pricing. You pay for each request rather than paying for the entire duration of a service being used. This can result in unpredictable expenditure if you have multiple services running on a single function or if you aren’t careful with your usage patterns.

  • Security: The traditional concept of firewalls has been removed from serverless computing because there isn't a machine with an IP address that can be blocked from accessing resources. Instead, you must use other methods like identity management systems such as Amazon Cognito if your app uses user authentication credentials (which most apps do).

  • Performance: Serverless computing is more expensive than traditional deployments because it requires more frequent provisioning and scaling up/down due to many factors including network performance issues between client applications and cloud providers as well as resource contention within each provider's datacenter footprint area where applications may reside at any given time (i.e., AWS availability zones vs regions). Because these factors are out of our control we cannot guarantee consistent performance across multiple environments so this must be factored into budget calculations when designing new projects using serverless technologies."

Wrap up!

Serverless is a game changer. It’s an architecture that’s designed to be better, faster and more cost-effective than traditional models. With the rise of cloud computing and the evolution of new deployment options like serverless, businesses can finally take advantage of all the technology has to offer without having to worry about maintaining servers or paying for servers they don’t need.

However, Serverless computing is still a relatively new technology. Its future depends on the ability of service providers to resolve some of the drawbacks listed above — most importantly, cold starts. Providers need to cut the time it takes to execute a function after it’s been in the idle state for a while. Solving this issue will decrease latency and ensure a seamless user experience. We know from the past years that code only/IaC is the future. 

I am starting to write a small proof of concept application to show the speed of this which can be found here. Check it out and have a play yourself!