Terraform Remote State and Locking (Terraform Module)

As part of our migration to cloud, our team has been learning about DevOps tools and best practices.

We have picked Terraform as the tool to manage our Amazon AWS infrastructure, with a Collaborative IaC (Infrastructure as Code) workflow, which is well explained in the following page:

A good practice is to leverage Terraform Remote State and Locking capabilities when working with large teams, this to improve efficiency and reduce the margin for errors and issues.

Terraform Remote State allows a team to store “state files” in a centralized remote location like Amazon S3. More about Terraform Remote State can be read here:

Additionally, Terraform Locking helps avoid situations where two team members attempt to deploy an infrastructure change at the same time, which could lead to conflicts and state corruption:

The following is a Terraform “template” module to create the required Amazon S3 bucket and DynamoDB table for this:

terraform {
  required_version = ">= 0.11.3"

# S3 Bucket
resource "aws_s3_bucket" "this" {
  acl    = "private"
  bucket = "${var.bucket}"
  region = "${var.region}"

  versioning {
    enabled = true

# DynamoDB Locking Table
resource "aws_dynamodb_table" "this" {
  count = "${var.dynamodb_table != "" ? 1 : 0}"

  name            = "${var.dynamodb_table}"
  read_capacity   = 3
  write_capacity  = 3
  hash_key        = "LockID"

  attribute {
    name = "LockID"
    type = "S"

  tags {
    "Terraform" = true

Following Terraform good practices, you could then create a new “live” module by extending the “template” module in the following way:

provider "aws" {
  region = "us-east-1"

module "s3statebucket" {
  source         = "[ path_to_your_template_module ]"
  region         = "us-east-1"

  bucket         = "[ your_s3_bucket_name ]"
  dynamodb_table = "[ your_dynamodb_table_name ]"

Please note DynamoDB locking is optional in the script, simply omit “dynamodb_table” if all you need is the S3 Bucket.

What is DevOps?

All Hands On … Cloud!

After some time of discussing pros, cons, immediate and future benefits of moving to cloud, our team received the green light to start moving towards Amazon AWS a few weeks back.

Our interest in cloud is not one but many, one of them is the agility our team can gain, from this perspective, moving is just not a matter of “migrating” but more of “migrating the right way”.

We realized as a team “migrating the right way” is changing our mindset, more than likely overhaul our development workflow, and leverage the new tools to be more ‘Agile’.

“DevOps” is this interesting buzz word that has been floating around for some time, as everything, it now took center stage for our team as we jumped into the cloud realm.

I recently assisted a PHP meetup in London, and chit-chatting with a guy, I tried to sound cool by saying:

Right, we are moving to cloud, and I think we will need some DevOps specialists to help.

I didn’t know, but the guy was a technology recruiter and immediately replied:

I have been trying to wrap my head around this DevOps concept, could you explain to me what traits or skill-set makes up a DevOps Engineer, or what does a “DevOps” role comprises?

The question caught me off guard and made me realize I didn’t have a clear answer!¬†So guess what? I decided to be more prepared next time around ūüôā

Defining DevOps (Let’s Try)

The more I read about DevOps, the more I realized it can be difficult to define, there are many opinions and angles as there are different teams and products around the globe.

The following is a summary of the most valuable pieces of information I collected from some of the sources:

DevOps¬†(a¬†clipped compound¬†of “development” and “operations”) is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops).
– Wikipedia –¬†https://en.wikipedia.org/wiki/DevOps

Thank you Wikipedia!, understanding the origin of the term is a good start.

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.
– Amazon AWS –¬†https://aws.amazon.com/devops/what-is-devops/

Amazon AWS basically says is the combination of cultural philosophies, practices, and tools; sounds like a lot!

DevOps is a set of practices that automates the processes between software development and IT teams, in order that they can build, test, and release software faster and more reliably. The concept of DevOps is founded on building a culture of collaboration between teams that historically functioned in relative siloes. The promised benefits include increased trust, faster software releases, ability to solve critical issues quickly, and better manage unplanned work.
– Atlassian –¬†https://www.atlassian.com/devops

Ok, Atlassian talks about a set of practices to automate processes between development and IT teams, and a culture of collaboration, starting to see a pattern here ūüėČ

DevOps is a new term emerging from the collision of two major related trends. The first was also¬†called ‚Äúagile infrastructure‚ÄĚ or ‚Äúagile operations‚ÄĚ; it sprang from applying Agile and Lean approaches to operations work.¬† The second is a much expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a¬†service, and how important operations has become in our increasingly service-oriented world.
– TheAgileAdmin –¬†https://theagileadmin.com/what-is-devops/

We are starting to get deep here, TheAgileAdmin Website talks about a collision of two trends, “agile infrastructure” (applying an agile approach to operations work) and an “understanding of the value of collaboration between development and operations staff throughout all stages of the development cycle”; sounds team culture to me!

A couple of more definitions found in the same article:

  • A cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at¬†scale.
  • DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process¬†to¬†production support.
  • DevOps is also characterized by operations staff making use¬†many of the same techniques as developers for their systems work.

DevOps Goals

Enough of definitions!, what does DevOps try to accomplish? let’s see …

The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.
– Wikipedia – https://en.wikipedia.org/wiki/DevOps

Efficiency and close alignment with business objectives. Got it!; how about Amazon AWS?

Evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.
– Amazon AWS –¬†https://aws.amazon.com/devops/what-is-devops/

To allow an organization to compete effectively in the market. I would say it as: speed with purpose.

It’s a firm handshake between development and operations that emphasizes a¬†shift in mindset, better collaboration, and tighter¬†integration. It¬†unites¬†agile,¬†continuous delivery, automation, and much more, to help development and¬†operations teams¬†be¬†more efficient, innovate faster, and deliver higher value to businesses and customers.
– Atlassian –¬†https://www.atlassian.com/devops

Atlassian says, to be more efficient and deliver higher value to business and customers.

The primary goal of any DevOps setup within an organisation is to improve the delivery of value for customers and the business, not in itself to reduce costs, increase automation, or drive everything from configuration management. At its essence, DevOps is a culture, a movement, a philosophy.
– DevOpsTopologies – http://web.devopstopologies.com/

And the prize goes to! … DevOpsTopologies describes the goal very clearly: is not about reducing costs, automation or any other inherited benefit, but about improving the delivery of value for customers and the business.

The previous point triggered a though related to Scrum and Sub-teams; I remember asking my trainer at a recent Scrum course I attended:

We have different specialties in our development team, for example Development, QA, etc. what does Scrum mean by not recognizing Sub-teams?

My trainer explained it like:

Specialists are OK, what Scrum suggests to be very careful with, is the concept of “Sub-teams” where members tend to only do what pertains to their specialty, and forget about the main goal.

The idea is to avoid situations where a QA would say: “we tested the code, it passes, it is your problem now”; or Development saying: “we finished our code and it works locally, it is QA’s/IT’s problem now”.

Scrum advocates for having a transparent and collaborative mindset, where everyone, disregarding specialties or areas of focus, have a single goal in mind: deliver high quality software for customers and the business.

In this type of mindset, team members are encouraged to be flexible and proactive. e.g. I am a Developer and QA is having an automation issue? How can I help?

Putting Everything Together

Being such a broad concept with many angles, I think the most important is:

  • What does it mean to you and your team?, and also,
  • Make sure everyone in the team understands the common goals and shares the mindset.

For our team, I think we can start with:

At its essence, DevOps is a culture, a movement, a philosophy.

DevOps is a shared team mindset; a combination of culture, practices and tools to improve the delivery of value for customers and the business.

DevOps advocates automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management.

The primary goal of any DevOps setup within the organization is to improve the delivery of value for customers and the business, not in itself to reduce costs, increase automation, or drive everything from configuration management.    

In practice, I think the concepts could be concretized for our team as a “DevOps & Integration”¬†group, that shares the mindset described above.

The “DevOps & Integration” group would be encouraged to look for opportunities to help and coach “Product Teams”, to increase the quality and speed of delivery of what they produce.

(“DevOps & Automation” was also considered; but “Integration” has a collaboration connotation to it, vs. “Automation” that not necessarily).


Time Allocation for Effective Leadership

The Discovery

Being a technology guy, time management and allocation is one of the things I have struggled the most over the years.

Coordinating multiple projects and initiatives can be quite challenging, even more when you add to it day-to-day operations and unexpected events.

As our development team grows, it becomes more evident I need to get better at this.

Sharing frustrations with my wife the other night, she gave me some advise on how to allocate my time, and knowing she knows well what she is talking about, I decided to put my headphones down and listen carefully.

My wife was the star Executive Assistant of a very busy executive, she has also extensive experience working in Consulting, Project Management and more recently with Financial Services remote teams (Yeees, I love my wife, but facts are facts :)).

I will try to explain her advise in my own words (sorry babe!)

The Advise

The advise revolves around Strategic, Tactical and Operational planning, which can be adapted to time allocation.

In order to keep an eye on the ball, there are four types of tasks we should identify, and appropriately allocate our time to each:

  1. Strategic (or “the roadmap / long-term planning horizon”) [Planned]

    Schedule your planning time, do you need to work on the next iteration of the system architecture?

    Do you need to pick a vendor for an important part of the business, and don’t know what’s out there? schedule some research time and stick to it!

    This is the type of task that normally goes out the window when things get tough, but is critical, think about it, where will we be tomorrow with no clear direction? prob. doing more bug fixes :/

  2. Tactical (or “medium-term”) [Planned]

    Planned projects need to keep moving forward, so schedule regular touch-point calls with your team to discuss progress and potential blockers.

    If we don’t follow-up, projects can deviate from the original goal or intent, and initiatives and good intentions can die, so … follow-up!

  3. Operational (or “day-to-day”) [Planned]

    Daily Scrum?, depending on the level of involvement you have on projects and initiatives, this is the most granular level of follow-up for planned work.
    As a team grows or you acquire new responsibilities, it becomes increasingly difficult to follow up on this level, so the advise is to start delegating it in the measure possible.

  4. Contingency (or “Ad-hoc”) [Unplanned]

    Leave free time for the unexpected.

    Keep in mind things can (and will) break, so don’t overbook yourself.

    Keep X percent of your time free, so you can jump on those not fun, but critical train-wrecks.

Personally, I think this is a basic but powerful framework for time management and allocation, so I will be taking it for a spin, best of luck in your own journey!