Auto-scaling with AppScale in Azure
AppScale continues to make App Engine applications portable
If you read our blog, you already know how much we like and value the App Engine model at AppScale. Google created a brilliant PaaS with App Engine that allows developers to focus on the application and their innovations. App Engine abstracts away the need to plan ahead for scaling, ops, or infrastructure changes/improvements. We liked it so much, that we created an Open Source version of it. Find us on GitHub and star us!
Among AppScale’s value propositions, portability is most popular. AppScale enables you to un-tether your applications from Google’s infrastructure, and move them wherever and whenever you need, whether that is for privacy, cost, regulatory or customization reasons. It’s the ultimate “anti-lock-in” weapon and it “future-proofs” your app. And since AppScale is Open Source, there will be no surprises in the future -- you own and control the system down to the bits.
We took great care in making AppScale portable to a large set of infrastructures, and while we take advantage of native provisioning systems present in private or public clouds, AppScale can also run on other, less advertized resources. Each AppScale release comes with easy to deploy images for Google Compute Engine, Amazon EC2, Alibaba Cloud (Aliyun), Azure, OpenStack, Eucalyptus, Docker, KVM, Vagrant, VirtualBox, VMWare and anywhere else a raw image can be used to start a virtual machine. AppScale is easy to build from source too. Our community members are even experimenting with AppScale on Raspberry PI. Click here for a list of ways to run AppScale.
Slaying the scaling dragon
One, if not the most important feature of App Engine, is the ability to scale the application automatically and autonomously. Developers, or application owners, need only specify the desired scaling limits, and the system takes care of everything else. This is what makes App Engine the platform of choice for applications that require scaling support for varying and unpredictable loads, such as mobile gaming apps.
Any developer or op, who has had to deal with scaling, understands the importance of this. Gone is the time of having to re-write the application to eliminate bottlenecks, and there is a new one under every rock; gone is the time of worrying about predicting the size of a database properly, and incurring expensive downtime while moving to a larger db; gone is the time of having to guestimate how much capacity an app may need in the future. Also gone is the tremendous amount of monitoring needed to be able to scale underlying resources up or down before the app crashes, or the bill goes through the roof. Lastly, gone is managing the size of the engineering team in order to refactor the application for that new larger customer load.
Today’s tools are getting better in assisting with managing and automating application scaling (Kubernetes, micro-services, load-balancers, etc.). For most PaaS, such scaling however still remains a manual and error-prone business, with appropriate monitoring and manual intervention needed at the deeper levels. Only App Engine takes care of all that automagically.
Autoscaling and AppScale
AppScale implements the App Engine model in open source, facilitating application autoscaling according to load needs. AppScale runs on a multitude of resources and infrastructures, but for the purposes of this blog post, we will categorize them into two: cloud infrastructures and all the rest.
On non-cloud infrastructures, AppScale automatically scales the application as long as there are available resources (virtual machines, AKA nodes) to use. For example if a deployment has nodes with available capacity, AppScale will use them accordingly as the application needs grow. This also improves efficiency when multiple applications run on the same deployment, but not all of them demand the same amount of resources.
Cloud Infrastructures provide the ability to ask for resources on the fly (the now famous “pay-as-you-go” model), with seconds to few minutes of lead time. AppScale takes advantage of that feature and adds more nodes, CPU, disk or anything else needed at the time.
On cloud infrastructures, AppScale can interact with the provisioning API and acquire more resources along with growing demands of the application. AppScale is elastic and releases such resources if/when the load spike dissipates.
In the next AppScale version (3.1) we will support Microsoft Azure natively as a cloud infrastructure (see pull request). Although we already have customers and users running AppScale on Azure, at this time they are not taking advantage of the resource provisioning capabilities of Azure. In the next version of AppScale, Azure will join GCE, AWS, OpenStack and Eucalyptus as a managed cloud infrastructure -- with automatic scaling!
To enable this, we at AppScale have been working closely with the Azure team to create a new component that interacts with the infrastructure, called the Azure agent. Because of the Azure team’s contributions and help, we were able to make it happen in a single sprint cycle. The code is currently under review, before being merged into the AppScale master branch, and extensive tests are added in our QA system for the Azure cloud support.
The Azure agent in AppScale 3.1 is new, and marked as a Beta version. We plan to release a production-ready version of it in AppScale 3.2.
Although this agent is fully-featured and compatible with other AppScale agents, we have begun work with the Microsoft Azure team to develop a more advanced version of the Azure agent, which will use VM Scale Sets for the different AppScale roles. The new development will use the Azure infrastructure more efficiently and will be faster to deploy and manage resources.
Using the Azure agent
The Azure agent integrates seamlessly into AppScale, which means that the application or the App Engine developer won’t see any difference in behavior or response if AppScale is configured to use the new agent. The visible changes are relegated at AppScale deploy time, when the infrastructure needs to be configured. All those changes happen in the AppScalefile. First the infrastructure needs to be specified:
infrastructure : 'azure'
then we need to tell AppScale which image to use. The image needs to be prepared ahead of time, and it needs to have appscale and appscale-tools already pre-installed. At 3.1 release time, we will provide a publicly accessible image also for Azure:
machine : 'URL-to-appscale-image'
specify which instance type to use:
instance_type : 'Azure-VM-Size-Type'
specify which zone to use for this deployment:
zone : 'West US'
and finally the credentials to use when talking to Azure **:
** A prerequisite to obtaining these credentials is to use the Azure CLI to create a Service Principal which validates access to the resources. Use these instructions to create a Service Principal and grant appropriate permissions for your subscription. A ‘Contributor’ role would be one of the roles to allow the user to have write access.
We also have some optional settings that can be used to specify the group, the tag and the storage account name. From here on follow the usual instructions on managing your deployment and applications.
As always we would love to hear from you. Check out the Azure work on GitHub, fork us and star us! Thanks.