I'm very excited to announce our second OpenStack Israel event which will take place on Tuesday this week, November 27th.
At this event you'll be able learn about the latest developments in OpenStack from Jonathan Bryce Executive Director at the OpenStack Foundation.
One of the other highlights of the event is a local success story by Koby Holzer System & Storage Engineer Group Leader at LivePerson who will talk about their experience with running OpenStack in production across multiple data centers. We will also have several talks focused on one of the hottest areas in OpenStack development - Network/ Quantum and SDM delivered by Yaron Haviv from Mellanox. Vachnis Avi from Alcatel will present their choice of OpenStack APIs as the de-facto standard for Cloud APIs.
Those who are also looking to get their hands dirty will have the chance to learn how to setup a simple OpenStack environment on your desktop from Ori Tzoran, DevOps Senior Engineer @ "Tikal Knowledge".
As with previous times, we’ve reserved slots for lightning talks - so, if you have an interesting story you'll have the chance to share it during the event.
I look forward to seeing you all at the event.
Please make sure to RSVP to secure your place at the event as the seats are limited.
I also argued that the current approach doesn't work, as we need to think of moving apps not as one-off projects, or as an afterthought, but at a large-scale. Moving apps at a large scale requires a completely different thinking.
I laid out what I believe should be the core principles behind this approach:
No Code Change - Any change, even the slightest one, to our existing apps will slow down our migration efforts substantially. Furthermore, many of the apps are third-party apps, where we often times don't even have control over the application code, so changing the app is likely not an option. There are many things that we can benefit from by moving our apps to the cloud, such as automation, ease of change, and configuration. We can obviously benefit more if we change our apps to take better advantage of the cloud infrastructure, but the right order would be to do this after we’ve already migrated the app to the cloud in the first place. There, of course, will still be many cases where just automating the way we run our apps and make them available on-demand would be sufficient enough.
Plug-in to the Current Way of Running Apps - The common way for running apps today is either through custom shell scripts in the simple case, or through configuration management tools such as Chef or Puppet in the more advanced case. If we want to migrate apps at a massive scale, we need to be able to plug-in to the most common environments, and make it possible to import them almost as is. In this way, we could leverage the knowledge and know-how that has already been invested into these systems and make the migration process vastly shorter.
Use Shared Infrastructure Across the Stack Regardless of the Language - Using different frameworks for each element of our application stack based on the language and environment in not going to scale for obvious reasons, such as complexity, a large number of moving parts, inconsistency, among other reasons.
Add Cloud Properties from the Outside - There are many cloud properties that we can apply to our existing apps without forcing any changes. For example, we can automate the scaling from small to bigger machines, we can also automate the configuration, and setup. We can significantly simplify the way we run the app by making it available on-demand. All these cloud properties can be plugged into almost any existing app without forcing a real change, as noted in the MySQL example.
Use the Baby Steps Approach - One of the main inhibitors to migrating apps was the all or nothing approach. There are many risks involved in migrating apps that go well beyond the technology challenge. The easiest way to mitigate such risks is by taking them one at a time. For example, we can first make our apps cloud ready, in which case we will abstract the automation part from the target infrastructure. By doing so, the decision where to run our app becomes tactical and less strategic. We can choose to run our production in our private data center, and run only testing and demos on the cloud. In this way, we can also make the migration gradual and smoother.
Incorporate Bare-Metal into our Cloud - One of the main challenges that I’ve seen for moving true enterprise workloads to the cloud wasn't necessarily related to the cloud, but to the virtualization overhead that is often used as the underlying infrastructure of many clouds. Today it is possible, to gain access to bare metal clouds which make it possible to run almost any workload including I/O intensive ones without any performance overhead, as I noted in my post about the emergence of bare-metal clouds.
In this post I will be referring to the way we've implemented this approach with Cloudify.
General approach
The least common denominator with all applications, regardless of their size and language, is that they all map to a group of processes with some degree of interdependency between them. 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. Having said that, working at the process level is often not enough as not all processes were 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 such.
Working on the process level makes it possible to plug-in to a large variety of infrastructure environments whether they happen to be in public, private or bare-metal environments. Cloudify uses an abstraction layer known as the Cloud Driver that allows it to plug-in to a large variety of cloud and private data center environments through simple configuration.
Here is how Cloudify maps to the specific principles that I laid out above:
No Code Change - Because Cloudify works on the process level, and uses a recipe-based approach it doesn't require any code change to get Cloudified.
Plug-in to the Current Way of Running Apps - The Cloudify recipes was designed to plug-in to diverse application environment configurations and setups. This currently includes basic shell/batch files in the simple scenario, as well as configuration management with tools such as Chef or Puppet in more advanced scenarios.
Use a Shared Infrastructure Across the Stack Regardless of the Language - Cloudify uses the same infrastructure to automate the deployment, fail-over and scaling, or in other words, a large variety of workloads - starting with simple web apps to Big Data apps. All this is possible due to the fact that Cloudify uses a process + recipe-based approach as I outlined earlier. In addition, the Cloudify abstraction of the underlying infrastructure details makes it possible to use the exact same application recipe on different target platforms whether they happen to be on public, private and bare-metal environments.
Add Cloud Properties from the Outside - Cloudify automates the deployment and configuration of the application even in the case of complex multi-tier applications, making it possible to launch the application on-demand on any given environment. In addition, Cloudify can plug-in to the application-specific metrics which makes it possible to detect application-specific SLA breaches, and thus automate the fail-over process as well. On top of that, Cloudify comes with a scaling rules plug-in that makes it extremely simple to add more instances to the application for scale-out purposes, or simply to enable it to move from smaller to bigger instances, in the case of a scale-up model. (See the MySQL use case as an example).
Use the Baby Steps Approach - With Cloudify all you need to get started is a start and stop script. All the other elements such as custom metrics, auto-scaling and more can be added at a later stage, making it possible to grow gradually with the value, and add more cloud properties as we grow. Additionally, the Cloud portability enables to first automate our apps on our existing environment, and then move to the cloud at a later stage. A good example for this would be to keep our production on our existing environment, and testing on the public environment. A more advanced incarnation of this could be to combine the two into a complete hybrid-cloud deployment.
Incorporate Bare-Metal into our Cloud - Cloudify was designed to work also on regular ol’ non-virtualized environments. In such a case, it takes a list of IP addresses as a fixed pool and manages the workloads elastically within the boundary of that pool as noted in this post bare-metal clouds.
Live Demo:
Below is two references that shows how Cloudify is used in the context of migrating enterprise Workloads to the cloud.
The first example uses IBM Infosphere BigInsights which an enterprise grade Hadoop distribution.
The Second example shows IBM WebSphere application deployment:
Final notes
Cloudify was designed, to a large degree, on the lessons of our earlier generation PaaS solution. In our earlier generation solution, we took a cautious decision to bind it specifically to Amazon and chose Java as the primary language of choice. A lot of that had to do with the maturity of the cloud market at the time, and the availability of tools and frameworks. Since then, there has been a very rapid advancement on almost every front which changed the entire landscape. That brought us to develop Cloudify.
When we came up with Cloudify the first thing that was clear to us was that we could take a vastly different approach to the way most PaaS solutions were designed to to run, and set the ambitious goal for running any app, on any cloud without compromising anything in terms of the control factor. I didn't expect that within a period of a year we’d see major enterprises and ISVs use Cloudify to run apps that, even I, never imagined could run on the cloud--such as network-based services and legacy apps that were written ten years ago when cloud was only an item in our weather report.
Today, I'm even more surprised to see how independent users have become with the platform. For example, one of our partners is using Cloudify for continuous delivery and integration. Another partner is using it to speed up the project delivery time for his customers, and use that as a major differentiator from their primary competitor. A major enterprise is using Cloudify in combination with Chef where they build an entire framework to automate the deployment of applications that were described in Chef, and auto-generate the Cloudify recipe on top of that. A major ISV is using Cloudify as part of its own cloud solution to offer their existing apps as a service, as well as on-board customer apps to their cloud platform. These are only few examples that represent some of the more interesting use cases that I came across recently. There are many projects that are coming along specifically around our recent integration with Chef and the work that we've done on the big data front.
Recent Comments