Exploring Advanced Widgets for Your GitHub Pages

In our previous blog post, we learned how to create an impressive landing page on your GitHub profile using a repository with the same name as your GitHub ID. We also briefly touched upon some advanced widgets that you can add to enhance your profile. In this follow-up blog post, we'll take a deeper dive into the various widgets available for your GitHub Pages. These widgets will help you showcase your skills, projects, and contributions in a visually appealing and interactive manner.

GitHub Readme Stats Widget

The GitHub Readme Stats widget by Anurag Hazra allows you to display detailed statistics about your GitHub profile. In addition to the top languages used, you can showcase your total commits, contributions, followers, and more. To add this widget to your profile, insert the following code into your README.md file:

```markdown
[](https://github.com/anuraghazra/github-readme-stats)

```

You can customise the appearance of the widget by changing the theme parameter to one of the available options, such as "radical," "gruvbox," or "dracula." Explore the GitHub Readme Stats repository for additional customisation options.

GitHub Activity Graph Widget

The GitHub Activity Graph widget provides a visual representation of your GitHub activity over time. This widget displays a calendar heat-map, where each square represents a day, and the colour intensity represents the level of activity. To add this widget to your profile, insert the following code into your README.md file:

```markdown
[](https://github.com/ashutosh00710/github-readme-activity-graph)
```

You can customise the appearance of the graph by changing the theme parameter to one of the available options, such as "github," "dark," or "rogue." Visit the GitHub Readme Activity Graph repository for more customisation options.

GitHub Repository Card Widget

The GitHub Repository Card widget allows you to showcase your repositories with a visually appealing card layout. You can display information such as the repository's name, description, stars, forks, and language. To add this widget to your profile, insert the following code into your README.md file:

```markdown
[](https://github.com/your-github-username/your-repo-name)
```

Replace `your-github-username` with your actual username and `your-repo-name` with the name of the repository you want to display. You can customize the appearance of the card by changing the theme parameter and adding additional parameters such as `show_owner`, `show_icons`, or `hide_border`. Refer to the GitHub Readme Stats repository for detailed customization options.

GitHub Profile Trophy Widget

The GitHub Profile Trophy widget allows you to showcase your achievements and milestones on your profile. It displays trophies for various accomplishments, such as the number of followers, repositories, stars received, and more. To add this widget to your profile, insert the following code into your README.md file:

```markdown
[](https://github.com/ryo-ma/github-profile-trophy)
```

Replace `your-github-username` with your actual username. You can customise the appearance of the trophies by changing the theme parameter, adding a title, or excluding specific types of trophies. Visit the GitHub Profile Trophy repository for more customisation options.

Wrap Up!

By exploring the various advanced widgets available for your GitHub Pages, you can create a highly personalised and interactive landing page on your GitHub profile. These widgets allow you to showcase your skills, contributions, and achievements in a visually appealing and engaging manner. Experiment with different widgets, customise their appearance, and make your landing page truly reflect your coding journey. With these powerful widgets at your disposal, your GitHub profile will leave a lasting impression on visitors and potential collaborators!

GitHub Landing Pages

Your GitHub profile is not only a place to showcase your projects and contributions but also an
opportunity to leave a lasting impression on visitors. By creating a landing page with advanced widgets, you can make your profile stand out and demonstrate your skills in a visually appealing way. In this blog post, we'll guide you through the process of creating a landing page on your GitHub profile using a repository with the same name as your GitHub ID. We'll also explore some advanced widgets that you can add to enhance your profile.

Sign in to GitHub

If you haven't already, sign in to your GitHub account. If you don't have an account, you can create one for free.

Create a New Repository

Click on the "+" icon in the top-right corner of the GitHub homepage and select "New repository" from the dropdown menu. Enter your GitHub ID as the repository name.

Customise Your Repository

Add a description to your repository to give visitors an idea of what your landing page is about. Be creative and let your personality shine through!

Create a README.md File

To create your landing page, you'll need a README.md file. Check the box next to "Initialize this repository with a README" to create the file automatically.

Design Your Landing Page

Open the README.md file by clicking on it within your repository. You can use Markdown syntax to format the text and add visual elements. Let's explore some advanced widgets you can add to your landing page.

GitHub Stats Widget

The GitHub Readme Stats project by Anurag Hazra allows you to display your GitHub stats, such as top languages used, on your profile. Add the following code to your README.md file, replacing `your-github-username` with your actual username:

```markdown
[](https://github.com/anuraghazra/github-readme-stats)
```

You can customise this widget by changing the colour, limiting the number of languages shown, and more. Refer to the GitHub Readme Stats repository for detailed customisation options.

GitHub Activity Widget

The GitHub Activity widget allows you to display your recent GitHub activity on your landing page. Add the following code to your README.md file:

```markdown
<!--START_SECTION:activity-->
<!--END_SECTION:activity-->
```

This widget will automatically populate with your recent activity, such as commits, pull requests, and issues.

GitHub Gists Widget

If you frequently use GitHub Gists to share code snippets, you can showcase them on your landing page. Add the following code to your README.md file:

```markdown
<!--START_SECTION:gists-->
<!--END_SECTION:gists-->
```

This widget will display your latest Gists, making it easy for visitors to explore your code snippets.

Feel free to explore other widgets and tools available to enhance your landing page further. You can add project cards, social media badges, or even embed interactive visualisations.

Commit and Publish

Once you've designed your landing page and added the desired widgets, it's time to commit your changes. Scroll down to the bottom of the README.md file, enter a commit message, and click on the "Commit changes" button.

Enable GitHub Pages

To make your landing page accessible to the world, enable GitHub Pages. Go to the main page of your repository, click on the "Settings" tab, and scroll down to the "GitHub Pages" section. Select the branch you want to use for your landing page (usually the main or master branch) and click on the "Save" button.

Visit Your Landing Page

Congratulations! You've successfully created an impressive landing page on your GitHub profile. To view your landing page, go back to the "GitHub Pages" section in your repository's settings. You'll find a link to your newly created landing page. Click on it and admire your beautifully designed profile!

Wrap Up

By creating a landing page on your GitHub profile and adding advanced widgets, you can showcase your skills and projects in an engaging and visually appealing way. The combination of a well-designed landing page and advanced widgets will leave a lasting impression on visitors and demonstrate your expertise as a developer. So go ahead, follow the steps outlined in this blog post, and create an impressive landing page that reflects your coding journey.

Happy coding!

Managing Security in a Microservices Architecture World

Micro Services architecture has become an increasingly popular method for building and deploying
software applications, offering a range of benefits such as increased agility, scalability, and efficiency. However, with the increased complexity of Micro Service Architecture comes new security challenges that organisations must address.

In this post, we'll explore some of the key security challenges of Micro Service Architecture and how DevSecOps can help organisations to effectively manage security in this environment.

Security Challenges of Micro Service Architecture

Increased complexity: One of the biggest challenges of Micro Services architecture is the increased complexity of the system. With multiple, interconnected Micro Services, it can be difficult to understand how security vulnerabilities in one service can impact the security of the entire system.

Configuration management: Another challenge of Micro Service Architecture is ensuring that each service is configured securely. With many services to manage, organisations must have a robust and consistent configuration management process in place to ensure that services are configured securely and consistently.

Lack of visibility: Micro Service Architecture can also make it difficult to see the big picture and understand the security posture of the entire system. With many services and components, it can be difficult to get a comprehensive view of the system's security status.

Coordination between teams: Another challenge of Micro Services architecture is coordinating security efforts between teams. With multiple teams working on different services, it can be difficult to ensure that security practices are consistent across the entire system.

Addressing the Security Challenges of Micro Service Architecture

Automated security testing: Automated security testing is a critical component of DevSecOps, and it can help organisations to identify security vulnerabilities in Micro Services architecture more quickly and efficiently. Automated security testing tools can be used to test the security of individual services and the entire system, providing organisations with a comprehensive view of their security posture.

Security-focused collaboration: DevSecOps encourages collaboration between development and security teams, which can help organisations to better coordinate their security efforts and ensure that security practices are consistent across the entire system

Continuous integration and deployment: Continuous integration and deployment (CI/CD) is a key principle of DevSecOps, and it can help organisations to ensure that security practices are integrated into the development process and that security issues are addressed quickly and efficiently.

Centralised security management: DevSecOps can also help organisations to centralise their security management processes, making it easier to manage security in Micro Service Architecture and ensuring that security practices are consistent across the entire system.

Wrap Up!

The security challenges of Micro Service Architecture can be daunting, but DevSecOps can help organisations to effectively manage security in this environment. By automating security testing, fostering collaboration between development and security teams, integrating security into the development process, and centralising security management processes, organisations can build a secure and stable Micro Service Architecture that protects against threats and vulnerabilities.

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!

m04r Data for the S3 App!

Now in our journey we need to add more tasks to build the front end. In this blog post, we will build out two Lambda functions and a serverless database to fetch and store data from an external website and make it accessible to a logged-in user through an API Gateway and by doing this we can no have more data available to our application out of the users raw reach and safely behind our API that will deal with any connection or credential issues.

Create a Lambda function to fetch and store data

The first step is to create a Lambda function that periodically fetches data from an external website and stores it in a serverless database. One way to achieve this is to set up a CloudWatch event to trigger the Lambda function on a regular schedule.

Here's an example of a Lambda function written in Node.js that fetches data from an external website using the request package and stores it in a DynamoDB table:

const AWS = require('aws-sdk');

const request = require('request');
const dynamo = new AWS.DynamoDB();
exports.handler = async (event) => {
    // Fetch data from external website
    const response = await request.get('https://example.com/data');
    const data = JSON.parse(response.body);
    // Store data in DynamoDB table
    const params = {
        Item: {
            "id": { S: data.id },
            "data": { S: data.data }
        },
        TableName: "your-table-name"
    };
    await dynamo.putItem(params).promise();
    return {
        statusCode: 200,
        body: JSON.stringify({
            message: 'Data stored in DynamoDB',
        }),
    };
};

This function uses the request package to fetch data from an external website, parses it as JSON, and stores it in a DynamoDB table using the AWS.DynamoDB client. The name of the table and the structure of the data being stored will depend on the external website you are fetching data from.

Create a Lambda function to retrieve data

The next step is to create a Lambda function that retrieves data from the serverless database and makes it accessible through the API Gateway. This function should be triggered when a user makes a request to a specific endpoint, such as /data.

Here's an example of a Lambda function written in Node.js that retrieves data from a DynamoDB table and returns it to the user:

const AWS = require('aws-sdk');
const dynamo = new AWS.DynamoDB();
exports.handler = async (event) => {
    // Retrieve data from DynamoDB table
    const params = {
        TableName: "your-table-name"
    };
    const data = await dynamo.scan(params).promise();
    // Return data to user
    return {
        statusCode: 200,
        body: JSON.stringify(data),
    };
};

This function retrieves data from the DynamoDB table by scanning the table and returns it to the user as a JSON string.

Create a serverless database

We will use DynamoDB as the Serverless database and use terraform to create the DynamoDB table for storing the data.

resource "aws_dynamodb_table" "example" {
  name = "your-table-name"
  billing_mode = "PAY_PER_REQUEST"
  hash_key  = "id"
  attribute {
    name = "id"
    type = "S"
  }
  attribute {
    name = "data"
    type = "S"
  }
}

Integrate with API Gateway

We will need to integrate the Lambda function created on step 2 to the API Gateway so that it is triggered when a user makes a request to a specific endpoint. This can be done by creating a new resource and method in the API Gateway and linking it to the Lambda function.

Here's an example of how to create a new resource and method in the API Gateway using Terraform:

resource "aws_api_gateway_resource" "example" {
  rest_api_id = aws_api_gateway_rest_api.api_name.id
  parent_id = aws_api_gateway_rest_api.api_name.root_resource_id
  path_part = "data"
}
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 = "NONE"
  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}"
    }
  }
}

This Terraform code creates a new resource and method in the API Gateway, with the path /data and linked to the Lambda function created on step 2. This will trigger the Lambda function when a user makes a GET request to the /data endpoint and return the data stored in the DynamoDB table.

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 both Lambda functions and the DynamoDB table to ensure that the data is being fetched and stored correctly and accessible when the user is logged in.

Wrap Up!

Now by creating these two Lambda functions and a serverless database to our setup, you can fetch and store data from an external website or another service and make it accessible to a our user through an API Gateway using what we learned from other posts we could use the logic to make sure our users are logged in with an identity as well!

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"? 

Going Serverless with GCP - YAML to JSON App

 Let's do some Google Cloud Platform

Feels like a big change for me as I am usually in the AWS platform for clients, but found some time to have a play with the GCP suite for making serverless Apps. Nothing fancy, let's do a basic app that will turn JSON to YAML in a language I don't usually dabble in... Why not try Node?! Ok Here we go!

Getting all signed up!

Firstly things first, we will need to grab ourselves an account with Google and be on the look out for any developer/trainer accounts as they sometimes get given to us for free!

Deployment

How should this be deployed? Well of course if we are doing things properly, we can do this with Terraform, works across the Cloud platforms and gets us to where we need to be fast without all that clicking around. We surely had enough of that getting our developer accounts to start with right?

On to the Magic!

First, create a new Terraform configuration file and define the provider for GCP, I like to name mine providers.tf to break out the code base and direct future developers to where certain Terraform elements are located:

provider "google" {

  project = "my-project"

  region  = "us-central1"

}

Our credentials should be configured from the command line and kept outside of our providers.tf file to allow versatility in deployment, before running any Terraform commands we can authenticate with Google using:

gcloud auth application-default login --no-launch-browser

If we are not in a place to use a web browser for authentication we can copy and paste the returned link to where we can, gain an authorisation code to complete the login process. Because of the above commands a number of environment variables will be set that allow us access to the Google Cloud Platform with Terraform. 

Next we will need to create create a Google Cloud Function resource and specify the runtime as Node.js:

resource "google_cloud_function" "json_to_yaml" {

  name     = "json_to_yaml"

  runtime  = "nodejs12"

  trigger_http = true

}

Set the function's code by specifying the location of the code file and the entry point for the function:

resource "google_cloud_function" "json_to_yaml" {

  source_archive_bucket = "my-bucket"

  source_archive_object = "source.zip"

  entry_point           = "jsonToYaml"

}

And now the NodeJS...

To transform the JSON input into YAML, you can use a Node.js library called js-yaml. Include this library in your package dependencies by adding it to the package.json file:

{

  "dependencies": {

    "js-yaml": "^3.14.0"

  }

}

Now, you can create the function that will transform the JSON input into YAML. In the code file, import the js-yaml library and create the function that will handle the transformation:

const yaml = require('js-yaml');

exports.jsonToYaml = (req, res) => {

  const json = req.body;

  const yamlOutput = yaml.safeDump(json);

  res.set('Content-Type', 'text/yaml');

  res.send(yamlOutput);

};

Finally, to deploy the function, run the following command:

terraform apply

This will create a new Cloud Function that can be triggered by an HTTP request, and will transform the JSON body of the request into YAML output. We can test this with the following command.

curl --header "Content-Type: application/json" --request POST --data '{"username":"xyz","password":"xyz"}' \ http://<End Point Address>

Wrap Up!

And there you have it a small Serverless self contained application that will allow us to turn our JSON strings into YAML. Not the most advanced example but illustrates the basic Serverless concept, in future blogs we can have a look at the more advanced examples and growing out our Infrastructure in to fully grown Applications.

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.

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!

Happy 10th Birthday Securing the Cloud!

It's my birthday and I'll blog/tag/label what I want to!

So while doing a lot of the prep work to create this site, I began organising my old code bases, ripping the good from them and create illustrations and examples... Hilariously I noted some of the dates of the code I was going over and some of it, over a decade in age!

I thought that deserved a little celebration and for some giggles and anonymised list of shenanigans I have witnessed over the times as I have grown with the Cloud.

Top 10 Funniest Moments!

1. Clients constantly asking for data to be removed from interesting places: When people hear "Security" they immediately jump to hacker and "can you hack $thing?" or "could you get rid of this photo from $X?" this has lead to some funny things I should not talk about...
2. Client Celebrations: One too few of these, it's always about what happens after the work is done!
3.  Working with a remote client to do some Network Gymnastics: A tale of deadlines, fast paced delivery and a broken VPN leading to a need to create a reverse shell from the clients system, to me, to connect to the network as SSH direct to the instance was banned. The things we do for our clients!
4.  Reverse Engineering and Early Days API: Before we had standards and everyone was building rapidly, reverse engineering how things like the Foreman were working to create wrappers and scripts like YAFCT to interact provided so, so many sleepless and coffee driven evenings, I do miss those times!
5.  Getting told off for talking about Security Vulnerabilities: ...Probably should have lead with the fact that the exploit involved an toy that is more targeted towards adults... <INSERT EGGPLANT EMOJI HERE>
6.  BitCoin mining rig found in Production: A security lesson to monitor ALL regions regardless if you are using them or not! Sadly the private keys were invalidated, it would have been worth a lot right now!
7.  Playing Apache Pong and Gource with one of the busiest sites on the Internet: ....Then watching it drop to nothing as the paywall was implemented!
8.  Using Facebook links to wind up the Web Developers with XSS: A warning to all developers to sanitise your inputs and not to trust anything, including the URL variable!
9.  Migrating Successfully to the Cloud so well we brought the original malware along too: A promotion for rebuilding into the cloud instead of straight migration - finding out you have pulled malware that has been living on your DC system to the Cloud is not the best surprise, but a funny experience!
10. Always Staying in the wrong hotel: If you know the story here, you know about the fun and games. Sadly, this one cannot be discussed!

Wrap up!

I hope you have enjoyed a quick look down some of the fun shenanigans as much as I have over the years, maybe throughout this blog you will find other references to some of the above, but as well, don't be afraid to reach out and get in contact!

Public Cloud, Private Cloud, Red Cloud, Blue Cloud!

Cloud computing is a type of IT service that enables users to access and use software, storage, and other services over the internet. The foundation for cloud computing is based on virtualisation technology. Cloud computing has become one of the most popular ways to store data, applications or any other kind of information in recent years.

Some organisations are using this new model to increase their business efficiency and productivity while others are migrating their legacy systems into the cloud environment because they see it provides greater flexibility than traditional hardware-based infrastructure models. In this article we will explain what exactly is public cloud and private cloud both their pros and cons so you can decide which one is best suited for your business needs

Cloud computing is a buzzword in the IT industry. It’s been around for more than 15 years and has become a core component of modern business technology. The term “cloud” refers to both a delivery model and an infrastructure model that enables enterprises to deliver, maintain and consume IT services via networks over the internet.

Cloud computing is essentially a way of delivering computing services that can be on demand, scalable and flexible while optimising utilisation rates by sharing resources among multiple users at any time.

What is Cloud?

Cloud computing is a model for enabling ubiquitous, on-demand access to a shared pool of configurable resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

The cloud model promotes availability and is composed of five essential characteristics (On-demand self-service, Broad network access, Resource pooling, Rapid elasticity and Measured service). These characteristics provide specific capabilities that enable the deployment of application frameworks such as Java EE 7 Enterprise Applications with its Java Development Kit (JDK) and WebSphere Liberty Profile server.

What is the difference between Public and Private Cloud?

Public Cloud is a cloud computing service that is sold on a pay-per-use basis. It’s generally more expensive than Private Cloud, but the upfront cost might not be as high and can be offset by the lack of need for additional software licenses.

Private Cloud is a cloud computing service that is provided by a single organisation for its own use. The “private” aspect means there aren’t any restrictions on who uses it or how it’s used (e.g., encryption). In other words, unlike public clouds where data is shared among many customers, private clouds only contain data owned and managed by one company or organisation

• Public Cloud: A cloud computing model where the infrastructure and software is owned and operated by a cloud service provider.

• Private Cloud: A type of cloud computing where the infrastructure is owned and operated by the company using it.

Which cloud model is best for my business?

The cloud model that's best for your business depends on a number of factors.

While public cloud services are popular among all kinds of companies, there are some industries where the private or hybrid models work better. For example:

• Most small businesses don't have enough resources to support their own infrastructure and therefore rely on public cloud services.

• Small businesses that want access to enterprise-grade security features might consider using a private cloud (or even a hybrid cloud) instead of a public one in order to keep their data protected from hackers, who tend to target large organisations with more resources than they have at their disposal.

• Enterprises often use hybrid clouds because they can be less expensive than building an entirely new physical data centre but still give them ultimate control over how they manage their infrastructure and protect sensitive information stored within it

Wrap up!

This article looked at differences between public and private cloud. If you’re looking for more information on how to use a cloud-based solution, we recommend reading my other blog posts while more intricate details to be added as this site develops! Alternatively, get in contact for some customised consultancy!

Bump Post for external content - Securing Cloud Systems

A shameless plug to promote external content and collect the tags <SMOKE BOMB!>

What did you do this time?

A revamp of a rough document sent to my company by Alert Logic to investigate Early Security Tooling 

https://www.slideshare.net/Cloudreach/cloudreach-voices-stay-ahead-of-the-hackers-a-guide-to-offensive-security-60330147

contains a break down of some of the tools that hackers will use when they attempt to get into your system, these tools work actively and passively to help them hone their attack and work out their victim. By understanding the principles used we can better protect our environments.

Check it out!

Bump Post for external content - Cost Control Exercise!

 A shameless plug to promote external content and collect the tags <MANIACAL CACKLES!>

What did you do this time?

A blog post that looked to educate users of mistakes made in our own lab by cost cutting tools that actually made things more expensive.

This would lead to some more cost cutting changes within our lab procedures and prevent other engineers having the same issue in the Future.

https://www.cloudreach.com/en/technical-blog/destroy-your-development-environments-to-control-costs/

Check it out!

Bump Post for external content - OWASP Juice Shop!

 A shameless plug to promote external content and collect the tags...

/me twirls a fictions moustache!

What did you do this time?

A blog post that looked to educate users on the practical examples of breaking into Web Applications and what can be done with them.

https://www.cloudreach.com/en/technical-blog/get-the-squeeze-on-owasp-juice-shop/

Check it out!