June 28, 2021

Orchestrate Applications With ZendPHP

AWS

By

What is orchestration and does your PHP application need it? In this latest blog article, we take a look at orchestration as it relates to PHP applications in the cloud, in Docker, and using ZendPHP.

What Is Orchestration?

Simply put, orchestration is the process of describing the various resources that make up a computing system.

Generally speaking, orchestration systems:

  • Describe complete systems. This means that everything required for the system to run is present. As an example, for a PHP application that uses Redis for session clustering, MariaDB for data persistence, RabbitMQ for handling asynchronous message processing, PHP nodes to process RabbitMQ messages, PHP nodes to handle HTTP traffic, and a load balancer to route traffic, orchestration would define and coordinate all of these services.
  • Favor automation. Everything described during orchestration should be repeatable and result in the same state when complete.
  • Can be versioned. This can be done either in the descriptions themselves (providing a version identifier), and/or using a version control system. As such, orchestration tends to favor configuration, and push any binaries or scripts needed to automate the system into the resources they describe. If a bug is uncovered after deploying, DevOps should be able to roll back to the previous version.

Do PHP Applications Need Orchestration?

Well, if the example detailing that orchestration describes complete systems looks familiar to you, even if you don't use every portion of it, then the answer is yes! In fact, the following basic scenario is not uncommon:

  • A load balancer, handling SSL negotiation, and reverse proxying to:
    • Two or more PHP nodes.

Orchestration can help simplify deployment and management of a basic example like that, all the way up to applications with dozens or hundreds of microservices all coordinating with each other. How you handle that orchestration, however, will depend on where you plan to deploy and how.

Orchestration in the Cloud

Over the past fifteen years, we, as PHP developers, have become fairly familiar with enterprise cloud providers, from the venerable Amazon Web Services (AWS), to Microsoft Azure, Google Cloud Platform, and more.

Most of these offer "compute cloud" or "cloud machine" services, which allow launching virtual machine images on their service. Over time, each has provided a marketplace to allow vendors to create ready-to-use machine images that customers can launch and customize to run their own applications.

On AWS, this is the Elastic Compute Cloud (EC2); on Azure, it's their Virtual Machines product; Google has its Compute Engine.

As these evolved, DevOps developed tools like Chef, Puppet, and Ansible to manage their computational clusters. These tools are primarily interested in how to provision an individual machine, but can be coerced into managing clusters.

A newcomer has since become a standard for cloud orchestration in the DevOps ecosystem: Terraform. From its own documentation, "Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently." It is provider agnostic, and has plugins available for provisioning systems like Chef, Puppet, and Ansible; as such, you can continue using what you know, but use Terraform to coordinate between all the resources.

Orchestration With Containers

When virtual machines were first commoditized, they were an answer to both production and development needs, as developers could literally develop in the same environment as production. Over time, however, many of us noted that (a) they consumed a LOT of disk storage, particularly if you were using a bunch of them, and (b) the bigger the image, the slower to start.

Linux containers have been around for a long time, but were an arcane solution that was difficult to understand and utilize. In the past five to ten years, Docker arose to make them easier to understand, and, more importantly, build and consume. Docker images, particularly once cached locally, are lightning fast to start, and, because they often can share layers (snapshots of state), tend to use less storage as well. Since they are idempotent in nature, the goal is one service per image, which means you generally need to orchestrate many containers to create a full application or system.

Docker has many different orchestration systems:

  • Compose, which runs on a single physical machine.
  • Stack/Swarm, which orchestrates across multiple machines, but generally requires manual intervention to start and stop the system.
  • Kubernetes (k8s), which can describe entire systems, and include features such as monitoring, logging, and autoscaling.
  • Helm, which is an abstraction layer over k8s.

The beauty of Docker is in its orchestration capabilities, and it is a fantastic platform both for development (as it provides the same environment as production) and large production applications. The various orchestration tools provide the tools you need to describe, automate, and version your applications.

Orchestration With ZendPHP

So, where is all this leading?

Some time ago, ZendPHP, an enterprise, supported, secure PHP for mission-critical applications, launched. This month, new capabilities for ZendPHP are launching, including:

Additionally, there is documented session clustering with ZendPHP using:

The goal is to make PHP orchestration simple, secure, and flexible, allowing it to grow with your application.

Try ZendPHP Free

Even better? You can try each now, for free, on PHP versions currently receiving support by php.net. Sign up for more details and to start a free trial.

Start TRIAL

 

 

Additional Resources

Matthew Weier O'Phinney Headshot

Matthew Weier O’Phinney

Zend Product Manager, Zend by Perforce

Matthew began developing on Zend Framework (ZF) before its first public release, and led the project for Zend from 2009 through 2019. He is a founding member of the PHP Framework Interop Group (PHP-FIG), which creates and promotes standards for the PHP ecosystem — and is serving his second elected term on the PHP-FIG Core Committee.