It’s no secret that Cloud Application Manager performs deployments on your remote virtual machines using an agent. But what goes on behind the scenes? What makes the agent tick? Join me for a deep dive.
Though not visibly apparent, when you trigger deployments from the web or API, the agent is the software we install on every virtual machine you deploy from Cloud Application Manager. Its sole purpose is to handle box deployments on the VM or service. It executes event scripts and runs lifecycle operations from the web or API calls. By itself the agent does not contain any other logic. It executes whatever Cloud Application Manager tells it to do and sends back the logs of the output.
We built the agent based on three important principles of software architecture:
- To be platform interoperable, that is, work on any OS or platform.
- To be network interoperable, that is, communicate over any network configuration easily.
- To cover a small footprint, that is, consume the least amount of machine resources.
Platform interoperability is pretty important. The agent works across all platforms on any OS and runtime libraries. It works cross-platform because it’s written in Python, and doesn’t require any dependencies.
In recent times, we made vast changes to the agent.
Before, the agent used the AMQP (Advanced Message Queuing Protocol) to communicate with Cloud Application Manager. The agent subscribed and listened to messages in the queue. When the messages came from Cloud Application Manager, they first got in the queue. Then the agent as a subscriber got the message, executed it and sent the results back to Cloud Application Manager in another queue that again followed the same publish and subscribe pattern to relay the message.
Now, the agent communicates directly and faster. Cloud Application Manager uses an HTTP WebSocket interface over the API to install and talk to the agent. Since the WebSocket protocol communicates bidirectionally, messages route faster in a less complex fashion.
Benefits of the Improved Agent
I’ll go over how these changes benefit deployments. First, networks can readily talk to Cloud Application Manager whether in the public or private datacenter cloud. AMQP as a lower level network protocol requires different ports to communicate. Earlier, you needed to open a firewall, which can pose constraints. Whereas now, the agent communicates securely over HTTP WebSockets port 443, which most networks are already configured to communicate with the Internet. If you have an HTTP proxy set up for Internet traffic, then your VMs talk to Cloud Application Manager by default with no additional networking required.
Second, you get a uniform bootstrapping on any platform, any cloud provider. Bootstrapping helps prepare the machine for Cloud Application Manager use. We installed the agent before differently on vSphere versus Amazon or MyServer. Now across every provider or infrastructure, you follow the same method, which is to run this single cURL command.
The command allows you to recover a previously offline agent. If the agent gets stuck for whatever reason, you can reinstall with that command and the agent will continue the deployment from where it stopped.
Third, you get better logging. Now that Cloud Application Manager communicates directly over the API, we get a detailed record of all the logs in real-time. With real-time logs, the activity on an instance is pretty much information as it happens.
In short, we connect to the agent directly. What architecture changes does that mean for the future? One valuable result of this change is to be able to report the exact status of the instance and the agent anytime. For the most part, these changes are transparent to you, and that’s a good thing. As you continue to deploy with Cloud Application Manager, you you can look forward to faster and more fail-proof deployments 100% of the time.
Want to Learn More About Cloud Application Manager and ElasticKube?
Cloud Application Manager is a powerful, scalable platform for deploying applications into production across any cloud infrastructure – private, public or hosted. It provides interactive visualization to automate application provisioning, including configuration, deployment, scaling, updating and migration of applications in real-time. Offering two approaches to cloud orchestration — Cloud Application Manager and ElasticKube — enterprise IT and developers alike can benefit from multi-cloud flexibility.
Explore ElasticKube by visiting GitHub (curl -s https://elastickube.com | bash).
Visit the Cloud Application Manager product page to learn more.