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

What is GEEK

Buddha Community

Infrastructure as Code vs. Infrastructure as Software
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

Custom Software vs Off-the-shelf Software: How to select a better one for your business?

Custom Software or Off-the-shelf software, the question in mind for many business personnel. Read this blog to get help to make the right decision that will benefit your business.
For a business that wants to upgrade and modernize itself with the help of software, a common dilemma it is whether to go for custom-made software or opt for off-the-shelf software. You can find many top software development companies worldwide, but before that all, you should first decide the type of software –an off-the-shelf software or a custom one.
This blog aims to overcome the dilemma and accord some clarity to a business looking to automate its business processes.

#custom software vs off-the-shelf software #custom software development companies #top software development companies #off-the-shelf software development #customized software solution #custom software development

Tyrique  Littel

Tyrique Littel

1604030400

How to tell if your code actually sucks...

There is no better moment for me than starting a brand new project.

Smells like new project spirit… (Whatever it means)

Starting a new project is funny. Everything seems to be in the right place. But as the projects grow and the deadlines come closer the things begin to boiling.

So, let’s talk about signals that can tell us if our code sucks and we how we can avoid that.

Everyone is afraid of adding or removing stuff

I guess we all have known at least one project that anyone wants to touch, or heard the phrase:

It works, don’t touch it!

Well, that’s not a good signal. I know there are complex projects, big projects, but if nobody in your team can touch it without breaking something, then there is something wrong with that code.

Code is like a garden, it needs to be treat and maintained, if it grows in size or complexity with no control, then will be harder to maintain and easily can get death.

Code grows out of control when there are no conventions to work in it, team practices, even solo practices are important to keep our code under control.

If you see yourself in a scenario where is hard to add things to your project, then you should rethink the whole thing.

Only the creator understands it (Sometimes even the creator can’t.)

If only one person in your team can understand a project, then that’s a problem and hopefully that person never gets sick or goes on vacation.

If you are working by yourself please don’t write overcomplicated code; in my experience simplicity is better; writing code that anyone can read is the right thing to do.

t is clear today may not be that clear in a couple of weeks, even for you.

Use comments on your code. Do not comment on every single line but put enough comments on the complicated and crucial parts.

1

If you develop on javascript this is a great repo with good practices.

It is difficult to read

I have to insist on this. Simple is better; there is no need to show anyone how abstract you can be or how much you know the language. Keeping things simple is way much more productive than trying to show off your knowledge and skill.

Keep your code as readable as possible, simple as possible. Clear variable names, descriptive functions names, clear statements. This will save time for you and your team.

A good way to measure how readable your code is is to overcome the necessity of comments. If the code does not need many comments to describe it, then it means the code is readable enough.

Conclusion

The best code is not only the one that is fast and performant; the best code is also the one you enjoy working on. I’ve had nightmares of codebases that I had to work with, and I also have had codebases that I enjoy.

Coding is a team sport, and every member of the team must be able to play the game, so write for the team.

#development #programming #software-development #coding #coding-skills #software-engineering #code-quality #code

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

Brain  Crist

Brain Crist

1595060940

Why VS Code is so popular?

If you’re reading this post, I bet you know or maybe even use VS Code. This fact alone tells us a lot about the VS Code’s popularity. Millions of developers around the world from many different fields of software use this editor for their daily work. But why’s that?

In this article, I’d like to go over some of the most important reasons behind the VS Code’s popularity. We all know that the general answer is “because it’s good”, but I’d like to go deeper than that. To explore what makes a really good code editor and how it’s done!

Initial overview

For those of you wanting no fluff, here are all the reasons why I think the VS Code is so popular (in no particular order):

  • open-source
  • familiarity
  • simplicity
  • design
  • extendability

Now, some of these reasons might be less or more clear, and even overlap with one another. But even if, we’ll try to dive into each of these reasons individually.

Open-source

The fact that the VS Code is (mostlyopen-source is an unprecedented advantage. Not only does it mean that the software is free to use, but also that you can help to improve it.

Another less obvious advantage of going open-source is increased community engagement. While not all VS Code users contribute to its codebase, they get a certain feeling of unity - bondage that - at least in this field - only open-source can provide.

But being open-source is an advantage far from exclusive to VS Code. Other code editors such as Atom and even whole IDEs like Eclipse or NetBeans are also open-source. So, what’s more behind VS Code’s success?

Familiarity

Now, this might be a little convoluted but bear with me.

I think it’s safe to say that VS Code is most popular among web developers. And it’s not without a reason. The language that most web developers are accustomed to is - of course - JavaScript. And what’s powering VS Code and with what does it integrate best? You guessed it, JavaScript!

On the inside, the VS Code is built using Electron - a framework for creating desktop apps with JavaScript with the help of Chromium and Node.js. Many web developers using VS Code are aware of and appreciate this fact. Not all do, mainly because of Electron apps notorious high memory usage and low performance, but there are still people who appreciate how meta this is - you write JavaScript in a JavaScript app!

On the other hand, VS Code utilizes its impressive TypeScript integration to power autocompletion and other useful editing features for both JS and TS. If you’re using TypeScript, it could be said that VS Code is your best bet.

So, the fact that VS Code is built on top of web technologies and also provides great support for them, makes it feel familiar and pretty much the default choice for a large portion of its growing user-base - web developers.

Simplicity

Without a doubt, one of the biggest advantages of the VS Code is its simplicity. From the first steps to the UI to discovering new functionalities, everything in VS Code feels simple.

With that said, I don’t imply that the VS Code is lacking in any way in terms of features - not at all. Thanks to its extendable architecture (which we’ll talk about in a moment), VS Code - even when being just a code editor - can rival the feature-set of full-blown IDEs! But, unlike those IDEs, it still manages to do it in a compact, user-friendly way.

This simplicity also shows through the VS Code performance, which is surprisingly good - especially for an Electron app. Unless you through multiple extensions at it, VS Code will feel lightweight and snappy - as all things should be.

Design

Now, the design is usually a very subjective thing, but not so much with the VS Code. With minimalistic UI and customizable themes, everyone can find something for themselves.

I consider the UI of the VS Code clean and well-designed, without any clutter whatsoever. The only rival to VS Code in this regard is probably Atom - although it falls short in a few other areas.

As for the customizability, nearly all VS Code users have some kind of their most favorite theme. Even more than that, they can make such a theme themselves, as nearly all UI elements are customizable, and the whole process is as easy as setting values in a JSON file can possibly be.

Extendability

Lastly, the advantage that many VS Code users would consider the most important - extendability. There are literally thousands of extensions in the VS Code marketplace with new ones coming seemingly every single day!

Extensions can serve many different purposes. From extension-like UI themes to programming language support, debugging, Git integration, and even Spotify players! I won’t say that there’s everything, but there’s certainly more than enough. And even if there isn’t, then you can easily make your own with the help of some JavaScript/TypeScript and detailed docs.

But why extensions are so important? It’s because they make the VS Code what it currently is - a very capable piece of software. Without them, VS Code would be not much beyond glorified text editor with good design and basic autocompletion here and there. Extensions are really important to customizing your software to suit your personal needs. It’s you who pick what features you need and when do you need them.

#vs code #software #watercooler #visual studio code #coding