Last month, platform-as-a-service (PaaS) provider Engine Yard released a “cloud in a box” that developers can use to test their applications locally before publishing to the public cloud. Multiple cloud providers have now embraced this deployment model as a way to accelerate development while making it easier to try a particular cloud before committing to it.
Engine Yard Local is available as a single virtual machine that includes the core components and interfaces that are present in the Engine Yard public cloud. According to Engine Yard, it mimics “the same operating system, system structure, provisioning system and software package tree used by Engine Yard Cloud and Engine Yard Managed instances.” In a blog post announcing the release of this product, Engine Yard described the value proposition.
Engine Yard Local serves as a nifty way to save you from going through the process of signing up for an account, configuring everything, deploying your application, and paying for your instances – only to find out that something is not working. With Engine Yard Local, you can continuously test your application, as if you’re actually on the cloud, except this is a free simulation with no limits.
Engine Yard Local is made possible by Vagrant, an open-source tool for creating and distributing development environments within virtual machines. As long as developers have Ruby and Oracle Virtual Box installed, they can run Engine Yard Local and target it from their development environment. A related product – not yet released – called Engine Yard Live makes it possible for developers to share access to their Engine Yard Local instance through the public internet.
Numerous PaaS providers now offer this sort of development fabric that helps developers try out their software before publishing it to the cloud. Microsoft’s Windows Azure SDK installs a compute and storage emulator that developers can use to simulate the Microsoft cloud on their local machine. However, unlike Engine Yard Local, there are numerous differences between the permissions and behavior of the emulator versus the public Windows Azure cloud. VMware’s Cloud Foundry PaaS has a model very similar to Engine Yard Local. Micro Cloud Foundry ships as a fully-contained virtual machine that closely mimics the services, behavior, and interfaces of any Cloud Foundry-compliant PaaS provider.
To try out Engine Yard Local, review their Knowledge Base article that describes all of the steps for installing and testing the product. Questions about the product can be asked in their Q&A forum. InfoQ wanted to learn more about this release, so we reached out to Engine Yard with a few questions.
InfoQ: What operating systems, platforms frameworks do you support, and how did you arrive at those choices?
Engine Yard: Engine Yard continually evaluates popular technologies and listens to customer feedback on what’s important for them to meet their business and development needs.
Engine Yard Local 1.0 currently supports the Engine Yard default stack, which consists of the Gentoo operating system, Ruby 1.9.3, Nginx, Passenger 3 and PostgreSQL. Future releases of Engine Yard Local will not only provide additional component choices but also updated versions. Engine Yard Local runs on Windows, OSX and Linux.
Engine Yard PaaS supports a variety of operating systems, languages, middleware and databases. The complete listing of our technology stack can be found here:https://support.cloud.engineyard.com/entries/21009842-engine-yard-technology-stack
InfoQ: What do you see as the common workflow (e.g. create, commit, build, deploy, etc) with users that take advantage of Engine Yard Local?
Engine Yard: Engine Yard Local enables developers to have an Engine Yard Cloud environment on their local machine. Developers can develop and test their Rails applications in the Engine Yard Local virtual machine and when they’re ready to deploy, they can commit their changes and deploy to Engine Yard Cloud. A common workflow would be develop, test, commit, deploy.
Once a developer has installed Engine Yard Local, you can use it from the directory of any Rails application. For example, we can create a new Rails app and then move into this application to start:
$ rails new myapp
$ cd myapp
$ ey-local up
This will start a virtual machine that is running the Engine Yard stack and start your application. You can go to http://127.0.0.1:8080/ to see the application running on your local machine. You can interact with your application and make sure it meets your requirements.
If the changes meet your requirements, you can now commit your changes to your Git repo and push to GitHub (or other repositories):
$ git add -A && git commit "It works"
$ git push origin master
Once you've done this, you can trigger other tasks like your continuous integration tools or deploy the changed code to the Engine Yard Cloud.
InfoQ: Do you think that this would be a logical extension to how developers currently build on-premises or cloud applications?
Engine Yard: Developers today test their applications locally and/or test them in a staging environment with a cloud provider. Engine Yard Local allows developers to develop and test their applications locally while making the process much more efficient. They can use Engine Yard Local for on-premise or cloud applications.
InfoQ: What uses cases (e.g. performance testing) do NOT make sense with Engine Yard Local? When do you really need to run your app on Engine Yard to get the full effect of something?
Engine Yard: Engine Yard Local is not intended for multiple virtual machines at this point. It’s also better for applications running in a staging environment as opposed to a production environment. Once an application is ready to scale to a multi-VM production environment, it’s time to deploy to Engine Yard Cloud.
InfoQ: Do you see this as a tool to accelerate migration of on-premise apps by allowing potential customers to "try out" the cloud before pushing to it?
Engine Yard: Absolutely. Engine Yard Local streamlines the process of moving to the cloud. It provides an easier way to troubleshoot deployments. Users can spin up instances which have the same tech stack components as in an Engine Yard Cloud environment. When they are ready to deploy, they can push a button and their app is deployed to the cloud.
