Nati Shalom's Blog

Is Your Data Really Secured?

Security has always been one of those topics that we as developers or architects hate to deal with. Our ideal world would be that security is dealt with at some higher level in our data-center, and that we don't need to think about it. It turns out that some of the most recent frauds can be caused by someone from within our own organization. In this specific fraud case, the cost to SocGen was $7.7b.  There was nothing specific in this incident that was a direct result of an application security failure, but it does force us to examine more carefully some of the current assumptions about security. In this post I focus on some of the potential security vulnerability that we may be exposed to as a result of using data-grid and caching more and more within our organization. 

Why Do We Need a Secured Data-Grid?

We add the data-grid/caching layer as a front end to the database to address the database scalability limitation. One of the common assumptions in this sort of model, is that the caching layer is an embedded part of a particular application. In other words, the caching layer can only be accessed by a specific application. Based on that assumption, it is fair to assume that it is the application's responsibility from a security perspective, to control access to its caching layer. Therefore, security was not generally considered to be a critical aspect of many of the existing caching solutions.

However, there are two things that change that assumption:

• Caching becomes a shared service (just like databases of today), that is shared by more than one application. SOA-based applications are a good example of this. SaaS-based applications impose an even bigger challenge in this regard.
• Virtualization and the drive for better utilization, forces us to think of a more efficient deployment model through sharing of resources. Having a dedicated in-memory cluster per application can be a fairly inefficient model, but on the other hand, running in a shared environment requires a high degree of isolation support by the data-grid service.

Security assumptions and constraints change significantly when you move from a cluster dedicated to one application, to a cluster shared between several applications. It is no longer enough to assume that the application is responsible for granting access to its embedded middleware components. In this case, multiple applications which share the same data, must have the right level of isolation and access. Securing the shared middleware resources is the key to achieving this level of isolation and control.

In the next section I describe the specific attributes that a secured data-grid must support.

Securing Your Shared Data-Grid/Caching Layer

1. Granting Access Based on Roles and Content

Imagine the following cases:

• Several applications can access the same data-grid service, and be granted different permissions to view each data item, based on the content of the data.
• Different parts of the same application (e.g. purchasing module vs. sales module) may be granted access to different accounts, even though all the account data is stored in the same shared data-grid.
• One part of an application can be granted read/write access, while another part of an application can be granted read-only access to the same data.

This scenario is very similar to what we expect from most databases today. A user can be granted access (authentication) through user-name/password authentication, and they can be granted read/write access (authorization) to the shared data. Providing such a level of control is fairly basic and core to any secured data-grid. However, there are cases where we would want to grant access to different parts of organizations, or where customers need to have different privileges for different parts of the shared data. For example, in a call center application, we might have a shared call center service that serves different departments in our organization. In such a case, we would want callers of certain departments to see only the contacts that belong to them, and not be granted privileges to see or have access to contacts that belong to other departments. In that case we would need to provide fine-grained authorization, based on the actual content.

2. Ensuring Isolation in a Multi–Tenant Environment

There are many cases where we do not want to share the same data-grid between different groups of applications, but at the same time we do want to share the physical memory resources. A multi-tenant environment implies that we run multiple services or applications in a shared environment, but keep them logically separated, as if they were running in their own dedicated environment. That level of separation is referred to as isolation. In order to do that, we need an abstraction layer that enables us to provision our data-grid as a set of fine-grained services that can be managed independently, even if they run on the same process. Abstracting the data-grid as fine-grained services enables us to provision the data-grid services on a shared group of machines or even processes (JVM’s), and still manage them completely independently.

There are a few components that enable that level of fine-grained isolation:

• Life cycle management – each data-grid can be started or relocated, completely independently of other data-grid services, even if they run on the same process container.
• Class-loader  - each data grid contains its own class-loader to ensure that there is no class version conflict between two data-grid services.

In addition to that, there are other levels of isolation, such as ‘zones’ where we can ensure that certain data-grid services never share the same process or even the same machine. At the top level, we can assign a data-grid with specific virtual machines (VM), which ensures the highest level of isolation, not just at the service level, but also at the operating and physical resources level.

Providing this level of fine-grained isolation control between data-grid services that share the same process, up to a completely separate data-grid that runs on its own virtual machine, is critical if we want to ensure best utilization on the one hand, and isolation on the other hand. Providing a limited degree of isolation determines how effectively we can share resources.

3. Transport Level Security

In most data-grid deployment, it is fair to assume that network level security is a responsibility of the data-center, not the data-grid, or even the application. There are cases where the data-grid can span across multiple firewall or data-center zones, and have a replication channel between those zones. In such cases, the replication channel can turn out to be a security loophole. The simplest approach to address this challenge, is enable replication over SSL. Using SSL can ensure that no one can “sniff” the packets that go over the wire.

The Administrative Challenge

Providing all this level of fine-grained security control and multi-tenancy can pose a huge administrative challenge. For example:

1. A super administrator needs to have full access to all data-grid services

2. An application administrator only needs to be granted access to data-grid services that belong to a particular application.

3. Operational managers need to be granted monitoring (read-only) access, to view how the system is behaving, but don't need to be granted access to change the data-grid topology or configuration.

These are only few of the challenges that we have to deal with, once we move from a dedicated data-grid to a shared data-grid. This basically means that we can’t assume that all administration operations to our data-grid are the same.  We need to treat operation guys differently then we deal with application managers, and they all need to have visibility and some level of control to our shared services. That means that we have to rethink how to manage security when we deal with shared data-grid services.

Not Just Your Data..

The same arguments that I have mentioned here, apply not just to the data-grid, but to any part of the application middleware that is going to become a shared resource. For example, think of the messaging service, or any other part of your application that becomes a service to other applications. This implies that we need some sort of generic way to handle application security that is consistent across the layers of the application.

How Security Reduces Costs

Being able to share data-grid services between multiple applications is a great cost saver. Here is how:

1. Better utilization  - we can better utilize the machines that run our data. In other words, we reduce the total number of machines that run our data services. The fact that we use less machines to run our data-grid services means that can save all of the cost associated with it i.e. cooling, maintanance, space etc.

2. Pooling of spare resources – each data–grid needs to run some level of spare capacity. Sharing of data-grid services enables us to share that spare capacity, and therefore better utilize it amongst different applications.

3. Reduction of the amount of redundant data – one of the ways that organizations dealt with the lack of ability to share their data services effectively, was by maintaining different copies of that same data. That led to redundant copies, as well as a lot of synchronization cost associated with it. Being able to safely share the data, means that we remove a lot of that overhead, and the cost associated with it.

4. Reduced administrative overhead – the data-grid becomes just like a data-base: instead of having each application group learn how to provision it separately, and go through the cycles of tuning and sizing it separately, we now have all that knowledge and skill set managed by a shared group. This is the same way in which Amazon manages its SimpleDB, SQS and other services - we as users of those services don’t need to worry about how to provision or maintain it.

Final Words

Caching/data-grids are going through a similar evolution to databases. As with databases, we started by using caching as an embedded service to the application. Now we are in the phase where we need to be able to share the data between multiple applications, or in cases where we don’t want to share the data, we need to be able to share the resources for managing the data, while keeping a high degree of isolation. The demand for these sort of requirements becomes much more common with SOA or SaaS-based applications.

We used to think of security as a defensive move. However, security is not just about protecting our data – security can create the right level of isolation that is a main enabler for achieving better efficiency and cost savings, through sharing of resources, as I pointed out above.

As we approach the next generation of middleware and data-centers, it becomes clear that we cannot move to the next wave of virtualization and cloud computing without a strong security and isolation solution that is built-in to all layers of our application and middleware.

GigaSpaces Security as a Reference for a Secured Data-Grid:

If you are interested to learn how these challenges have been addressed specifically by GigaSpaces, you are welcome to join a technical webinar that we will be conducting on that subject. The webinar will take place on Wednesday, October 28, 2009 9:00 AM - 10:00 AM PDT

GigaSpaces and GoGrid: Cloud Platform for Enterprise Applications

I had few discussions in the past week with people who asked me about our recent GoGrid announcement and how our cloud offering integrates with the GoGrid environment. I’ll try to answer the most frequently asked questions below. In addition, we’re conducting a webinar where you can ask your specific questions online and watch a live demo – see details at the bottom of this post.

What is the GigaSpaces cloud offering?

GigaSpaces provides a set of cloud-enabled middleware services, namely data grid, messaging and Map/Reduce. These are equivalent to the Amazon SimpleDB, SQS and Map/Reduce, with the the main difference being that it’s implemented entirely in-memory and designed to support existing enterprise applications. On top of that GigaSpaces provides integration of those services into a Platform as a Service solution designed to make the deployment of JEE/Spring or XAP-based applications extremely simple.

What makes it enterprise ready?

Most enterprise applications are based on standard JEE or .Net platforms.  In addition, all enterprise applications are transactional in nature and cannot tolerate any potential inconsistency. Enterprise applications are more sensitive to performance and latency. Our cloud-enabled middleware supports all these requirements. It was designed to leverage memory resources to gain the best performance and latency, and supports large-scale deployments from the get-go. It is based on XAP, which is a mature product with hundreds of deployments in the most mission-critical applications.

What makes your middleware cloud-enabled?

GigaSpaces supports all the key characteristics expected from cloud-enabled middleware, as defined by Gartner below:

How is it different than traditional middleware?

With GigaSpaces all middleware services run on a shared pool of resources. GigaSpaces provides a high level of security to ensure complete isolation between multiple applications. The deployment, provisioning and monitoring is completely automated.

Can your middleware seamlessly shrink and grow dynamically when a machine joins or leave the network?

Yes – let me explain:

There are three components that makes our middleware elastic and thus suitable for a dynamic environment:

1. Service automation and administration – this part takes care of moving the middleware and application services around based on machine, memory, and CPU utilization.
2. Common clustering and state management – this part makes sure that nothing breaks when you start to move around any of the applications or middleware services.
3. API Facade – this part provides a standard interface as well as language binding, for seamless access from existing applications.

What does the integration with GoGrid include?

The integration includes the ability to use any of the middleware services (data-grid, messaging and Map/Reduce), either individually or integrated with our PaaS solution.

Can I use it if I'm not running on GigaSpaces XAP?

Yes. Users can leverage the GigaSpaces images to get deployment automation and improved management for their existing application, as well as add auto scaling and high availability. 

What is unique about the GoGrid cloud offering?

For GigaSpaces users, the main things that you’ll find useful in the GoGrid environment are as follows:

• Enable custom deployment – GoGrid enables enterprise users to customize their environment to fit their specific enterprise standard. This include VPN, network as well as machine hardware configuration if required.
• Native multicast support – makes cluster deployment simple.
• Standard database storage support – makes database high availability simple.

For GigaSpaces windows/.Net users, you’ll find the following useful:

• Built-in .Net support
• Support for Windows and SQL Server 2008
• GoGrid have the same pricing for 64/32 bit

When can I try the GoGrid integration?

The GigaSpaces/GoGrid solution is currently available for limited set of users. Public availability is expected within a month. If you’re interested in early access, or want to be notified when the images will be publicly available, please send an email to <cloud at gigaspaces dot com>.

Is there a live demonstration?

To see a live demonstration, you should register to the Enterprise-Grade Cloud Platform with XAP and GoGrid webinar that will take place on October 14 at 9:00 AM PDT.

The Word is Out on GigaSpaces XAP 7.0

GigaSpaces XAP 7.0 was released in mid-July. For those who missed the buzz, in this post I’ll try to provide a summary of the main perspectives that were voiced about the new release. At the end of this post is a list of additional articles and sources for those interested.

Gartner – cloud-enabled XTP, greater appeal to mainstream enterprises

Massimo Pezzini from Gartner wrote a detailed review, GigaSpaces Focuses on Cloud-Enabled XTP With XAP 7.0, where he covered the main points of the release as follows:

Version 7 introduces several technical improvements aimed at better supporting cloud deployments, including:

• Full service-level-agreement-driven autoscaling of the platform — now extended to a Java EE Web container (currently Jetty, though others will be added)
• New administration application programming interfaces, extending the XAP management tooling, that enable integration with third-party monitoring environments and make it possible for XAP applications to “automanage” themselves (for example, triggering a new virtual machine in a cloud environment to increase processing capacity)
• Significant performance improvement and a simplified programming model for multicore processor environments
• Metadata-driven, multitenancy support for cloud deployments
• Improved integration with the Amazon Elastic Compute Cloud (EC2)

GigaSpaces' progressive and well-established support for popular standards like Spring and parts of Java EE is already helping lower users’ concerns about use of an “unusual” platform. More user support will likely come from the planned adoption of OSGi Alliance standards in future versions. The full integration of Jetty is a notable new marketing proposition that can appeal to mainstream enterprises looking for ways to non-intrusively scale up and down Java ServerPages/Servlet applications. This paves the way for more strategic adoption of XAP full capabilities in these accounts. The core DCP, the cloud deployment options and the new multitenancy capabilities are likely to appeal to independent software vendors, system integrators (SIs) and leading-edge organizations looking for new technology opportunities for business diversification.

Wall Street & Technology Journal – private clouds, commodity hardware, faster time to market

Penny Crosman from the Wall Street & Technology Journal provided a fairly detailed overview on who is using GigaSpaces XAP on wall street:

Wall Street clients are using XAP to create private clouds, allowing applications to share resources. One firm is using it for applications that support real-time portfolio analysis of profit and loss. Another is using an XAP-powered private cloud for a reconciliation service; prior to XAP, each application at this firm had a dedicated infrastructure. To prepare for peaks and lows, they had to provision many hardware units. Today, two applications share the same infrastructure, and the firm is creating infrastructure as a service.

A market data distributor is planning to go live with XAP 7.0 in August to provide certain online services. The company will use XAP to better allocate resources and better scale and integrate the web tier of applications.

One big financial organization had a high-end hardware infrastructure that cost over $1 million per year in annual maintenance. The company switched to XAP, invested $300,000 in commodity hardware, and achieved an annual savings of $946,000 in hardware maintenance alone, because of the fact that they're running on simple commodity hardware, according to Bar Sadeh.

Another big financial service organization estimated the cost to redesign a customer support application using open source tools at $425,000, just for development time and resources. "They didn't bother to add the expenses of memory and hardware because this cost estimate already exceeded what they would have to pay for XAP," Bar Sadeh recalls. The firm also estimated a nine-month effort for the project, however, using the GigaSpaces software it took four months, she says.

DZone interview – all the patterns you need to build scalable applications, working out-of-the-box on a single platform

I had numerous interviews describing the new release. I’d like to point out the one that was published on Dzone specifically: 

XAP 7.0 offers all the patterns you need to build scalable applications in a simple and cost-effective way – based on lessons learned from our demanding enterprise customers and from the new generation of Internet services such as Google, Amazon and Twitter. These patterns include asynchronous even-driven design, partitioning/shards, parallel execution and Map/Reduce, consistency without distributed transactions, and moving the database to the background while persisting all data with 100% reliability and consistency (more details on all of these in my blog). XAP 7.0 offers all these patterns working out-of-the box, on a single platform, without forcing the user to shop around for different packages and point solutions, figure out how to glue them together, and take the risk that the weakest link in this complex chain will break the entire application.

You can read the full story here

eBay Marplaats.nl – map/reduce for simple aggregated search, massive hardware savings

This was followed by joint webinar with Cees de Groot, Lead Architect of eBay Marktplaats.nl; I'll probably cover the Markplaats project in more detail in a future post. Cees discussed how they used the patterns I mentioned above to scale their hugely popular classifieds site (over 6.4 million unique visitors per month) and how he used patterns like Map/Reduce to execute a simple aggregated search. Cees also mentioned why they ended up choosing GigaSpaces over Terracotta. He discussed their challenges with their current PHP application and how they where able to take a gradual approach to overcome those challenges with XAP. One of the interesting outcomes of this process is the fact that they were able to reduce the number of servers in their data center by at least 65%, through the use of XAP’s in-memory clustering and by employing a combination of advanced scalability patterns.

I highly recommend listening to Cees talk – even as someone who was closely familiar with this project, I find that I learn a thing or two every time that I hear him discuss it (Cees’s talk starts 20 minutes into the session).

Shay Bannon and Uri Cohen – distributed autowiring, custom SLAs, multi-core performance boost

I would also recommend looking into Shay Banon's blog post, Distributed Autowiring with GigaSpaces Executors, where he provides a good technical overview of Map/Reduce, a common pattern for executing complex aggregated queries, made famous by Google and used in many other scenarios, including social networking sites.

Banon also provides a good technical overview, together with Uri Cohen, of a real-life usage scenario of Map/Reduce, in a webinar which took place last week. The webinar also covers other areas of the release, such as the new administration API and how it helps users write their own SLA.

I can't help but show a slide from the webinar presentation, which shows the performance improvement we've achieved in a multi-core environment. I'm really proud of this. Here it is:

Summary and future Road map

As a summary, I'd like to quote Massimo from Gartner, who concluded his review of the 7.0 release as follows:

Other vendors, including Oracle and IBM, plan to extend their DCPs with OSGi, Spring and Java EE elements. But none has yet architected a full cloud-enabled XTPP like GigaSpaces. This gives the company at least a year's competitive advantage on the technology front.

In future releases, we plan to continue in the same direction, bringing the value of virtualization and cloud computing to our enterprise users. This will include better support for data center integration, extended integration with production monitoring, built-in SLA and deployment automation, and of course, additional improvements to our In-Memory Data Grid in terms of performance and resource utilization. At the same time, we'll continue our efforts to make the product simpler and reduce the learning curve, by adding more support for standard APIs like JPA. Stay tuned…

References cited above, and a few others

• Release Notes - What's New in GigaSpaces 7.0.0

• GigaSpaces Focuses on Cloud-Enabled XTP With XAP 7.0 (Gartner)

• GigaSpaces Unveils Cloud-Oriented App Server (Wall Street & Technology)

• Nati Shalom talks about XAP 7.0 (DZone)

• Hyper-Scale Cloud Apps with GigaSpaces XAP (CloudBzz)

• How the New XAP 7.0 Admin API Helped Us Troubleshoot Burning Issues (blog by Kobi Kisos, our QA team leader)

• UI & Manageability Improvements in XAP 7.0 (blog by Uri Cohen)

• Distributed Autowiring with GigaSpaces Executors (blog by Shay Bannon)

• GigaSpaces XAP 7, The “Real Option” for the Cloud and On-Premise (blog by James Liddle)

• GigaSpaces 7.0 Release (blog by Guy Nirpaz)

Platform as a Service: The Next Generation Application Server?

Platform as a Service is a term that can be fairly confusing for many people. Normally the term is associated with Google App Engine from Google and Force.com from Salesforce.com as the main references for this model. From a technical point of view, it is aimed to provide a similar type of value to the one that is currently provided by many of the application servers i.e. it provides a generic container that can host different applications and shield them from the details of the underlying operating system, network, database implementation. Unlike most of the existing application servers it was designed for massive scaling from day one. Another big difference is in the way it is being consumed. With PaaS you don’t need to install any software and go through all the hoops to setup a cluster environment etc. PaaS is provided as a hosted service that is pre-configured and installed. You get a production ready environment right at the start.

Key Characteristics of a Cloud/SaaS Enabled Application Platform

Last week I came across David Mitchel Smith presentation from Gartner. David provided a good definition to the main PaaS characteristics. A snippet from his presentation covering this area is given below:

What’s interesting is the great emphasize on Multitenancy support. The fact that the platform is going to be shared between multiple applications and potentially even different customers require various levels of tenancy support and isolation to ensure that even though were taking advantage of the fact that we can share resources between applications, each application needs to be able to use the platform as if it is running on its own dedicated resources. Another interesting point is the need for XTP support. Many would view XTP as a niche that is normally referenced in the high end part of the market, so it is fair to ask why would XTP fit into a general PaaS solution?  XTP represents a model for supporting enterprise transaction processing applications in an extremely scalable environment. In our case, scalability is not necessarily driven from the demand of a particular application but from the fact that many applications are going to run on a shared environment.  A PaaS targeted to enterprise applications would need to provide support for this level of scalable transaction processing support as a core service.

Can you run your existing business applications with GAE or Force.com?

No. Unfortunately as in anything in life reality can really spoil the party.

Force.com was designed to make it simple to run business applications that are database centric i.e. CRM, Reporting etc. It provides a rich set of high level services that make building such applications extremely simple. Google provides a more generic application platform and recently announced support for Java which is a big step towards reducing vendor lock-in concerns.  Google seems to be geared for consumer based applications. Force.com offers a more high level platform that is based on its proprietary services. This means that in order to take advantage of their service you will need to go through a complete re-write.

Force.com is based on a database centric architecture. They also seem to be limited in scalability as they partition their database per application. This means that if your application needs to scale more than what a single database can provide, you can find yourself pretty much locked.

Google's recent support for Java makes their offering closer to standard JEE application servers, however their current support impose a lot of limitations due to their sandbox model. These limitations mean that at the end of the day GAE can be applicable only to a small set of relatively simple applications.  Since there is no guarantee or control over the resources that you are going to receive from their underlying infrastructure, it is likely that the application performance will be unpredictable and will therefore be affected by other applications that are sharing the same hardware.

The fact that the platform as a service shields you from the details of the underlying infrastructure is what makes it simple and that is both the advantage and limitation. You can’t control the environment, you can’t choose your operating system, you can’t install your own set of services and you can’t control the performance characteristics of this platform.

This puts a huge adoption barrier for most current enterprises.

IaaS vs PaaS

Infrastructure as a Service provider provides a hosted service model that offers plain machine level access. This model is also known as Server as a Service. The fact that you get access to the bare metal allows you to run almost any application on this hosted environment. Unlike PaaS, IaaS gives you extreme flexibility. You can choose your own operating system, install any package that you want, you can setup your firewall, security etc. Amazon is known to be the leader in this space and also provides  a set of services on top of their infrastructure such as SimpleDB, SQS and MapReduce. Having said all that, this flexibility comes at the cost of complexity. In many cases you will need to install your own software, configure it, tune it etc. before you could make it run effectively on the cloud. Many application developers don’t have the skill-set to do that. This exposes many operational challenges as many organizations are not geared to support this type of environment from their own IT. The high level services provided by Amazon are still proprietary and would require a complete re-write if you plan to use such services.

PaaS for Enterprise applications – doing it right

The ideal solution would be to combine the best of the two worlds i.e. the flexibility of IaaS and simplicity of PaaS, and here is how:

• Build a Generic PaaS on top of AWS – To build a PaaS we don’t need to re-invent the wheel. Unlike Google and Force.com we don’t need to own the infrastructure, we can actually use Amazon infrastructure or even better build our PaaS such that it can be portable between Amazon IaaS and a VMware IaaS. By doing so, the PaaS can provide us the ability to deploy applications in a simple way just as in GAE but would still enable us to control the environment, install our own software and get the full flexibility that IaaS provides.
• JEE as first class citizen – Many of the existing enterprise applications are built in JEE. Making JEE a first class citizen within our PaaS environment will enable you to leverage the existing skill-sets within those organizations. Similar to the standard model that has more than one implementation out there, reducing the lock-in factor significantly.
• Pre-configured for extreme scalability – All the services provided through the PaaS will need to be implemented and pre-configured for extreme scaling and come with a production ready setup to enable dynamic scaling and fault-tolerance.

Next generation application Server?

Yes, In my opinion, PaaS represents the next wave in middleware technology. One that is targeted for virtualized enterprises, one that was designed for scale-out from the get go, one that fits the new way of delivering SaaS applications and one that can be extremely simple to use. The current PaaS players i.e Google and Salesforce and to a lesser degree Microsoft represent one type of player, those that own it all, i.e. the infrastructure and the platform. There is already a new emerging category of players in the PaaS market, Application PaaS players. Application PaaS players would specialize on delivering only the platform and not the hardware and network infrastructure. They act as the bridge that will enable portability between different infrastructure providers including the internal IT (a.k.a private-cloud). The application PaaS players will also be segmented in similar ways to the way application servers are segmented today, i.e there would be the one targeting the low-end consumer market in similar ways to Google App Engine, the ones that will be aimed toward the high end of the market and those who will be specialized in certain languages or development framework, i.e. Ruby/ Java/ .Net etc. In the PaaS type of world, those who would be able to provide a holistic solution that works smoothly across all the application tiers would have an advantage over those who are providing point solutions.

What about my existing applications ?

Most people would categories PaaS as a platform that is delivered through the internet. That statement would make the idea behind PaaS irrelevant for a large part of the existing enterprise applications, as a majority of them are not ready to run their application in a hosted service over the internet. Let’s examine that statement:

Many of the existing IT run farms of application servers in their internal IT. Those application servers are running in an internal data center that is not that different from any other hosted services, only that it is a specialized hosted service tailored for the needs of the specific organization. I would therefore argue that those organizations that are already running such application server farms would find it easier to evolve such server farms to PaaS model than to change their entire IT infrastructure into internal cloud. The reason is that those applications were already written to run in an application container model, therefore a large part of the transition work can be done within the container implementation and outside the application code. Targeting them first would therefore be potentially easier transition than trying to transform all your other applications into a virtualized environment.

I know that there are many people out there that would argue that internal PaaS is not a PaaS because it doesn’t answer the exact definition of PaaS. However in my view the similarities exceed the differences and the value to the enterprise would be almost identical to the one that I would receive by any of the internet based PaaS platform.

Will I lose control?

PaaS will provide the internal IT much better control over the applications that are running on their environment. You can have high visibility as to ways the application consume resources. In the same way, you can control fairly tightly the application security, scalability, resource management and fault-tolerance which can finally be managed in a consistent way across all the applications.

Final words

Platform as a Service represent the next generation application server IMO. GAE and Force.com are most known references in the market for that model. Both tries to offer the complete stack and that’s both their advantage and limitation. There already is a new category of Application PaaS providers that specialize on providing PaaS on top of existing infrastructure providers. There would be generic PaaS providers (similar to GAE) geared for the low end part of the market and those that are geared for the high end of the market. There would also be more vertical PaaS providers (Similar to Force.com)  i.e. those that will provide PaaS for a certain segment of applications or segment of the market such as Online Gaming PaaS, Telco PaaS etc. A good example for such a service is Twilio. As I outlined in my recent post (Google App Engine plus Amazon AWS: Best of both worlds), this is not just a theory but a reality in the making. GigaSpaces' contribution to this new reality is our new cloud framework on Amazon EC2. Geva Perry provides an excellent overview of other good examples that follows that same line his post What's Really Exciting About Cloud Computing.

References:

• Google App Engine plus Amazon AWS: Best of both worlds
• Waiting to see if App Engine or an alternative gets there first
• What's Really Exciting About Cloud Computing.
• JavaSpaces and the Next Big Thing
• Space-Based Architecture for AppEngine
• GigaSpaces as Alternative to GoogleAppEngine for the Enterprise
• GigaSpaces introduces portable PaaS
• Google Brings App Engine's Pros and Cons to Java
• Google App Engine and The Java Web; The Wrong Java?

Google App Engine plus Amazon AWS: Best of both worlds

George Lawton wrote a a good summary of my JavaOne talk in his article titled Google App Engine plus Amazon AWS: Best of both worlds 

Google App Engine (GAE) is focused on making development easy, but limits your options. Amazon Web Services is focused on making development flexible, but complicates the development process. Real enterprise applications require both of these paradigms to achieve success… What we really want is the flexibility and performance of AWS and the simplicity and ease of use of GAE.

This is exactly what we had been working on for the past year, leading us to the launch of our new cloud platform. With this platform we leverage GigaSpaces XAP as the high performance scale-out application server and Amazon as the robust and flexible IaaS. Together they form an alternative Platform as a Service geared for enterprise grade applications. This allows the cloud environment to inherit the extreme performance, latency and scalability of the XAP platform, which in turn enables achieving your performance and scaling target with less machines, implying a lower cost.

Real-life case study: Primatics financial – Risk analysis as a service

Francis de la Cruz and Argyn Kuketayev from Primatics Financial joined me through the presentation. In their part of the session they described their experience in developing a SaaS application for Real Time analytics.

Kuketayev described how Primatics used this approach to create a new automatically scaling cloud version of an existing banking application. Primatics initially developed a mortgage securities application that allows banks to estimate the value of a basket of hundreds of thousands of loans. The value of these loans fluctuates as economic conditions change and some portion of home owners cannot afford to make payments on their loans. Banks normally only need to assess the value of these loans at the end of each month, making them an ideal candidate for cloud services like AWS.

From a scalability perspective the challenge is to be able to provide a highly multi-tenant application that need to serve many firms, many users in that same firm each running many jobs at the same time. Implementing such a model can be fairly complex as you will need to be able to manage the life cycle of each job and each user independently and in isolation from one another.

 

Trying to build such a service directly on Amazon is going to be fairly complex, as you can learn from George’s summary below:

Primatics wrote the first version of EVOLV:Risk as a hosted web application for a regional bank.. The application needed to be fault tolerant so that if one node crashed, they did not have to restart the application over again from the beginning. Kuketayev said that it is not just about the loss of four hours, but the office is trying to close out the month and needs to access data to end the monthly cycle so they can go home.

Using GigaSpaces' toolset they rewrote the entire application infrastructure in about four-months to run on top of AWS. Now they can kick off as many instances as required for different banking customers, and each instance runs significantly faster than before. Kuketayev said that it is important for banks that none of their applications run on the same infrastructure as another bank.

The diagram below shows the specific architecture that Primatics ended up using. Those that are familiar with Space Based Architecture would find it fairly straight forward:

The application is built out of  a set of processing units. Each processing unit contains the compute agents in the form of a polling-container.  The compute agents gets a a reference to a remote Data Grid that is shared by all processing units. Each agent gets the job injected to it by the polling container and gets a reference to the data it required to process the job. Once the job is completed, the result is stored back in the space. The results are flashed out back to a database through a mirror service.

In a case of a failure, other compute agents are able to continue from the exact point of failure and continue the job processing as if nothing happened. This is because the state of the job is kept safe in the data-grid and not in the agent’s memory.

Kuketayev from Primatics nicely summarized thye lesson he learned after going through the experience of trying to build it on his own vs. trying to use GigaSpaces:

Kuketayev said that one of the biggest lessons is that you need to have your infrastructure do the provisioning for you automatically, or otherwise you end up spending a lot of time just turning things on and off. He said they are now using configuration APIs to automate this process, whereas before they were using scripts. This allow for automatically throttling and failover recovery without human intervention.

Kuketayev advised "You need to make sure you use the right tools … You don't want to have to worry about provisioning and reliability. Make sure you have provisioning, failover, monitoring and SLA out of the box."

The full JavaOne presentation is available here:

Alternative to Google App Engine on Amazon

View more OpenOffice presentations from Nati Shalom.

Final words

Fr solution providers the size of Primatics, building a risk analysis application as a service couldn’t be possible without cloud computing. Cloud enabled them to offer their solution as a service without the need to go through major investment of building a data center to support it.

Primatics’ experience is not special. One of the benefits of building Software as a Service is that you have one shared environment for all your customers. At the same time, one of the challenges is that in a shared environment, failure becomes more public and will impact ALL your clients. If the system doesn’t scale well, you’re going to be hit twice as hard as in a standalone application.

Building a robust and scalable SaaS application can be fairly complex. A good cloud infrastructure will get you a first class data center, but it won’t solve your application requirements.What’s interesting with cloud computing is that it forces you to think about the cost and efficiency of your application more than ever before. In the Primatics example, running a simulation of 100 nodes for 3 hours is very likely to fail at some point. A failure during such a simulation will immediately cost you 300 hours, not to mention the fact that you might lose the simulation window for the day and the reputation challenge you’ll will be facing with your customers. In addition, putting the data in-memory and making the application run 3-5 times faster means that you would need 1/5 of the machine power, which saves 80% of the cost of running the application.

I believe that the challenges imposed by cloud computing force us to focus on what we do best and avoid investing in areas which are not core to our business. Because the pay-per-use model significantly lowers the cost barrier, going down the path of writing your own infrastructure, as many have tried to do before, will be much more expensive and risky then ever before.

References:

• Google App Engine plus Amazon AWS: Best of both worlds 
• The Need for Speed - Saving Costs By Improving Application Efficiency
• eBay Subsidiary Uses XAP to Boost Performance - Expects to Meet Same Loads with 95% Less Servers
• The impact of cloud computing on build vs. buy behavior