Zachariah  Wiza

Zachariah Wiza

1625285880

Terraform vs. Pulumi vs. Crossplane - Infrastructure as Code (IaC) Tools Compared

We are comparing Terraform, Pulumi, Crossplane. Those are the most popular and the most exciting Infrastructure as Code (IaC) tools we have on the market today. Which one should you use? What are the pros and cons of each? What are the use cases that make one a better choice over the others?

#terraform #pulumi #crossplane #iac

Timecodes ⏱:
00:00 Intro
03:20 Criteria
04:50 Requirements
06:56 Syntax
14:40 Plan and preview
16:10 Create, update, and destroy
20:58 CI/CD
21:32 Drift detection and sync
27:08 GitOps
29:38 Support
32:59 Final thoughts

➡ Gist with the commands: https://gist.github.com/b992aeb8bbee2df1823c45475ceb4373

🔗 Terraform: https://www.terraform.io/

🔗 Pulumi: https://www.pulumi.com/

🔗 Crossplane: https://crossplane.io/

📚 DevOps Catalog, Patterns, And Blueprints: https://www.devopstoolkitseries.com/posts/catalog/

📚 Books and courses: https://www.devopstoolkitseries.com

🎤 Podcast: https://www.devopsparadox.com/

💬 Live streams: https://www.youtube.com/c/DevOpsParadox

➡ Follow me on Twitter: https://twitter.com/vfarcic

➡ Follow me on LinkedIn: https://www.linkedin.com/in/viktorfarcic/

#terraform #pulumi #crossplane

What is GEEK

Buddha Community

Terraform vs. Pulumi vs. Crossplane - Infrastructure as Code (IaC) Tools Compared
Zachariah  Wiza

Zachariah Wiza

1625285880

Terraform vs. Pulumi vs. Crossplane - Infrastructure as Code (IaC) Tools Compared

We are comparing Terraform, Pulumi, Crossplane. Those are the most popular and the most exciting Infrastructure as Code (IaC) tools we have on the market today. Which one should you use? What are the pros and cons of each? What are the use cases that make one a better choice over the others?

#terraform #pulumi #crossplane #iac

Timecodes ⏱:
00:00 Intro
03:20 Criteria
04:50 Requirements
06:56 Syntax
14:40 Plan and preview
16:10 Create, update, and destroy
20:58 CI/CD
21:32 Drift detection and sync
27:08 GitOps
29:38 Support
32:59 Final thoughts

➡ Gist with the commands: https://gist.github.com/b992aeb8bbee2df1823c45475ceb4373

🔗 Terraform: https://www.terraform.io/

🔗 Pulumi: https://www.pulumi.com/

🔗 Crossplane: https://crossplane.io/

📚 DevOps Catalog, Patterns, And Blueprints: https://www.devopstoolkitseries.com/posts/catalog/

📚 Books and courses: https://www.devopstoolkitseries.com

🎤 Podcast: https://www.devopsparadox.com/

💬 Live streams: https://www.youtube.com/c/DevOpsParadox

➡ Follow me on Twitter: https://twitter.com/vfarcic

➡ Follow me on LinkedIn: https://www.linkedin.com/in/viktorfarcic/

#terraform #pulumi #crossplane

Wiley  Mayer

Wiley Mayer

1603976400

Infrastructure as Code vs. Infrastructure as Software

Infrastructure as Code has been the hottest trend in cloud-native application development in recent years. By transforming infrastructure management into simple coded runtimes and routines, Infrastructure as Code or IaC allows developers to be more involved in the deployment part of their CI/CD pipelines. Even the most complex cloud infrastructure can be created with several lines of code.

IaC also means that server management, resource provisioning, and even long-term maintenance of complex cloud infrastructures are entirely simplified. Tools like Terraform certainly make maintaining a production environment that is both capable and efficient easy, even when there is no dedicated infrastructure team to handle the associated tasks.

A new trend that we’re seeing right now is further simplification of IaC, mainly known as Infrastructure as Software or IaS. Now that cloud services and the providers behind them are easier to access and control using tools and software, it is not impossible for the entire cloud infrastructure to be provisioned and managed as software libraries.

How does Infrastructure as Code differ from Infrastructure as Software? Which approach is better? We are going to answer these questions, and several others about these two trends, in this article.

IaC and IaS

The two approaches have some stark differences, but we are going to take a closer look at each of them first before we start differentiating the two. Infrastructure as Code is obviously the older approach of the two, and it has been very popular among developers. Using tools designed for managing infrastructure through lines of code, you can either manage the configurations of your cloud infrastructure or manage the provisioning of cloud resources; or both.

Terraform, a popular tool used by millions of developers, applies the second approach. The tool is not just handy for managing multiple configurations and making sure that key infrastructure variables are coded properly; it is also capable of provisioning resources and automating server deployment as needed. Terraform is very extensive in this respect.

Upon close inspection, Infrastructure as Software performs similar⁠—if not the same⁠—tasks using similar tools. You can deploy new server instances or configure the entire architecture using a few lines of codes. You can also automate provisioning and management, and you can still integrate IaS with your existing CI/CD pipelines.

Services that are available today support both approaches in most cases. The tools that fall into these two categories basically use the same API calls and available cloud resources to perform their runtimes, but they take different approaches when it comes to management. That actually brings us to our next point.

IaC vs. IaS

Now that we know how the two approaches are relatively similar, it is time to get the obvious out of the way. Infrastructure as Code and Infrastructure as Software has one huge difference, and that difference lies in the programming languages used by the tools. The easiest way to understand this difference is by comparing Terraform with Pulumi, which is a popular IaS tool.

Terraform requires you to use its native programming language. The HCL language is used for low-level programming. While the language is also used by other tools, the way it is used by Terraform is not always as straightforward as it seems. Terraform also supports JSON syntax but parsing and generating can quickly become bottlenecks as you try to organize massive cloud infrastructure environments.

Pulumi, on the other hand, uses programming languages you are already familiar with. It actually supports many of them, including Python, Go, and JavaScript. Don’t forget that loops and the programming structure of these familiar languages are carried over, so you define your cloud infrastructure the way you code functions in your cloud-native apps.

Since the programming language being used carries its own best practices and things like package management, you can implement the same set of elements into your IaS routine. No need to worry about having difficulties pushing infrastructure modules or doing plenty of adjustments in order for the configuration to be deployed at all.

#blog #code #continuous delivery #continuous integration #ci/cd pipeline #infrastructure as code #infrastructure as software #pulumi #terraform

Tyrique  Littel

Tyrique Littel

1604008800

Static Code Analysis: What It Is? How to Use It?

Static code analysis refers to the technique of approximating the runtime behavior of a program. In other words, it is the process of predicting the output of a program without actually executing it.

Lately, however, the term “Static Code Analysis” is more commonly used to refer to one of the applications of this technique rather than the technique itself — program comprehension — understanding the program and detecting issues in it (anything from syntax errors to type mismatches, performance hogs likely bugs, security loopholes, etc.). This is the usage we’d be referring to throughout this post.

“The refinement of techniques for the prompt discovery of error serves as well as any other as a hallmark of what we mean by science.”

  • J. Robert Oppenheimer

Outline

We cover a lot of ground in this post. The aim is to build an understanding of static code analysis and to equip you with the basic theory, and the right tools so that you can write analyzers on your own.

We start our journey with laying down the essential parts of the pipeline which a compiler follows to understand what a piece of code does. We learn where to tap points in this pipeline to plug in our analyzers and extract meaningful information. In the latter half, we get our feet wet, and write four such static analyzers, completely from scratch, in Python.

Note that although the ideas here are discussed in light of Python, static code analyzers across all programming languages are carved out along similar lines. We chose Python because of the availability of an easy to use ast module, and wide adoption of the language itself.

How does it all work?

Before a computer can finally “understand” and execute a piece of code, it goes through a series of complicated transformations:

static analysis workflow

As you can see in the diagram (go ahead, zoom it!), the static analyzers feed on the output of these stages. To be able to better understand the static analysis techniques, let’s look at each of these steps in some more detail:

Scanning

The first thing that a compiler does when trying to understand a piece of code is to break it down into smaller chunks, also known as tokens. Tokens are akin to what words are in a language.

A token might consist of either a single character, like (, or literals (like integers, strings, e.g., 7Bob, etc.), or reserved keywords of that language (e.g, def in Python). Characters which do not contribute towards the semantics of a program, like trailing whitespace, comments, etc. are often discarded by the scanner.

Python provides the tokenize module in its standard library to let you play around with tokens:

Python

1

import io

2

import tokenize

3

4

code = b"color = input('Enter your favourite color: ')"

5

6

for token in tokenize.tokenize(io.BytesIO(code).readline):

7

    print(token)

Python

1

TokenInfo(type=62 (ENCODING),  string='utf-8')

2

TokenInfo(type=1  (NAME),      string='color')

3

TokenInfo(type=54 (OP),        string='=')

4

TokenInfo(type=1  (NAME),      string='input')

5

TokenInfo(type=54 (OP),        string='(')

6

TokenInfo(type=3  (STRING),    string="'Enter your favourite color: '")

7

TokenInfo(type=54 (OP),        string=')')

8

TokenInfo(type=4  (NEWLINE),   string='')

9

TokenInfo(type=0  (ENDMARKER), string='')

(Note that for the sake of readability, I’ve omitted a few columns from the result above — metadata like starting index, ending index, a copy of the line on which a token occurs, etc.)

#code quality #code review #static analysis #static code analysis #code analysis #static analysis tools #code review tips #static code analyzer #static code analysis tool #static analyzer

Kole  Haag

Kole Haag

1604019600

Terraform Tips: My Favorite Tools

TFSwitch

This is an amazing tool from Warrensbox which you can find on Warren’s website here or on the github repo here.

Tfswitch allows you to switch between different versions of Terraform on the fly. In addition to switching between Terraform versions tfswitch will download any version of Terraform you do not have installed if the version is selected.

Here are a couple of gifs from Warren’s github README that demonstrate how it is used.

Image for post

To check out the tool and find more information on usage go check out the repo! Or just install it using this command:

brew install warrensbox/tap/tfswitch

Terraform-docs

Terraform-docs is an excellent tool for quickly creating a README.md for your terraform modules. You can find the github repository here.

All you have to do is change directory to your Terraform configuration files and run this command:

terraform-docs markdown ./

Then copy the output that will look something like this:

### Requirements

No requirements.
### Providers
| Name | Version |
|------|---------|
| aws | n/a |
### Inputs
| Name | Description | Type | Default | Required |
|------|-------------|------|---------|:--------:|
| availability\_zone | Variable for AZ | `string` | `"us-east-1a"` | no |
### Outputs
No output.

Paste this output into a README.md file for your module. Then you will have a beautiful markdown file in github that looks like this:

On to the next tool!

Visual Studio Code Extensions

For a multitude of reasons I switched from using Sublime Text to using Visual Studio Code. That is a topic for another article, but just know I found VS Code to be FAR superior.

Here are some of the extensions I found to be helpful for writing Terraform code.

Bracket Pair Colorizer 2

Image for post

Bracket pair colorizer highlights your brackets and helps you to make sure your syntax is correct. Missing a bracket? It will help point that out as well! Here is what it looks like:

Image for post

HashiCorp Terraform

Image for post

This probably goes without saying, but I use HashiCorp Terraform to highlight the terraform syntax and verify that my code looks correct. Here is some code that looks good:

Image for post

Here is some that looks bad:

Image for post

It won’t solve your syntax problems for you, of course. Definitely helps find them though!

#hashicorp-terraform #coding #devops #terraform #infrastructure-as-code

Samanta  Moore

Samanta Moore

1621137960

Guidelines for Java Code Reviews

Get a jump-start on your next code review session with this list.

Having another pair of eyes scan your code is always useful and helps you spot mistakes before you break production. You need not be an expert to review someone’s code. Some experience with the programming language and a review checklist should help you get started. We’ve put together a list of things you should keep in mind when you’re reviewing Java code. Read on!

1. Follow Java Code Conventions

2. Replace Imperative Code With Lambdas and Streams

3. Beware of the NullPointerException

4. Directly Assigning References From Client Code to a Field

5. Handle Exceptions With Care

#java #code quality #java tutorial #code analysis #code reviews #code review tips #code analysis tools #java tutorial for beginners #java code review