ActiveState recently released Stackato 3.2, packed with lots of awesome new features. Many of these new features are key requests direct from our existing customers. And today I want to draw focus to the new feature that is sure to make the IT management and DevOps people happy--really happy. This new feature is availability and placement zones.
Think for the IT/DevOps
Many say that a PaaS should primarily be designed with the developer experience in mind. While I don’t disagree that the developer's experience is important, I’d argue that the IT management experience is just as important, especially when it comes to Private PaaS.
Why does this availability and placement zones feature make IT people happy? From conversations with our customers, we are often asked how customers can control where applications are deployed. My initial thought is that from a developer’s perspective, why do you care? The application is up in the cloud, and is running normally, so everyone should be happy… but apparently not the IT guy. I put on my IT hat, and wear my IT boots, and dive into their concerns.
How does IT know where the applications are in order to know what is lost if something fails? Resource planning and management is always on their top of mind, and if there is no easy way for them to know where applications are, and what the impact from a failure could be, they will freak out. I'm not kidding here.
How does IT know that the applications are properly distributed such that if something fails, the applications is still serving the target end users? Uptime! To the IT guy, any downtime is not acceptable. Let’s be realistic though, unless it’s a really, really expensive solution, we’re unlikely able to have perfect uptime. Like all other technology and things, certain parts will fail. While not necessarily expecting the perfect uptime, the expectation is still to maintain as high of an uptime and availability as possible to serve the end users.
How would you determine the physical/virtual resources in order to tailor to the hosted applications? It is not atypical for enterprises to have various categories of applications that could have significantly different resource requirements. What can be done to better align with the physical resources they already have in the organization?
Availability Zone and Placement Zones
With the release of Stackato v3.2, we added availability and placement zones so that our customers could have more flexibility and control over where they deploy and scale their applications.
If you have worked with Amazon EC2 or other public cloud services, you're probably already familiar with availability zones. Availability zones are usually tied to either geographical locations or physical infrastructure, grouping resources that may fail together. Let’s take a look at a couple of use cases with availability zones:
physical host machines with different power source
two geographically separated locations.
Scenario 1: While we are working with virtual servers and containers, let’s not forget that there is still underlying hardware supporting all the fancy software. When multiple physical host machines do not share the same power source, it makes sense to the use Availability Zone to define and separate the servers from each power source. In the ever-so-unlikely event that your IT staff accidentally trips over the power cord to one of the virtual hosts, it won’t bring down the other host that has an instance of your application running.
Scenario 2: At scale, with two separate data centers in different locations, you may identify each data center as an availability zone. When configured properly, your applications can survive site disasters as there will still be applications running in the other data center to serve your end customers. 
Whereas availability zones are used to spread application instances across multiple racks or geographic locations, placement zones restrict application instances to a certain set of VMs (droplet execution agents). Admins define nodes as belonging to one or more placement zones, and developers or deployers choose which placement zones to push their applications to.
A single DEA can only be in one availability zone, while it can belong to many placement zones.
[Learn More about DEAs and Stackato Architecture]
The examples later in this article will present a few typical scenarios using both availability zones and placement zones.
Application Instances and Distribution
Many people associate application instances with Virtual Machines. In Stackato, your application runs in its individual docker containers.
The diagram above provides a visual representation of the containerization approach to hosting applications. At the base of the infrastructure, the physical layer, we are working with physical servers that are often referred to as host machines. Virtual machines running inside the physical host are typically refer to as guest machines. Containers are then run inside the guest operating system for security, utilization, and portability purposes. Applications pushed to Stackato are deployed to Docker containers. As an application is scaled to increase another instance, another identical Docker container is spawned to house the entire application stack, and the router automatically registers the new route. This, is efficient elastic scalability with little to no manual intervention.
When scaling out horizontally, the logic for distributing application instances first spans across availability zones, then considers distributing instances across DEAs within the same zone. It ensures that instances are split evenly across availability zones before considering how many instances there are in each DEA within a zone. With this distribution strategy, Stackato is able to ensure your applications have instances running reliably across the platform.
Refer to the animated diagram below as an example of how an application is scaled from 1 to 8 instances across two availability zones.
Example Scenarios
Let’s take a look at several practical availability zone and placement zones strategies, all very common scenarios across enterprise companies:
1. Heterogeneous Resources
This is a straightforward scenario in that placement zones are used to separate resource classes. When you have certain resources with higher IO throughput (ex. SSD vs HDD) and certain resources with higher CPU (Xeon vs Celeron), place your CPU-intensive applications and IO-intensive applications accordingly.
2. Heterogeneous Resources at Multiple Locations
Let’s extend the first scenario. Now that the placement zones span multiple availability zones, application instances are distributed across datacenters. Now your applications are earthquake-proof, hurricane-proof, and just a bit more realistically power-outage-proof! Oh, and have you heard of the hybrid cloud?
3. Multiple Environments and Multiple Locations
This diagram depicts a scenario where dev groups in the east and west can deploy to their "local" placement zones associated with the respective availability zones during development and testing. When the applications are ready for production, the applications can be promoted to a placement zone which spans both availability zones, such that the applications can tolerate site failures.
4. Complex scenario with multiple environments and multiple resource types.
While each DEA can only have one availability zone assigned, a DEA can belong in multiple placement zones. This diagram showcases a complex scenario where there are multiple environments, with various resource types as well as geographical or availability requirements. Developers from US West may choose to just use the basic Dev environment, The US East developers can be collaborating with European developers on some applications that require high IO throughput. The production environment spans multiple availability zones, while high IO applications can be specifically placed in the high IO production resources.
The examples above show that the use of availability and placement zones allow for full control over application deployments that fit your business needs. With proper setup of placement zones and availability zones, you get a flexible, scalable, reliable and highly available platform for running your applications. Stackato has been designed to support the elastic scalability and maintain the availability that your business requires.
Coupled with the super awesome application autoscaling feature, we get a truly elastic, portable, and infrastructure agnostic environment allowing applications to take full advantage of the cloud.
Follow @HoReal
Share this post:
If you'd like to evaluate how availability and placement zones work, you can download Stackato or contact us to request a customized demonstration.