Why build a hit counter from scratch on AWS when other services exist for the purpose?

Consider this as a fun little hands-on project that hones your AWS, IaC and Python programming skills!

Overview

Here is a quick overview of all the services that will be deployed in this project:

• S3 bucket for hosting the static assets of the web application

• ACM certificate for enabling secure communication over HTTPS

• Cloudfront for serving the static assets across edge locations for our global user base

• DynamoDB will be our NoSQL database choice

• Lambda function for running our backend logic and eventually getting and setting the values in the database.

• Lambda function URL will be used rather than an API Gateway

Prerequisites

• An AWS account and some AWS experience

• Some Infrastructure as Code (IaC) knowledge

• An AWS CLI profile configured for your development environment to access your AWS account

Fork the repository

Before we start, make your fork of the repository containing the full source code. This will be your own copy giving you the flexibility to experiment and explore.

Lambda function logic

The handler function will be the entry point when lambda is invoked. The handler calls the update_hit() function which updates the 'hit_count' attribute of a specific item (key = "1") in the DynamoDB table. The UpdateExpression parameter defines the update operation to perform. Here, it uses the 'ADD' action to increment the value of the 'hit_count' attribute by 1. The updated value of 'hit_count' is returned and we expect that as a string. The string zfill() method is used to pad a copy of this string with zeroes on the left. Resulting in the transformation "234" -> "00234"

Terraform provider

Time to write some Terraform for provisioning our resources. First, we declare the provider block in provider.tf file. The default_tags mean that all resources created with this provider will be tagged with the provided map.

provider "aws" {
  profile = "YOUR_CLI_PROFILE"
  region  = "us-east-1"
  default_tags {
    tags = {Name = var.name}
  }
}

Variables

We define some variables we need in variables.tf. We also declare the full_name local variable, which is a concatenation of name and env variables. This variable will be mainly used as the (aws-end) name of major resources. This way we can easily replicate the project for a different environment, such as another region within the same account, without worrying about name collisions.

variable "name" {
  description = "Name of application"
  default = "demo"
} 
variable "env" {
  description = "Environment name"
  default = "env"
}
locals {
  full_name = "${var.env}-${var.name}"
}

Lambda Function

The rest of the code, except output, is defined in main.tf. Here we provision the lambda function that runs on Python3.8, using a deployment package in a zip archive. We also define an IAM role that the lambda function can assume. The role provides AWSLambdaBasicExecutionRole and an inline policy that allows the lambda function read and write access to the DynamoDB database.

resource "aws_lambda_function" "myfunc" {
  filename         = data.archive_file.zip.output_path
  source_code_hash = data.archive_file.zip.output_base64sha256
  function_name    = local.full_name
  description      = "Hit counter demo"
  role             = aws_iam_role.iam_for_lambda.arn
  handler          = "func.handler" #filename.handlermethod
  runtime          = "python3.8"
  environment {
    variables = {
      TABLE_NAME = aws_dynamodb_table.hitcount.name
    }
  }
}
resource "aws_iam_role" "iam_for_lambda" {
  name = local.full_name
  assume_role_policy = data.aws_iam_policy_document.allow-lambda-assume.json
  managed_policy_arns = [
    "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
  ]
  inline_policy {
    name   = "ddbreadwrite"
    policy = data.aws_iam_policy_document.ddbreadwrite.json
  }
}
data "archive_file" "zip" {
  type        = "zip"
  source_dir = "${path.module}/lambda/"
  output_path = "${path.module}/packedlambda.zip"
}
data "aws_iam_policy_document" "allow-lambda-assume" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      identifiers = ["lambda.amazonaws.com"]
      type        = "Service"
    }
  }
}

Database

The database is DynamoDB with a single table; an id and hitcount columns. We can store as many website pages as ids and their corresponding hit counts in the hitcount column.

data "aws_iam_policy_document" "ddbreadwrite" {
  statement {
    sid       = "ddbreadwrite"
    effect    = "Allow"
    actions   = ["dynamodb:Scan", "dynamodb:PutItem", "dynamodb:GetItem", "dynamodb:UpdateItem"]
    resources = ["*"]
  }
}
resource "aws_dynamodb_table" "hitcount" {
  name           = local.full_name
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "id"
  attribute {
    name = "id"
    type = "S"
  }
}

The API

A lambda function URL will serve as the https endpoint to our lambda function. This is a quick way to create an API, but usually not suitable for production use.

resource "aws_lambda_function_url" "url1" {
  function_name      = aws_lambda_function.myfunc.function_name
  authorization_type = "NONE"
  cors {
    allow_credentials = true
    allow_origins     = ["*"]
    allow_methods     = ["*"]
    allow_headers     = ["date", "keep-alive"]
    expose_headers    = ["keep-alive", "date"]
    max_age           = 86400
  }
}

Here is the full GitHub code for the project.

Let's run Terraform

To run Terraform we go through the workflow steps:

terraform init
terraform plan
terraform apply

Outputs

Our resources should now be created in the AWS account. We see a terminal output for the new function URL endpoint. Making a get request to this endpoint should return the hit count value.

Changes to Outputs:
  + function_endpoint = "https://4pxyxy0e.execute-api.us-east-2.amazonaws.com/prod/api"

What's next: Embedding the counter API into a webpage

Now that our API is successfully deployed, we can integrate it into a webpage by writing some Javascript in our frontend.

url = "https://4pxyxy0e.execute-api.us-east-2.amazonaws.com/prod/api"
let mcount = ""
fetch(url)
  .then(response => response.text())
  .then((response) => {
      console.log(response)
      mcount = response
      for (let i = 0; i < mcount.length; i++) {
        var newSpan = document.createElement('span');
        newSpan.innerHTML = mcount[i];
        document.getElementById('mydiv').appendChild(newSpan);
      }
  })
  .catch(err => console.log(err))

The code fetches data from our API endpoint via a GET request and then appends each character of the text response to an HTML span on the webpage.

See the full working demo here.

Let me know your thoughts in the comment section.

Fixed mindset: Ability is predetermined

Growth mindset: Learning takes time and effort.

TechStar is the global flagship Accenture program targeting high-performing consultants in Technology for developing leaders. This year, approximately 1% of high-performing analysts and consultants in the Technology business were recognized and nominated for the program. It is not uncommon to find highly technically skilled and accomplished individuals in Tech teams. But how about leadership skills? I accepted my nomination into the program and couldn't wait to explore, network and engage with colleagues, luminaries and Subject Matter Experts. I am happy to share some of the pivotal moments and lessons I learned along the unique 6-month journey.

Nurturing a Growth mindset

I have come to embrace the belief that my abilities and skills can be further developed through dedication, effort and a commitment to continuous improvement. During the journey, I had to complete a challenge focused on cultivating some key mindsets. One of which was the growth mindset.

This mindset has been especially significant in light of the challenges I faced during my initial years of living in the US, particularly in terms of communication. Many did not understand how drastic cultural changes had an impact on one's understanding, listening and speech. I used every piece of feedback I received as a valuable input for growth.

TechStar provided a supportive environment and resources necessary for me to reflect on these past experiences and channel my learnings for personal and professional development.

Managing priorities

One of the recommended books for the journey, that I had the privilege of reading and discussing during BookClub, was “The Phoenix Project.” Bill Palmer's experience in the novel resonated with me. As the new VP, he has to navigate the demands of several departments and make strategic decisions. His team has to balance their work of ongoing maintenance tasks with any urgent production issues that arise.

In my role as a cloud consultant, I often find myself faced with the challenge of managing priorities. Balancing day-to-day tasks while also managing a small team can be challenging. It can be overwhelming at times, especially when the demands from various stakeholders and departments seem to pull in different directions. I have found that having a structured approach and using tools like Jira has helped make tasks more visible and organized.

Additionally, delegating tasks to teammates who may have more bandwidth, and based on individual strengths plays a crucial role in managing priorities!

Sustainability

My passion for nature and commitment to making the Earth a better place have been further reinforced. I learned that different programming languages have different energy efficiency scores, with some being more 'green' than others. This has triggered a shift in how I think about selecting a programming language for a project. I also question the necessity of certain infrastructure choices. I am learning to strike the correct balance between reliability and sustainability. I have become more conscious of avoiding unnecessary resource consumption, thereby contributing to a more sustainable technology landscape.

Final thoughts

In all, the learning sessions covered a wide range of topics, including the art of storytelling, health and well-being, inclusion and diversity, and cutting-edge technology domains like data and AI, cloud, security, sustainability, and enterprise and industry technologies. I am grateful for the recognition, inspiration and mentoring that I gained from participating in this flagship program. I was nominated for a purpose and I plan to use my learnings as guiding principles to shape my career growth. I am excited to embrace the challenges that lie ahead as I step into the next phase of my leadership development journey.

After I completed the 3-hour long exam, to say I was tired is an understatement. I was totally worn out! On top of that, I didn't receive the PASS / FAIL preliminary evaluation that typically appears on the screen at the end of every AWS exam I have taken.

Experience counts

When AWS recommends the exam for candidates with 2+ years of hands-on experience building solutions on their cloud, they aren't kidding. The exam tests your competence over very practical scenarios without a lot of time to think through the options. There is far more depth to the scenarios here than at the associate level.

There are a lot of areas here that are outside the solutions architect-associate level. For example, knowledge of designing a hybrid architecture by integrating AD and other third-party IDPs with AWS Direct Connect or VPN.

In my current role at work, I have been involved in managing hundreds of AWS accounts for a large client. I used AWS Organizations, Control tower, and SCPs for account management tasks, vending and governing accounts at scale. I used IaC and CICD tools for remediating changes across environments and building / replicating environments.

Exam areas

My knowledge from taking the SysOps Administrator and Developer associate exams were useful as several concepts were within the scope of the AWS SA Pro exam.

CloudWatch (Logs, metrics, events etc), SSM, Config, Secrets Manager, Service Catalog

Additional topics, which I totally enjoyed being tested on were migration tools and services:

Data and application migration services such as AWS DataSync, AWS Transfer Family, AWS Snow Family, S3 Transfer Acceleration, AWS Application Discovery Service, AWS Application Migration Service, AWS Server Migration Service

AWS provides an exam guide that lists all services and tools in the scope of this exam: https://d1.awsstatic.com/training-and-certification/docs-sa-pro/AWS-Certified-Solutions-Architect-Professional_Exam-Guide.pdf

Study plan

I used the Acloudguru course which was free through my workplace subscription. Other recommended courses include Adrian Cantril and Stephan Maarek’s courses.

Practice tests

I used Tutorials dojo practice exams and Acloudguru practice exams.

It was important to take my time with the practice exams. I worked through the problems multiple times. I reviewed the correct answers to understand them as well as know why the incorrect answer options are incorrect. Another thing that helped was learning how to quickly eliminate obviously incorrect answer options and deciding on the remaining options; which best answers the question.

White papers

I highly recommend reading the AWS whitepapers. https://aws.amazon.com/whitepapers

Time management

Managing my time for this exam was crucial. There were 75 questions that had to be completed within 180 minutes, so roughly 2 mins per question. The questions, as well as the answer options, can be very wordy. There were several questions along with their answer choices that I had to reread multiple times to understand the finer details. Spending more time than allotted for each question, I ran out of time with 7 questions left to complete.

Exam day

Took my exam online with PearsonVue. I checked in for my exam about 10 minutes earlier than scheduled. There were 12 people waiting in line. I waited an additional 30 mins before my proctor was available.

After the long exam, I took the closing survey and was anxious about my results. To further increase my anxiousness the PASS / FAIL preliminary evaluation did not appear. Only the standard notice that says AWS will evaluate results against compliance and policies and that the process can take up to 5 working days. This was unusual from my experience taking other AWS certifications with PearsonVue. At this point, I thought I failed.

Early the next morning, I received my digital badge from Credly and an email from certmetrics congratulating me on passing my SA Pro exams! I hope my experience will be valuable to you.

Let's walk through how we can quickly set this up with terraform.

First, create the provider and terraform blocks in provider.tf.

touch provider.tf

terraform {
  required_providers {
    aws = {
      version = ">= 4.9.0”
      source = "hashicorp/aws"
    }
  }
}
provider "aws" {
  profile = “your_cli_profile”
  region  = "us-east-1"
}

The most recent release of the terraform-provider-aws (v4.9.0) by Hashicorp has the lambda functions URLs functionality. Make sure to replace profile with your cli profile. If you don’t already have an AWS access profile setup refer to the AWS documentation to set it up.

Creating the Lambda URL resource

Now we will go ahead and create the lambda functions URL resource.

touch main.tf

resource "aws_lambda_function_url" "url1" {
  function_name      = aws_lambda_function.myfunc.function_name
  authorization_type = "NONE"

  cors {
    allow_credentials = true
    allow_origins     = ["*"]
    allow_methods     = ["*"]
    allow_headers     = ["date", "keep-alive"]
    expose_headers    = ["keep-alive", "date"]
    max_age           = 86400
  }
}

Note that the authorization_type = 'NONE' makes your URL publicly accessible. This might be fine for testing. In higher environments, however, this must be avoided. We set our familiar CORS values including allow_methods which can be set to "GET", "POST", "DELETE".

Before we can run this, we need a full lambda function resource, myfunc.

resource "aws_lambda_function" "myfunc" {
  filename         = data.archive_file.zip.output_path
  source_code_hash = data.archive_file.zip.output_base64sha256
  function_name    = "myfunc"
  role             = aws_iam_role.iam_for_lambda.arn
  handler          = "func.handler"
  runtime          = "python3.8"

}

resource "aws_iam_role" "iam_for_lambda" {
  name = "iam_for_lambda"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

data "archive_file" "zip" {
  type        = "zip"
  source_dir = "${path.module}/lambda/"
  output_path = "${path.module}/packedlambda.zip"
}

We will use Python for the handler function.

mkdir lambda && touch lambda/func.py

def handler(event, context):
    body = "hello"
    response = {
        "statusCode": 200,
        "statusDescription": "200 OK",
        "isBase64Encoded": False,
        "headers": {"Content-Type": "text/json; charset=utf-8"},
        "body": body
        }

    return response

Let's run terraform

To run terraform we go through the workflow steps:

terraform init
terraform plan
terraform apply

Now let's go into the console to look at, and try out our new Lambda Function URL.

Final thoughts

Congrats! you just created a Lambda Function URL, a simple API to your serverless lambda function. Lambda Function URLs do not have native APIGateway capabilities such as rate limiting, throttling, IP whitelisting / blacklisting, authorizers. There has been a lot of talk about this in the wider developer community and concerns about how security best practices can be implemented.
On the plus side they:

• have no added cost on top of Lambda

• are quicker to implement than API Gateway

• can be paired with CloudFront to tap some of its inherent benefits such as WAF, Logging, geo targeting - targeting delivery to specific end-users.

Here's the github code for the project.

If this already sounds like you, take a deep breath. Remember, we have all been there; grab a cup of coffee or tea, and let's learn some more about CNAMEs.

What at all is a CNAME?

In simple terms, a CNAME record points a name to another name. It is used, for instance, when you want to point visitors of your domain name app.example.com to another name such as app.something.com. Below you see how I pointed my blog url blog.nquayson.com at hashnode's network url. It is that simple.

Why are CNAME records so common?

The rise in cloud computing is a factor here. A common way to point a domain to a CDN is to add the address as a CNAME. Also, many providers use CNAME records as a way to validate domain ownership.

The common issues:

• CNAME record cannot be at the Apex/root domain level.
• CNAME record cannot be defined with other record types (eg MX, TXT, A) for the same name.
• MX record cannot point to CNAME
• CNAME record CAN point to other CNAME records, however this practice is considered inefficient.

Why not directly point at IPs rather than names?

To ensure high availability, many modern hosting providers and CDNs generally run on distributed system architectures. When host node instances fail, or when there is a better server node available (based on factors such as latency, proximity, health, or cost) providers may have to route traffic to a different node. This will result in a change of destination IP. So your application will break, if you pointed your service directly to an IP.

Some providers will allow creating one CNAME at the domain apex, because of CNAME flattening, but then that can cause other records such as TXT, MX to not work properly. Let's say your domain name is www.example.com We refer to example.com as the 'apex' or 'naked' or 'root'. Some providers such as namecheap use the '@' symbol to represent the apex. The problem with the apex domain is that setting a CNAME record, breaks any other records associated with this name. For instance, you might want to use email service on your domain. However, by setting a CNAME for the apex, you will not be able to use email.

Are there any workarounds?

Yes: CNAME flattening or simply using www. First, you may have heard of the ALIAS record type (not to be confused with the 'A' record which points name to IP address).

The ALIAS record (also referred to as an ANAME) is not traditionally part of the DNS spec. They are virtual record types usually found with cloud DNS providers for their own internal use.

The way it works is, when the authoritative name server receives a request for a record which has an associated ALIAS record, it resolves the ALIAS first. Let's say the ALIAS points to another CNAME. It will then resolve that CNAME down to it's A records. They work pretty like CNAME record type but are a way to solve some of the many problems that are associated with the CNAME record.

What if your DNS provider does not support the ALIAS record

Rather than set the CNAME to your website at the domain apex, you could set it on a subdomain such as www. Keeping www as your main URL or canonical domain frees up the apex, as well as other subdomains to be used for other services such as email.

Let me know in the comments below whether you have faced any CNAME issues in the past, and how you resolved it!

That started somewhere around the 1970s, when the C programming language was being developed at Bell Labs. The very first publication of it was a simple C program that output the string 'hello, world' and a newline character.

main( ) {
        printf("hello, world\n");
}

Today's hello world applications look a little bit different. There's no comma after the hello, and there is usually no need for a new line at the end of world.

def hello():
    print ("hello world")

For me personally, programming has been one of the most fascinating things I've ever learned. I learned programming in qBASIC from an old book I had chanced upon in my high school library. I found it very challenging and different. The sheer power of creativity that came along with it kept me motivated to go on and on; in the process exploring basic data structures and understanding really old algorithms like the bubble sort and insertion sort. I have gone on and on to write at least a dozen hello world applications in different programming languages and platforms. Needless to say it creates a good starting point for writing much more complex solutions. Cheers to learning! Connect with me on Github.

It has been one exciting project in which I have learned to put together several AWS Services and skills that I picked up along my AWS SAA certification journey.

Around the beginning of this month, a good friend introduced me to, AWS Serverless Hero, Forrest Brazeal's cloud resume challenge. It challenges participants to build a resume website using AWS cloud infrastructure; building and configuring services using cloud IaC automation in a CICD Pipeline.

Found it at a time that I had newly passed the AWS Solutions Architect – Associate exam, and it presented a great opportunity to test myself with a practical problem, have fun practicing with it, and showcase my skills.

Prior to this project, I had had some experience with relational database instances running on-prem/server and working on some few small python projects. But I had never fully performed a CICD Pipeline implementation for a lot of the cloud services that were required for this challenge. The more I dived deep, the more my interest heightened. I, perhaps, spent a lot more time reading (because of my curiosity) than actually working on the project.

I accepted the challenge! In a nutshell, the steps that were taken to complete the challenge, in no specific order, involved: creating the frontend and then hosting it in S3, Domain registration and DNS configuration, AWS SAM and CloudFormation for building the serverless backend stack; which was comprised of AWS API Gateway + Lambda (Python) + DynamoDB, then finally, continuous integration and deployment using Github Actions. My codebase was stored on Github and I incorporated Unit Tests into my CICD pipeline. I started straight out taking the bull by the horns, from the backend, using a small dummy html file.

Backend

I built a small Linux (Ubuntu) box at home exclusively for the project. I installed and setup Python, PIP, Boto3, AWS CLI, SAM CLI, Docker, DynamoDB Local. I did this to provide me with the flexibility to try out features locally, before meddling with resources in the cloud. First, I experimented with basic CRUD in DynamoDB Local using Python and Boto3. This was my first real experience with a NoSQL DB. It was fairly easy to pick up. I also experimented with provisioning resources in the cloud from my local linux CLI. I ended up creating multiple AWS SAM templates for my backend infrastructure which, again, comprised of API Gateway, Lambda Function Event, and DynamoDB. Running from the AWS CLI and AWS SAM CLI, I succeeded with deploying my backend resources. Next task was to automate provisioning these same resources in a CICD Pipeline.

SCM, Automation and CICD Pipeline

I did some extensive reading and comparisons around Jenkins, AWS CodePipeline, CircleCI and Github Actions. AWS CodePipeline looked like the easiest for this task, but I wanted to try something new. I settled on GitHub actions, which was released a couple of months ago. My Actions workflow run in a Linux Docker container, mostly executing bash scripts. Environment variables such as access keys were securely set in Github Secrets. For the frontend repository, on each push of my local code to the master branch of my GitHub repository, the actions CICD is triggered, the workflow is executed, and the code base is automatically synced with the hosting S3 bucket. Then the CloudFront CDN cache is invalidated. The workflow for the backend CICD pipeline involved Setting up the job, Checkout, Installing SAM CLI, Unit Testing, SAM Build, Deploy, and Invalidate Cache. SAM template Code is only built and deployed after the Python Lambda function passed the Unit tests.

Frontend

At this point, I was confident I had completed a bulk of the tasks required. I have basic HTML and CSS knowledge and have not built an entire website all by myself. I usually find it comfortable working in the backend. It was challenging to find a website template that I liked exactly. So, I completely stripped apart a minimal html blog template which I had found on HUGO; modified it to look like a resume (I spent lots of hours trying to make it look elegant ++insert smiling face++). I did a simple JS XHR GET request to the API to get the visitor count. This step helped brush up my rusty CSS skills and reminded me to appreciate design work, even more.

DNS, Domain, Hosting, CDN, SSL Certificate

I realize people like to keep things within the AWS ecosystem for simplicity, but it was not too hard to apply my DNS knowledge to hook my CloudFront distribution with an external domain registrar. There were a few downsides with AWS Certificate Manager during DNS validation using the CName record, but I was able to get it fixed by googling. I also had to switch my AWS region to us-east-1 to use ACM according to AWS FAQ.

Final Words

This project presented a refreshing challenge, motivating me to do a lot of reading about Docker and the AWS CLI. I have learnt CICD automation for cloud infrastructure and how to include unit testing into the workflow Pipeline. I learned to integrate a lot of the services, which I had previously not used together. I discovered portals where I can do further reading when I run into problems with AWS services. Big thanks to Forrest Brazeal for allowing me the opportunity to take part in this challenge. Here is the end product. And here are github notes I co-authored after my studies for AWS Solutions Architect – Associate exam.

The Mine Operations

The mine was one of Newmont's operations in the Sub-Saharan region. The pit lies within the Sefwi Volcanic Belt, one of Ghana’s largest volcanic belts; an open-cast surface mine measuring approximately 2100 x 450 x 120 m. Traditionally, land surveyors had used manual total stations to measure distances and bearings from the mine to hundreds of fixed-prism targets installed in the walls of the open pit. At the time of writing there were about 300 prisms installed in the mine pit and more prisms added weekly, to cover all slopes in the pit walls. These readings were taken daily, usually multiple sets, then submitted to the geotechnical engineers to conduct their analyses. Geotechnical engineers will usually receive thousands of x,y,z coordinate pairs or distance-bearing polar readings. This manual way of performing monitoring changed after the new system was implemented.

Overview of the system

The system installed consists of an optical robot (Leica NOVA MS60 MultiStation) - which automatically learns and makes measurements to the carefully distributed targets, DTM meteo sensor and a Netmodule Industrial Router all getting power from a 12V Solar Panel Power supply. Leica GeoMos Monitor and Leica GeoMos Analyser software installed in VMs, for analyses and data aggregation. The GNSS receiver installed at the station receives differential GPS observations to check relative movements at the monitoring base. The Netmodule Industrial Router handles communication and serves as a WLAN client and a conduit for data flow between the MS60, GeoMOS and the Meteo Sensor. Geomos connects to the MS60 via a Wi-Fi network, collects data from the sensors and stores them in a SQL database. For high availability, there is also a secondary radio network that the system automatically fails over to when anything goes wrong with the primary network.

The DTM Meteo Sensor is installed close to the monitoring station to measure atmospheric variations in temperature and pressure. These data are used to correct the measured slope distances by the MS60 sensor.

The Ms60 was chosen over other monitoring sensors because it had the added capability to make reflectorless 3D scans and had made a reputation as the world’s first self-learning MultiStation, automatically and continuously adapting to any environment, despite the challenges. Data from the MS60 sensor is a combination of scans of sections of the mine wall as well as measurements to installed prisms in the mine wall. This data is analyzed and organized by GeoMOS and stored in the database.

With this monitoring system installed, it is possible for geotechnical engineers to perform 24-hour continuous slope stability analyses. The data from the system makes it possible for slope failures to be predicted in advance. What are your thoughts?

UPDATE 2017: A more detailed account of this project appeared in Leica Geosystem's magazine Reporter 76.