Category Archives: GigaSpaces

Alcatel-Lucent, GigaSpaces, Guest Post, Partnerships

Alcatel-Lucent, GigaSpaces Partner for Delivery of Carrier Cloud PaaS

Guest post by Adi Paz, Executive VP, Marketing and Business Development, GigaSpaces

GigaSpaces Cloudify solution enables the on-boarding of applications onto any cloud. For several months now, GigaSpaces has been working with Alcatel-Lucent (ALU) on the use of Cloudify in a carrier cloud service environment. Together with Alcatel-Lucent’s CloudBand™ solution, Cloudify is a fundamental building block in the technological backbone of ALU’s carrier-grade Platform-as-a-Service (CPaaS).

Dor Skuler, Vice President & General Manager of the CloudBand Business Unit at Alcatel-Lucent, has said that, “Offering CPaaS as part of the CloudBand solution enables service providers to make a smooth migration to the carrier cloud and quickly deploy value-added services with improved quality and scalability, without the need for dedicated equipment.”

This new class of carrier cloud services brings the benefits of the cloud to the carrier environment without sacrificing security, reliability and/or quality of applications. The CPaaS enables the on-boarding of mission-critical applications on a massive scale, including both legacy and new carrier cloud services. This is a factor in meeting the requirements of many customers’ Service Level Agreements (SLAs) by integrating carrier networks.

Unlike regular cloud environments, where an application needs to explicitly handle multi-zone deployments, CPaaS enables the application workload and availability to be handled through a policy driven approach. The policy describes the desired application SLA, while the carrier CPaaS maps the deployment of the application resources to the cloud and reflects the best latency, load, or availability requirements.

Additionally, the integration will enable the creation of network-aware CPaaS services, simplified on-boarding to ALU’s CloudBand platform, multi-site app deployment and simplification of management of a number of latency and location-sensitive applications. The ability to comply with five-nine reliability, security, and disaster recovery requirements ensures peace-of-mind for enterprises choosing to on-board mission-critical applications to the carrier network.

The Cloudify Approach

Cloudify manages applications at the process level, and as such uses the same underlying architecture for any application regardless of the language or the technology stack that comprises the application. That said, working at the process level is often not enough, because not all processes are made the same. For example, databases behave quite differently from web containers and load-balancers. In order for us to still get in-depth knowledge about the managed application’s processes, Cloudify uses a recipe-based approach. The recipe-based approach enables us to describe the elements that are specific to that individual process, such as the configuration element, the dependency on other processes, the specific key performance indicators that tell if that process’ behavior is aligned with its SLA, and so on.

Working on the process level makes it possible to plug into a large variety of infrastructures, whether they happen to be public, private, or bare-metal environments. Cloudify uses an abstraction layer known as the Cloud Driver that interfaces with the cloud infrastructure to provide on-demand compute resources for running applications.

The Cloudify process can be implemented be done on individual clouds from HP, Microsoft, IBM, CloudStack, etc., or in the carrier network infrastructure of a company like Alcatel-Lucent.

Adi Paz is responsible for developing and communicating GigaSpaces’ strategy, and managing the company’s go-to-market activities and strategic alliances.

 

GigaSpaces, Guest Post, No-Ops, PaaS, Platform as a service

Does PaaS Really Mean No-Ops?

Guest post by Yaron Parasol, Director of Product Management, GigaSpaces

Yaron Parasol is GigaSpaces Director of Product Management

I’d like to start with a brief overview of the evolution of the cloud – and why I think a new approach to PaaS solutions is needed – and the best scenarios for this to come into play.

First there was IaaS. Cloud was created with the notion of IT agility and cost-reduction. You need servers? No problem! Forget about red tape, forget about sys admins. You create an account and in few clicks you select the hardware profile and OS image you need, and voila, your server is out there, ready for you to use. No hassles, immediate gratitude.

Well, this is true as long as the images you get form your cloud provider match your needs. If you have custom needs, you will have to create and maintain your own image. So, you need the sys admin’s knowledge. However, we’re also seeing a change in methodology here – sys admins no longer need to install the servers once they’re up. Instead, they provide their expertise using approved and maintained images on the cloud. Application developers can choose the right image for them and from that point on, create virtual machines in the amount and hardware size they need for their applications.

Now let’s switch to PaaS. The idea of no-ops is the guideline for many of the existing PaaS offerings. Their use cases and features are all about developers. As Michael Cote put it:

“The point of PaaS is to make a developer’s life even easier: you don’t need to manage your cloud deployments at the the lower level of IaaS, or even wire together your Puppet/Chef scripts. The promise of PaaS is similar to that of Java application servers: just write your applications (your business logic) and do magic deployment into the platform, where everything else is taken care of.”

Developers need to deploy applications to the Cloud. They don’t want to care about the OS but they also don’t want to care about platforms, load balancers etc. They want to focus on what they know – writing code.

This is definitely a very productive approach for some developers and some applications. Reality shows that a big portion of Cloud users don’t find these solutions a good fit for their purposes. These users continue to deploy and manage their applications on infrastructure clouds, as if they were running on premise leveraging the good old Ops folks. Others have taken a more agile approach, using configuration management and automation tools such as Chef.

These users chose not to use PaaS because they need flexibility and control. PaaS doesn’t seem to answer a lot of the current IT challenges – see for example here and here.

Existing applications with a variety of platforms, some using extremely complex topologies (like Hadoop, or a sharded MongoDB setup) are some of the reasons why PaaS won’t cut it for many users.

They would like to install their chosen versions of their preferred platforms, use their OS image, with their configured security groups, tune them in a manner that fits their applications and deploy their applications with the topology they choose.

Chef, like other DevOps tools, go a long way here and helps to achieve the flexibility while re-establishing a new agile relationship between Dev and Ops. Ops bring in their knowledge and skillset, but they document it and maintain it as code in a more structured and configurable way. This in turn gives the application guys the agility they need, putting a complex application to work in a single click and eliminating the platform black box experience which they dislike so much.

Application vs. Separate Platforms

However, DevOps tools still fall short when it comes to managing applications. They are not aware of the application’s inner dependencies. They don’t know how to monitor the application, scale it or even run a complex multi-tier recovery process. Most of these tools can’t even provision an entire application on the cloud.

So what if you could extend the DevOps experience to apply to the entire application lifecycle?

What if you could use Chef and the likes for installation but not stop there – automate things like failover and recovery, and even monitoring and scaling? You will still have all the Ops wisdom tailored to each of your applications and be able to automate any of your existing applications without re-architecting them.

This is exactly our take on PaaS, a DevOps style process that can describe any application’s lifecycle on any runtime environment, providing full automation without taking away the control.  And this is exactly what we set out to do with our Open Source PaaS platform – Cloudify, borrowing the idea of recipes but extending it to be application-centric and not infrastructure-centric.

The recipe describes the application dependencies and lifecycle events externally without any code or architecture change.

lifecycle{
init "mongod_install.groovy"
start "mongod_start.groovy"
postStart "mongod_poststart.groovy"
}

view rawmongod.groovyThis Gist brought to you by GitHub.

See how to create your own recipes here.

Mapping events like installation, start, post-start and stop to scripts or Chef cookbooks, exposing groovy andREST interfaces for context sharing and dynamic configuration and even provide a way to describe monitoring techniques, scaling rules and process “liveness” detection.

So think about it this way: while most PaaS services come with a catalog of predefined application blueprints, allowing the user to control only the application code, this new kind of PaaS stack, allows the user to define the blueprint, that is – any blueprint!

So, the recipes combine the Ops expertise with the power of automation for the developers. They completely remove the lock-in risk from the application-stack perspective.

You can read more the recipes, download Cloudify and experience it yourself or even join the community and influence the roadmap at cloudifysource.org. Or you can come see more when we present at HP Discover next week in Las Vegas.