• Home
  • blog
  • Hashicorp’s Packer – Is It Something for PHP Developers?

Hashicorp’s Packer – Is It Something for PHP Developers?

Packer logo

tl;dr; – Is Packer a tool you’ll need in your tool box as a PHP developer? It depends.

If you do a lot of server work for your clients or on the job, along with development work, then yes. Packer can help you a lot.

If you are only a developer and don’t really do much work on the server directly, then no. Packer won’t be very helpful.

That being said, it is wise for any PHP developer to learn the basics of creating server environments. You will run into these technologies in your career in one way or another (everything you create runs on them!). This specialized knowledge will help your career in the future for sure! At a minimum, you’ll understand your dev-ops colleagues and the work they do much better.

If your interest has been piqued, or if you do a lot of manual server work, please do read on.

An image of two numbers: 2016 and 2006, and an arrow from the former to the latter

A Look Back in Time

tl;dr; #2 – If you have a command of Vagrant and understand it’s purpose as a tool, please jump to this section of the article.

Only 10 years ago, developing PHP applications basically worked like this: the developer would throw some code up on a web server via FTP and see if it worked. If it didn’t, they would troubleshoot it, edit in a change in some text editor, reload the affected file via FTP again and see if the changes fixed the problem. In that case, they’d go to the next feature or issue, wash, rinse, repeat (and hope nothing they just worked on broke). They might have had some synchronization going with FTP, too.

This was the workflow of the average lone PHP developer pushing stuff to a development server or, heaven help them, directly to a production server (and still is the same process for some developers today, actually). Building the web server itself back then was usually the work of someone else.

Also, in that not-so-distant past, to get teams of developers to work together, there might have been some form of concurrent versioning system and maybe the team even had an auto-deployment set up. When changes were committed to the repository, it would deploy to either a staging or a production system automatically. This scenario was actually the best technology for web application development back then.

In those good old days, things like continuous integration, virtual machines, cloud computing, infrastructure orchestration, data-center automation and even the term “devops” were basically unknown. They were just coming to life. Amazon was just starting their Web Services business. And remember, this was only 10 years ago!

Ahhh, how simple life was back then, right?

Well, no. Back then, development was slower and more tedious, and also more error prone. Servers also always had to be “put up” for testing, which often meant developers had to wait until the “network guys” got a server ready for use with, say, the newest version of PHP. It was often a fight in a lot of cases and for the “network guys”, keeping servers “in shape” was often like fighting fires.

Funny image of fire being put out in IBM office

Computing Today and Virtualization

Today, with the computer technology within everyone’s grasp, developers can carry a much more sophisticated development infrastructure right with them on their own laptop. The computing power of a laptop or PC today is considerably more than what was available just 10 years ago in a web server.

In fact, many of the smart phones we have today are more powerful than the servers of 10 years ago.

Image of server next to an image of an older iPhone

Technology is amazing, isn’t it?

Because of the growing amount of computing power available, more and more people started to realize that this computing power could be split off into separate “machines”. This allowed for totally different things to happen on them at the same time. More importantly, the computing power could be much better utilized, saving resources. These were the main drivers for the virtualization of computing power.

In other words, today, with the ability to make virtual machines, developers can carry their own development environments with them and are no longer restricted by another party of people, who have to “give” them a proper environment to work on. More importantly, they can locally build a complete development environment, which mimics a full web server.

Not only does this make developers much more autonomous, there is another big advantage to this kind of local development environment: it is called “development-production parity” – a concept we discuss at length in the newbie friendly “Jump Start PHP Environment” book. Dev-prod parity basically means that the developer can develop on a system virtually identical to the one the app will end up on when deployed live.

A stock image displaying a rating of adjectives, the top one names "Excellent" being selected with a checkmark

The Production Parity Advantage – it allows the developer to produce higher quality code, because they can do the right things, the right way, the first time.

Today, a developer can have everything they need to develop highly complex applications within a highly complex environment, right in their own backpack.

Continue reading %Hashicorp’s Packer – Is It Something for PHP Developers?%