Nati Shalom's Blog

Our Open Source Cloud (Re) Architecture with OpenStack + TOSCA

Cloudify OpenStack Native approach - The Story behind the Scenes

In the previous post I outlined what I mean by native-approach to the OpenStack cloud. In a nutshell, a native approach represents out of the box tighter integration with OpenStack, all without being limited only to OpenStack.

In this post I want to share some of the stories behind the design of Cloudify 3.0 and the approach that we have taken to make Cloudify *native* to OpenStack.  I would first start by outlining our motivation behind this approach.

OpenStack-only or Not-only-OpenStack?

It is our core belief that for the foreseeable future supporting hybrid cloud is going to be important for many of the OpenStack users for the following reasons:

1. Transitioning to OpenStack is a long journey - Many enterprises have VMware-based stacks as their core infrastructure. Where many of these organizations have often started their journey toward OpenStack by creating a dev environment, and then gradually moving more workloads into their OpenStack environment as they get more comfortable with it. This process usually spans over months and possibly even years. It became apparent to us, that during this time these customers would still be using VSphere and VCloud in parallel to OpenStack. For such users, having a common platform to manage their app deployment across two environments can smoothen the transition and also reduce the risk of getting stacked if one of the environments doesn’t meet their needs.
2. The public cloud market is going to be dominated by non-OpenStack clouds - while OpenStack is on a trajectory to dominate the private cloud market, the public cloud market looks quite different with AWS as a strong and long-standing leader and other major clouds emerging such as GCE and Azure - hoping to close in. Many organizations wouldn’t want to host their entire data center on a private cloud, and would therefore need to take a hybrid cloud approach. In order to support hybrid cloud, we had to include an abstraction layer that will allow us to integrate with clouds other than OpenStack.

At the same time we wanted to have a more intimate integration with OpenStack in order to leverage the fact that it is open source and allows for a deeper integration with its core services. Through that we were able to enable smooth and simple integration of Cloudify into OpenStack.

Extending or Rewriting?

Cloudify 2.x already took a step toward deeper integration with OpenStack and we were one of the first to announce our support for OpenStack. Recently, we also added support for OpenStack Neutron.

We realized that if we want to make Cloudify fit natively into the OpenStack infrastructure it is not enough to have integration with the OpenStack components.  We also need to ensure that the design behind Cloudify will be consistent with the way other projects and services of OpenStack are implemented. This led us to the conclusion that we wouldn’t be able to be a first class citizen with OpenStack unless we underwent a major redesign of Cloudify.

Going Python?

Our first step in this direction was to move from Java to Python. Moving to Python wasn’t as painful as you would think for us, because many of our developers already knew the language. This decision quickly proved itself, as it became much simpler not just to develop the new version of Cloudify faster, but it also enabled us to join other OpenStack projects as well as reuse some of the same components and frameworks that are already used by OpenStack.

Integrating with Core OpenStack Services

Many of the products that declare support for OpenStack mostly integrate with the compute API (Nova), and quite often come with their own security, messaging, configuration, and other such considerations. We felt that this is not enough, and doesn’t fit in with the way other services are built within OpenStack. Hence, we decided to deepen our integration with other services such as Keystone, Neutron, Heat and later with Ceilometer, Mistral and others.

Going TOSCA?

Cloudify 2.x was designed around a proprietary Groovy-based domain specific language (DSL) for defining application topology and configuration. It became apparent that the DSL had become a central piece of Cloudify architecture. As a result, maintaining a proprietary DSL would only serve as a barrier going forward. TOSCA (Topology Orchestration Specification for Cloud Applications led by the Oasis Foundation) defines a standard templating language. TOSCA was similar and richer in concept to our previous 2.x specification. Because of this, using TOSCA seemed like a natural evolution.

At the time when we decided to use TOSCA, the specification was provided in a fairly complex XML. Our first step for adopting TOSCA was to come with a simplified YAML based version which better fits into the spirit of OpenStack. After the OpenStack summit in Hong Kong, when we first introduced the idea, it became apparent that members from the Oasis group were already thinking along this line.We decided to join forces and join the Oasis organization. We started working with the team to incorporate TOSCA as an official part of OpenStack. During the Atlanta summit, it was decided to integrate the TOSCA project into the Heat project and now there is an official definition of the TOSCA 2.0 specification based on YAML. Our goal is to use the TOSCA 2.0 specification as the official templating language for Cloudify instead of our current TOSCA like DSL.

Integrating with OpenStack Heat

OpenStack is growing, and with this the services that are included as part of the core OpenStack project continue to grow up the stack. One of these services is OpenStack Heat, which started as the equivalent of Amazon Cloud Formation, and is becoming more of a general purpose infrastructure orchestration these days.

We realized that since Heat is closely integrated with OpenStack it will follow the OpenStack release cycles and API, and therefore would provide a useful tool for setting up the OpenStack infrastructure. The approach that we have taken with Heat is an “overlay approach”. This means that users can use Heat as they do today to set up their infrastructure. Then, Cloudify integrates with Heat in a way that will allow it to discover any resource that was provisioned through Heat, and ultimately add the monitoring, logging and software stack on top of that environment. 

Integrating with Neutron - Network Orchestration

Networking becomes a core service in any cloud deployment. Networking refers to an element such as security-group, private IP, floating IP as well as routers, DNS, vLans, load balancers, and such.

Cloudify 2.7 included basic integration with Neutron that allows users to attach floating IPs and set the availability zone configuration.

With Cloduify 3.0, we included support for all the networking elements and can now create vLans, security groups and more, as part of the application deployment.

Design for Scale

Application orchestration often requires intimate and continuous integration with the application so that it can detect failure in sub-seconds and take corrective actions as needed. This often imposes a more complex scalability challenge.

Cloudify 2.x uses a hierarchy of managers, where each manager controls 100+ nodes as a scaling architecture. One of the things that we have experienced over the last year is that there is a growing class of services such as  Big Data and NFV. With these services, a single service can be comprised out of more than 100s and potentially even 1000s of instances. This is why the manager of managers approach didn’t fit well to these use cases.

To enable scaling of 1000s of nodes per manager, we decided to use a message broker approach based on AMQP as well as to separate the provisioning, logging and real-time monitoring tasks into separate services that can scale independently. This allows us to also control the level of intimacy between the Cloudify manager and the application services. As an example, we can tune Cloudify to handle the provisioning and logging only, and use the real-time information that has already been gathered by the infrastructure. This is especially important in the context of OpenStack, as we expect that a large part of the metrics can be gathered through the infrastructure itself.

Integrating your DevOps toolchain of choice

One thing that has become clear through the various OpenStack statistics based on their annual survey, is that many of the OpenStack users are using a toolchain that is comprised of tools available through OpenStack infrastructure, as well as tools that are not specific to OpenStack such as Docker, Chef, Puppet, Ansible, JClouds and others.

Integrating all these tools as part of a deployment system becomes a fairly complex task that can takes weeks and even months.

We realized that if we want to provide a full lifecycle management of the application, it wouldn’t be right to force a particular stack or toolchain on a user, but rather provide an open pluggable architecture that could enable you to easily integrate your choice of tools into the same deployment.

With Cloudify 2.x we included support for Chef, Puppet and also had a cloud driver that allows us to integrate with various cloud infrastructures, as well as with tools like JClouds.

With Cloudify 3.x we created a more generic plugin architecture that allows users to plug in almost any element of their application, starting from the cloud plugin to configuration management, orchestration, monitoring etc.

To make this simple we included a Bash plugin that provides a simple framework for integration with external tools, just by pointing the plugin to the relevant Bash script.

Final Notes

In this post I thought sharing the story behind the scenes that we went through to make Cloudify OpenStack native, and the rationale and decision process behind them, would be relevant to other users that are considering their OpenStack strategy.  Especially for those still deciding how deep they should integrate with OpenStack.

The good news is that, it is quite possible to integrate natively with OpenStack without limiting yourself only to OpenStack. Having said that, the initial investment required to get there is quite big. I hope that this lesson from our own experience will save others time.

OpenStack by the Numbers

One thing that I like about working with an open source community like OpenStack is that you get direct access not just to the source code itself, but to its users and ecosystem as well.  This allows you to be less exposed to marketing spins, and actually analyze our actions based on real numbers.

The OpenStack Foundation conducts a very insightful survey twice a year which helps to measure how users are using the technology. This is an important and useful feedback loop that goes to the PTL of the various projects, and can help product companies to analyze their go to market plans and such. You can find the source

I found the original version a bit too verbose, so I took the liberty to put together an executive summary of the main points from the survey, mostly targeted at decision makers. I hope that you’ll find it useful, any feedback would be highly appreciated.

Main Reasons for Choosing OpenStack

The main reason cited for choosing OpenStack is Open Technology and Avoiding Lock-in.

Interestingly enough Cost Saving comes only 4th!

 

Size of Deployments

The large majority of the current deployments are under 100 nodes.

Around 30% of the deployments run relatively large scale deployments between 500-1000.

QA/DEV	Production

Production seems to follow a similar trend but lower in numbers to QA, which is reasonable as I believe that some of the QA deployments represent a transition stage to production.

 

User Type

The majority of the users seem to be service providers and cloud operators.

There is also a good number of ISVs and ecosystem partners, which is a strong indication that OpenStack is indeed an ecosystem.

There's a very strong presence of OpenStack in the Telco industry. Finance seem to be lagging behind the adoption curve with only three financial organizations declaring their use of OpenStack.

The majority of the deployments run on private or hosted private clouds. About 20% run on public or hybrid clouds. OpenStack also seems to attract mostly small to mid-size companies.

 

Private/Public Clouds	Size of Organizations

 

Deployment Tools

The survey includes two categories for deployment tools, one for those that are used for deploying the OpenStack infrastructure, and the other that are used for application configuration (covered in the application survey).

According to the two surveys users tend to use different sets of tools for the infrastructure deployment and for application configuration management. Puppet seems to be the most popular choice for OpenStack users in both categories. 

One of the interesting results is to see that Bare Metal and Docker are starting to appear in more deployments. This is fairly impressive given that the two are not yet officially supported by OpenStack.  VMware is around 10%-13% of KVM of Virtualization similar to XEN.

 

OpenStack Deployment Tools

 

Applications on top of OpenStack

As noted above, Puppet is popular for application configuration, as well as infrastructure deployment. Heat and Docker take the 2nd and 3rd place respectively,  putting Chef behind in the 4th place.

Given the popularity of Heat during the last summit I wouldn’t be surprised if Heat and Docker will surpass the use of Puppet in this category.

 

 

Popular Frameworks

Interestingly enough, JClouds seems to be gaining popularity amongst OpenStack users. This may be an indication that ~ ¼ of the users are interested in frameworks that are not tied only OpenStack. Not surprisingly, Python is far more popular than any other language, however Java seems to have a good and dominant presence more than other frameworks. One possible explanation is that the type of users that are attracted to OpenStack are more of the traditional enterprise organizations, and less of the new web-facing companies.

Operating Systems

Ubuntu and CentOS are the most popular choice. Windows adoption amongst OpenStack users is between 10-20%.

<

Application Survey	Production Survey

 

Compatibility / Portability

EC2 is a relatively popular choice which indicates that there is an increasing desire among the OpenStack community to maintain portability with EC2. This also correlates with the popularity of portability frameworks such as JClouds.

 

QA/DevTest	Production Survey

 

References

• OpenStack user survey presentation
• OpenStack user survey online session from OSS Atlanta 2014

Making Chef as Simple as Ansible

In his book Taste Test, Matt Jaynes compares a few popular configuration management tools such as Chef, Puppet, SaltStack and Ansible.

Jaynes points to some of the areas of complexity within Chef in comparison to Ansible. According to Jaynes, Chef’s areas of complexity can be summarized by the following:

• Ease of Installation: Chef is not easy to install

• Agent Installation: Chef doesn’t provide a remote agent installation 

• Remote Execution and Update: Chef lacks remote execution and push update

• Ordering: Controlling the execution order of tasks is not intuitive

Making Chef as Simple as Ansible using Cloudify

One of the things that has kept me busy lately is how to make the experience of using Cloudify and Chef a smooth and simple experience. We wanted to get to the point where users can run a Chef Server or Agent, install cookbooks and wrap it with Cloudify Application Service in just a few minutes without having to download or install any software.

We've launched a new online service that does just that – making Chef on the cloud simple.

The way this works is that once you click on the launch button a new server is created on the cloud (HP OpenStack cloud in this specific case). Next we install the Chef-Server using Cloudify on that machine. After 2-3 minutes once the server is up a new interactive shell window is opened. The interactive shell will allow you to interact with the service by invoking a set of custom commands that are listed just below the interactive shell screen.

If you want to view the progress and process of deployment you can click on the “Manage Your App” button. You can also click on the “Use Chef” to open the Chef web admin.

While we wanted to make the experience simple it was equally important that we wouldn’t take shortcuts in that process for the sake of a demo. To that end, we kept the demo identical to the way you would run things in production. That means that all that is needed to build a similar demo yourself is download Cloudify and follow the same steps in your own environment.

Learn more about how Cloudify makes the Chef experience simple

Here’s how Cloudify maps specifically to the challenges outlined in Matt’s book.

• Ease of Installation: Cloudify comes with built-in server provisioning support that works with a wide range of clouds out of the box, namely OpenStack, AWS, Azure, CloudStack, among others. Cloudify also comes with built-in integration with Chef. Cloudify allows you get your Chef Server installed and running on any of the supported clouds. 

• Agent Installation: Cloudify will provision your application machines, install a Chef agent and wire them up with the Chef server. Or, if you choose to run solo, it will allow you to install the agent with the appropriate cookbooks for that service.

• Ordering: Cloudify allows you to define the dependencies between services and will launch them based on that order.

• Remote Execution and Updates: Cloudify uses a custom-command abstraction that allows you to execute remote shell scripts on a group of instances that belong to a particular service or to a specific instance in a group. This feature is useful to run maintenance operations, such as snapshot in the case of a database or code push in a continuous deployment model.

 

Remote Execution with Cloudify

 

Beyond Deployment Automation

While improving your deployment experience with Chef is reason enough to use Cloudify, there are other benefits to gain as well. The real long-term benefit of using Cloudify is to manage post deployment through built-in management, logging and monitoring capabilities, as well as the built-in workflow for automating failover and auto-scaling processes.

Cloudify 3.0 Monitoring

 

Technical Overview of the Cloudify and Chef integration

To learn more on how Cloudify works and how you can build your own Cloudify/Chef service see the Cloudify Chef integration documentation.

 

What’s next with Cloudify 3.0

The upcoming release of Cloudify (currently in Beta) includes further enhancements - specifically the support of Yaml/TOSCA-based configuration. Using Python to reduce the agent and server footprint, allows custom workflow setup to allow users to add their own set of rules to automate upgrades, fail-over and scaling processes, enhanced monitoring and many other goodies, so stay tuned for further updates shortly..

Final Notes

If you're a Chef or Cloudify user, please share your experience  with me with this new service and, more importantly, let me know if there are areas where we can do even better. I would be most appreciative of your feedback.

Notes from DevOpsCon Israel

The first DevOps conference in Israel turned out to be a great success.

With a room filled to capacity, and even people sitting on the floor just to take part - the energy level just hit the roof.

A great testimony to that is the number of comments on the Meetup page and tweets in the #devopscon twitter thread.

First thing first - in this post I'm going to focus only things that were covered in the main hall, as I  wasn't able to attend all tracks.

Main take away (In 140 Characters)

• Ben Kepes - Keepers of the Keys to the Kingdom - IT as manufacturing pipeline, undeployed code as wasted goods in inventory
• Ran Tavory - DevOps a Jungle of Tools - Infra management and application deployment are two distinct things
• Uri Cohen - One Does Not Simply Walk Into DevOps: There are three parts to DevOps. Culture & Processes, Infrastructure as Code, Application as Services.
• Clive Foley - We Tried to Build a DevOps Team and All We Got was this Lousy T-shirt - Having a DevOps team that is responsible for DevOps, is the wrong way to run DevOps
• Yosef Dinerstein - Continuous Deployment with Node.js over Azure - Microsoft Azure is not a .Net shop anymore

Common takeaways (Some, in slightly more than 140 Characters)

• NoOps? What's the role of IT in a DevOps world? The role of IT is to build tools and infrastructure that will allow developers to run their stuff straight into production.
• DevOps is about culture not tools.
• Applications need to be designed as loosely coupled services, otherwise it becomes impossible to manage continuous changes.
• It’s about accountability - Developers need to be accountable for running their code in production.

Panel discussion:

• Why do most applications in the cloud run outside of PaaS <- most people build their own kind of *private* PaaS
• Will (public) PaaS makes ops obsolete? <- heated debate - my personal view, probably in 3-5 years if nothing gets in the way <- Avishai you can relax, you have plenty of time before you'll need to find a new Job :)
• How to convince your management that DevOps is the right thing? – It’s about culture. You need to get the buy-in from top management. A useful way to get that buy-in is through the "build-it and they will come" approach. Once people "see the light" it’s much easier to get their buy-in for an idea.

Quotes of the day:

If it moves graph it, if it matters alert it (Allspaw)

You build it, You run it (Werner Vogels)

Done means Released (Jez Humble)

"Code that has been written but not yet deployed is very similar to inventory, you’ve paid the cost to develop the software but are not yet getting any of the benefit from it”- Mark Imbriaco, GitHub

Final Words - DevOps as a Movement

The are three elements that makes a movement IMO -  Frustration->Disruption->Passion

DevOps certainly fits into all three.

• Frustration (Pain) - many of us have been frustrated by not being able to do our Job, but rather get stacked by someone else’s job.
• Disruption (Cure)- DevOps leads to a complete disruption on many fronts - the way we design our apps (Services), the way our organization works (breaking up silos),  the way we run our business (agile, continuous delivery)
• Passion (Tell the world) – as a human being when we go through such pain and we feel that we’ve found a cure for that pain, we get passionate about it and we want to share it with others who share the same pain. DevOps seems to be that cure.

To put it in Seth Godin’s words

Leaders make movements, movements make change.

Now it’s your turn to become a leader or a messenger, and there are now many tools to make your job easier - you can start by proposing meetups, sessions, blogging, tweeting, and of course RT... or if you’re too shy for all that, just click Like or simply RSVP to the next event..

Where do we go from here?

There are currently two scheduled (local) events that are worth noting in this context:

- Check out the next Carburetor podcast - Ran Tavory, Ori Lahav and Myself will be sharing thoughts from the event on DevOps

- Reversim Summit 2013

If you have a great story that you want to share suggest a new DevOps meetup on the IGT Meetup page and we’ll take care of the rest..

Reference

• DevOps Conference Israel take-aways (Shahar Kedar)
• My talk about continuous delivery at SAP IT (Alon Aizenberg's)
• Impressions from DevOps Con 2013 (Sharon Revah Zitzman)
• DevOpscon website

Productivity vs. Control tradeoffs in PaaS

Gartner published recently an interesting paper: Productivity vs. Control: Cloud Application Platforms Must Split to Win. (The paper requires registration.)

The paper does a pretty good job covering the evolution that is taking place in the PaaS market toward a more open platform and compares between the two main categories: aPaaS (essentially a PaaS running as a service) and CEAP (Cloud Enabled Application Platform) which is the  *P* out of PaaS that gives you the platform to build your own PaaS in private or public cloud.

According to Gartner the main split between the two categories is Productivity vs Control:

The cloud application platform markets are splitting to support two different constituencies: mainstream application developments that are focused on fast time to deployment, and advanced projects requiring the full control of the underlying cloud application platform attributes.

The paper also provides useful takeaways that follow that line of thought:

• The aPaaS market is now dominated by high-productivity offerings targeting mainstream, often opportunistically oriented, rapid application deployments, at times implemented by "citizen developers" without formal IT department approval.
• High-control offerings are emerging to support the most-advanced, systematically oriented requirements. These projects often look primarily for a CEAP, rather than an aPaaS, to enable maximum control over the technology environment.

My take:

While I was reading through the paper I felt that something continued to bother me with this definition, even though I tend to agree with the overall observation. If I follow the logic of this paper than I have to give away productivity to gain control, hmm…  that’s a hard choice.

The issue seem to be with the way we define productivity. Let me explain.

Productivity – redefined

The term "productivity" is pretty wide. Even after a short research on the subject it became clear to me that even today were lacking an agreed-upon model for measuring Programming productivity as noted in the wikipedia definition:

A generally accepted working definition of programmer productivity needs to be established and agreed upon. Appropriate metrics need to established. Productivity needs to be viewed over the lifetime of code. Example: Programmer A writes code in a shorter interval than programmer B but programmer A's code is of lower quality and months later requires additional effort to match the quality of programmer B's code; in such a case, it is fair to claim that programmer B was actually more productive.

During my short research I came across an interesting study on the subject by Google. I thought that the study went a long way toward defining productivity. It does so by taking a a specific challenge (HPC in this specific case) and measured the actual progress students made on developing a certain task at different stages using various technologies.  For example, it measured how much time was spent to develop a certain algorithm, the time it took to debug it, optimize it and get it working.  One of the interesting outcomes of this study that seems to be generally applicable to many other technologies is that we often spend more time debugging and optimizing code than on the actual development. It was also found that the biggest bang for the buck is gained by shortening the transition between the various development cycles and less by reducing the time of each individual cycle. (I’ll get back to that later on in this post.)

Which platform is more productive?

On a question comparing the RoR and Garils platforms on stackoverflow (Is developer productivity higher on Ruby on Rails or Grails?) it became clear that answer to the question is always subjective as it depends on your existing skillset, legacy, framework etc. In other words, there is no clear winner and the answer can be different on a per case basis.  This brings me to the point that its going be hard to claim that one platform is more productive than the other without taking the specific context in mind.

Also see Joseph Ottinger's post, "It's not about C++ and Java performance," which addresses a series of benchmarks people were trying to use to assert than Java was better than C++ and vice versa.

Defining Platform-Productivity

The definition that seem to resonate best for me was provided by Can Wolf on one of his comments on stackoverflow thread above:

Productivity is measured by units of features being delivered (not lines of code).

Can Wolf's comment in brackets is even more interesting. In many of the recent language debate centered around productivity we seem to be zeroing on the number of lines of code required to deliver a given functionality as the main measure for productivity. As I noted in the opening of this section reducing the number of lines of code covers only a narrow aspect of productivity - and not necessarily the best one. 

Measuring the the time it takes to bring new feature from development into production is where I believe we should put the focus when we measure productivity as this is what really matters – by looking at that measure we may find that language choice has actually only a marginal contribution on our overall productivity in comparison to how well we can speed up the time it takes to go through the QA and Production cycles. We may also find that the right choice would actually be to combine different languages for different purposes.

In a case of a PaaS platform that means that a platform that makes it extremely easy to write your own hello-world application wouldn’t be considered productive if it fails to take you effectively through the entire debugging and optimization cycles into production.

Productivity vs. Control tradeoffs in PaaS

I started this post by quoting Gartner on the choices between Productivity and Control when looking into the two main categories in PaaS market.

I thought that Carlos Ble's post Goodbye Google App Engine (GAE) is a good example that illustrate why the initial perception behind GAE as simple platform that provides extreme productivity can be completely wrong.

..developing on GAE introduced such a design complexity that working around it pushes us 5 months behind schedule.

Part of the reason that brought Carlos through that experience IMO is that in the course of trying to make GAE extremely productive the owner made the platform too opinionated to the point where you lose all the potential productivity gains by trying to adopt their model. In addition to that, with a platform like GAE you have very little freedom to leverage existing frameworks such as your own database, or messaging system, or any other third party service that can by itself be a huge contributor to productivity.

Instead, you're completely dependent on the platform provider's stack and pace of development and that in itself can work against agility and productivity in yet another dimension. In this specific example Carlos couldn’t use a certain version of a Python library which would have made his productivity higher and had to work around issues that were already solved elsewhere.  This is a good example how the lack of flexibility lead to poorer productivity even in the case of simple applications.

Amazon PaaS (BeanStalk) vs Google App Engine – Productivity + Control

It's interesting to compare Google App Engine with Amazon Beanstalk. Amazon provides full control over almost every piece of their platform. You could choose your own operating system and integrate with  external database and other services of your choice, etc. At the same time, Amazon provide layers of abstraction on top of their infrastructure through services like RDS, SimpleDB, SQS, MapReduce, and Beanstalk. In addition, to that they have an network of ecosystem PaaS providers such as Heroku, GigaSpaces and others that run on top of their IaaS services and complement their offering.

Open productivity

Amazon's approach is to provide what I would call Open Productivity. It enables you to start with extreme productivity where you would give up some degree of control at the earlier stages. Unlike GAE you're not locked into any of those layers of abstraction and you always have the choice to go another level down and pick your own database of choice, OS framework, etc.

Amazon's approach is pretty much aligned with the approach that we took in GigaSpaces in 2009 when we developed our first generation PaaS, as I noted in this post Google App Engine plus Amazon AWS: Best of both worlds. In other words, you don’t always have to trade extreme productivity for control. If the platform architecture is layered correctly it is possible to get a good degree of productivity and control as in the case of Amazon and GigaSpaces.  Choosing between the degrees of productivity and control becomes a decision of which layer of abstraction to start with and not necessarily which platform to choose from.

Doing it the other way around - i.e. providing closed productivity first - without a good degree of control could lead to high productivity at the beginning but end up with low productivity as the project evolves as noted in Carlos' experience. In addition to that it is often much harder to take a closed productivity platform and open its control levels at a later stage if the platform was not designed for it from the start.

The caveat though is that it often takes more time to start with an open platform and build the layer of abstraction on top. In my view, this leads to a better evolution as you grow with your users and follow their demand rather than the other way around.

Bottom line – It’s not about productivity

After working on this short analysis, I came to the conclusion that since productivity is a broad term it would be wrong to think that our choice is to trade productivity with control when we select aPaaS or CEAP platforms.

To put it simply the main difference between the current class of aPaaS and CEAP is that most aPaaS are targeted toward the long-tail of web applications where CEAP is targeted to the more high end part of the spectrum. 

All of the platform would try to provide extreme productivity for the type of applications that they are targeting.

A better way to make a platform choice would be based on the target applications that each platform is aimed for. For example I would look at GAE for extremely small Java or Payhon applications (widgets) or prototype, Heroku for small Ruby based App, Force for an application that needs to integrate more tightly with the salesforce ecosystem.

I would look for Beanstalk if I’m already running a simple java application and don’t plan to switch off of Amazon anytime soon. I would choose CEAP such as GigaSpaces in cases where I don’t want to be bound to a particular cloud provider and want the flexibility to run the same application on variety of environments private or public with or even without virtualization, In Java or .Net.  The later would fit into most enterprises and the more high end SaaS providers where the first would probably more into end users applications.

Extensibility & Flexibility

One of the attributes of control is extensibility and flexibility. Extensibility and flexibility is another factor worth considering when selecting a platform. As it stands today, the various platforms tend to be quite different in the level of choice that they offer in language, frameworks, and the ability to plug-in your service of choice or using only parts of the platform (database, messaging, ..). As noted earlier in the GAE example, flexibility can actually lead to greater productivity.

What’s next.. toward a 2ndG PaaS

If we follow the evolution of aPaaS and CEAP solutions, we can see a consistent shift toward more open platforms than the one that was available in the first generation PaaS. With the emergence of more open infrastructures in the form of OpenStack, as well as the evolution of enterprise data centers toward hybrid clouds, we can expect even higher degree of flexibility not just on Amazon but on any cloud (private or public). The other thing that comes up often in many of the recent DevOps discussions is the demand to enable similar level of productivity and automation that Amazon (or GigaSpaces for that matter) provides for its own built-in services to external services of my choice.

Gartner's paper does a petty good job covering that shift in the PaaS market but the use of productivity as the differentiating factors can be misleading as I outlined in this paper.

The good news is that they were expected to get much better selection of choices between the various tradeoffs around productivity and control.  I will dive into the details of that in a followup post.

PaaS trend discussion @ Cloud Connect

In this post I tried to lay out my own analysis on this matter. I’m very interested in other people experience on this subject so If this topic is of interest to you and you happened to be in CloudConnect next week I’d be happy if you would drop me an email (natis at gigaspaces dot com) or simply meet me at our CloudConnect booth (106). 

 

 

References

• Productivity vs. Control: Cloud Application Platforms Must Split to Win
• Measuring Programmer Productivity – A scientific study 
• Programming productivity
• Is developer productivity higher on Ruby on Rails or Grails?
• Google App Engine plus Amazon AWS: Best of both worlds.

Need scalability? Don't forget pricing

In most discussions about scalability, we often approach the topic as a pure technical/architecture challenge, and ignore cost issues. The problem is that when we truly scale our application, and want to benefit from economies of scale, we're going to end up with scale limitations, not because of technical issues, but because of the pricing  and licensing models.

Scalable pricing

Scalable pricing means a pricing scheme that provides the benefits of economies of scale. Below are pricing models commonly used for software products and how they fit in the new dynamically-scalable world.

• Free - while this certainly sounds like the best option (and may very well be) the customer needs to be aware of the following:

- The free license of a software product typically does not include support: not an option for most mission critical applications.
- When you do pay extra for support, you will typically be charged just like any other run-time license on a per CPU basis.
- Make sure that the company behind the product has a sustainable business model, otherwise there is a good chance that it will either die when its funding dries up or change its license model to monetize its user base. That's fine, but all it means is that it's not really a free offering in the long run, and you don't know what the pricing model will be exactly.
- In terms of total cost of ownership (TCO), free products are not necessarily the cheapest option. TCO is dependent on many factors, for example, dependency on other products (and their license costs), the need for integration and maintenance, etc. See my post, Economies of non scale, for more on the topic.

• Subscription model - With a subscription model you pay a fixed periodical fee, typically on an annual basis for infrastructure software, and on a monthly basis for SaaS. Subscription pricing is suitable for on-demand scalability as it provides the flexibility to grow or reduce cost based on the annual use of the product.
• Pay per use - this model is even more flexible then subscription model as it gives you higher granularity. Pay per use is provides in various forms where the usage can be a measure of CPU utilization or bandwidth utilization. Amazon for example charge per machine utilization for its EC2 services and data-utilization for its data services.
• Perpetual license - This model is used to buy licenses in advance and pay for support separately (normally 15-20% on top of the per CPU license). This is the most commonly used model with commercial software products, however, due to the large initial investment required by this model, it doesn't fit well with on-demand environment.
• Enterprise unlimited license - This model enables you to pay premium price in advance (based on potential future usage) and gives you the freedom to use the software without any limit. This model fits to environment where you anticipate that over a fairly short period of time the usage of the product will become wide and therefore the pay-per use or any of the other models mentioned above will become more expensive.

Which model to choose?

Each of the models has pros and cons and therefore the answer depends on your situation. Also, over time, as the situation changes, you will probably realize you need a different license model, and so it becomes equally important that the product you choose will give you the freedom to move from one model to another in the future.

GigaSpaces scalable pricing

With GigaSpaces we continuously look into ways to make our software license cost fit the on-demand world. For example, we launched a free Start-Up program that provides a totally FREE version of GigaSpaces for startups (hundreds of start-ups have already signed up for this program since we launched it last year). We also provide a Pay-Per-Use model for those running on Amazon EC2.

We felt that even though this is a fairly flexible pricing, we could do better. As of our 6.6 release, we added the option to buy our software at a yearly subscription price, and we also launched a new package called XAP Standard Edition, which is sold at a very low price of $9,500k per package (not CPU) where the package includes two servers, 4 GigaSpaces nodes and up to 50 clients or remote servers.

These changes were designed to address the needs of developers looking to start running their applications at a relatively low scale, who need the full functionality of the product, but cannot afford the full XAP price. Another principle that we kept when we designed this package is that moving from Standard to Premium edition wouldn't require any change in your architecture or code - which means that you could always scale to the premium edition just by changing the license key.
More details about the new pricing model is available here

Other references:
GigaSpaces and the Economics of Cloud Computing

Economies of Non-Scale

Testability – the orphan child in distributed systems – Part II

In Part I of this post-series I discussed the importance of testability in distributed systems and outlined a set of key principles for addressing the issue.

The truth is that testability is often constrained by the products that we're using. In this post I wanted to outline how we at GigaSpaces address these issue with OpenSpaces, our new Spring-based development infrastructure:

Start with the architecture

There are a few components in OpenSpaces and Space-Based Architecture that significantly simplify the distributed architecture complexity:

Processing-Unit: unifies the deployment, scaling and fail-over behavior semantics of both the middleware and business logic components.

In-Memory Middleware: OpenSpaces takes advantage of the fact that space-based middleware can address both messaging and data using the same underlying technology. That in itself reduces a large part of the complexity, because we reduce the amount of moving parts in our architecture.

The fact that "spaces" can be collocated in-memory reduces the runtime footprint and provides a simple way for running the entire application in a single process environment.

Spring Abstraction – The Spring Framework was primarily designed to address the complexity of J2EE applications. OpenSpaces utilizes and extends many of the principles introduced by Spring, such as dependency injection and separation between the business logic and the underlying implementation through abstraction, remoting, etc. This simplifies the architecture and configuration of an OpenSpaces-based distributed application.

Measure scalability and fail-over as part of the unit-test environment

Because OpenSpaces is a relatively lightweight framework, it is easy to start an entire cluster within a single Eclipse session. This allows to very easily measure the behavior of the application in fail-over and scaling scenarios.

Enable fast iterative development 

The concept of the Processing Unit allows developing all of the business logic in a single VM and running it locally.  Moving it to a cluster, and scaling it, only requires to run that *same* processing-unit multiple times. This makes the production and unit-testing environments pretty much one and the same, and therefore, enables testing 90% of the functionality in a single environment. OpenSpaces helps you to take advantage of that and enable the developer to deploy the application from his or her testing environment to the production system by a click of a button, knowing that it's going to behave the same as in the local environment.

Keep the configuration consistent

In this respect, OpenSpaces provides a standalone container that is tuned to run within an Eclipse environment. Using this approach, a user changes only the container used between the development and production testing environment, while the rest of the code and configuration remains the same.