BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Now, though, the Apache Software Foundation (ASF), a nonprofit organization that provides support for open source software projects, is finalizing work on Apache Stratos 4.0. As a multi-cloud Platform as a Service (PaaS) framework, Stratos promises to allow the integrated deployment and management of a PaaS across various public and private cloud infrastructures. The approach could make it possible to create an application once, then move it or scale it across providers based on business or operations rules.
Stratos was initially developed by WSO2, a Sri Lanka-based provider of enterprise middleware platforms with U.S. headquarters in Palo Alto, Calif. WSO2 donated the software to ASF in July 2013. The new version represents not just a mere upgrade, but a rethinking of the architecture, noted Luca Martini, distinguished engineer in the Mobile Internet Technology Group at San Jose, Calif.-based Cisco Systems Inc. "Stratos 2 and 3 were mostly focused on Web services," Martini said. "Stratos 4 will enable a true PaaS."
Getting smarter about scaling
Lakmal Warusawithana, a WSO2 software architect, reviewed some features of the upcoming multi-cloud release during the recent WSO2Con 2013 U.S. conference in San Francisco. Overall, Stratos 4.0 lets an organization create a secure multitenant, elastic, metered and billed PaaS, he said. It also includes cloud bursting abilities and it standardizes communications using a message broker. Another feature: a real-time event-processing engine that can be used to analyze real-time data and automatically scale the instance up or down.
Stratos 2 and 3 were mostly focused on Web services. Stratos 4 will enable a true PaaS.
distinguished engineer, Cisco Systems Inc.
These new features open the door to what Warusawithana called multifactor autoscaling, which can be guided by application health or businesses rules analyzed by an event-processing engine. That capability allows companies to create smart policies that can work across multi-cloud deployments.
The architecture allows external load balancers that can publish statistics to the real-time event-processing engine to scale up or down the instance. This capability could also be defined as a cartridge, allowing the load balancer itself to automatically scale up or down with the application. The cartridge model allows the load balancer to scale as well. If an organization needs separate load balancers, the cloud controller will spin them up.
The load balancer can publish settings to a central, complex event processor. That capability allows all of the parts involved in load balancing to scale on demand. With multifactor autoscaling, a failure message from a load balancer can be analyzed in real time to make a decision about scaling or moving the application instance.
The new architecture also introduces smart policies. These could include rules for higher availability, failover, lower costs, maximizing the use of dedicated resources, or other more complex behaviors -- all of which could be defined by the DevOps team. For example, if you wanted 99.999% availability, you could define the policy and enable it across a multi-cloud deployment.
In addition, Stratos 4.0 will enable cloud bursting across multiple providers. With cloud bursting, it will be possible to have a private PaaS for setting up resources in such a way that the app could burst onto other infrastructures. When an organization is bursting onto different clouds, each instance could also include load balancing capabilities. This provides a cost-effective way of running an app on dedicated servers without worrying about peak time resource allocation.
The costs can add up for a company that is running a PaaS on Amazon Elastic Compute Cloud (EC2) for many years, Warusawithana said. A private PaaS could allow an organization to run the bare applications on dedicated hardware 24x7 to reduce the cost of the PaaS environment. Then if the app load peaks, the infrastructure could automatically scale across a public cloud provider's infrastructure as required.
Write once, deploy anywhere
The subtle differences in the ways Infrastructure as a Service (IaaS) services are configured can make it difficult to run code across multiple clouds. The Stratos 4.0 work will build upon Linux Containers, a lightweight system virtualization architecture that isolates the resources required to an application from the underlying IaaS infrastructure.
That factor allows developers to create a universal cartridge that runs across the various clouds that can be managed by an integrated cloud controller. The use of cartridges will make it possible to use the policy engine to move a cartridge across multi-cloud IaaS platforms, depending on different rules, such as cost or availability. An organization could run a dedicated instance on an internal cloud to keep costs down, but then burst to other providers with higher demand. The developer creates a container that runs on EC2, OpenStack or other clouds without modification.
However, the cartridges are designed to be stateless, so a database cartridge will lose its data when closed, Martini said. That, in turn, can present a challenge for database applications. It's possible to run such applications as a process by pointing them to a persistent store -- like Amazon Simple Storage Service -- that could be accessed after the database management cartridge is closed.
Stratus 4.0 runs on a variety of IaaS systems, including EC2, VMware vCloud and OpenStack. It should also work on any IaaS that Apache jclouds supports.
The basic platform is currently in incubation; ASF hopes to deliver an alpha version in December 2013.