Tag Archives: Application Server

[product ]the key features and functions of WebSphere Application Server

original:http://www-01.ibm.com/software/webservers/appserv/wasfamily/compare.html

WebSphere Application Server

Compare editions

Download WebSphere Application Server datasheet - Get it now!

IBM® WebSphere® Application Server delivers the secure, scalable, resilient application infrastructure you need for a Service Oriented Architecture (SOA). Compare the available editions to find the one that is right for your company’s needs.

 

Table describes the key features and functions of each WebSphere Application Server configuration, so that you can choose the configuration that best fits your current business strategy—and so that you can be prepared to grow your solution as your needs evolve.

WebSphere Application Server Community Edition V3.0 WebSphere Application Server – Express V8.0 WebSphere Application Server V8.0 WebSphere Application Server Network Deployment V8.0 WebSphere Application Server Hypervisor Edition V7.0 WebSphere Application Server for z/OS® V8.0
Optimized for: Lightweight Java EE 5 application server based on open source Apache Geronimo Lower-cost, ready-to-go solution for smaller scale deployments of dynamic web applications Build, run and manage dynamic web applications on single server or moderately sized deployment environments Advanced management, automated performance optimization and availability for mission critical applications Optimized to instantly run in VMware and other server virtualization environments Takes advantage of the qualities of service of IBM z/OS®
Java EE 6 compliance fully supported fully supported fully supported fully supported fully supported
Java EE 5 compliance fully supported fully supported fully supported fully supported fully supported fully supported
Java Platform, Standard Edition 6 (Java SE 6.0) fully supported fully supported fully supported fully supported fully supported fully supported
Broad programming model choice partially supported fully supported fully supported fully supported fully supported fully supported
Simple failover fully supported fully supported fully supported fully supported fully supported fully supported
Advanced clustering partially supported fully supported fully supported fully supported
Large-scale transaction support fully supported fully supported fully supported
Dynamic caching fully supported fully supported fully supported
Advanced security fully supported fully supported fully supported fully supported fully supported
Runtime provisioning partially supported fully supported fully supported fully supported fully supported fully supported
Administrative Agent, to reduce overhead of administration fully supported fully supported fully supported fully supported fully supported
Job Manager, to enable scalable remote administration fully supported fully supported fully supported
Workload management within a server: integrated with z/OS Workload Manager fully supported
Reporting and chargeback: granular reporting on resource consumption fully supported
WebSphere Application Server Feature Packs partially supported fully supported fully supported fully supported fully supported fully supported
Optimized to instantly run in VMware and other virtualization environments fully supported
Broad operating-system support and database connectivity partially supported fully supported fully supported fully supported fully supported partially supported1
Socket-based pricing option fully supported fully supported
Application assembly and deployment tooling partially supported fully supported fully supported fully supported fully supported fully supported
Open source based fully supported partially supported partially supported partially supported partially supported partially supported
Production-use database fully supported
24×7 product support Available for fee fully supported fully supported fully supported fully supported fully supported

Key: fully supported = fully supported, partially supported = partially supported, blank = not supported
Table 1: Key features and functions of IBM WebSphere Application Server configurations

WebSphere Application Server Community Edition V3.0 WebSphere Application Server – Express V8.0 WebSphere Application Server V8.0 WebSphere Application Server Network Deployment V8.0 WebSphere Application Server Hypervisor Edition V7.0 WebSphere Application Server for z/OS® V8.0
Programming Model Support
Java EE 6 fully supported fully supported fully supported fully supported fully supported
Java EE 5 fully supported fully supported fully supported fully supported fully supported fully supported
Java Platform, Standard Edition 6 (Java SE 6.0) fully supported fully supported fully supported fully supported fully supported fully supported
Web 2.0 and Mobile fully supported fully supported fully supported fully supported fully supported fully supported
OSGi Applications partially supported fully supported fully supported fully supported fully supported fully supported
Java Batch fully supported fully supported fully supported fully supported fully supported
XML fully supported fully supported fully supported fully supported fully supported
Service Component Architecture (SCA) fully supported fully supported fully supported fully supported fully supported
Communications Enabled Applications (CEA) fully supported fully supported fully supported fully supported fully supported
Session Initiation Protocol (SIP) fully supported fully supported fully supported fully supported fully supported
Dynamic Scripting fully supported fully supported fully supported fully supported fully supported
Integrated Tooling Support
Rational Application Developer Standard Edition for WebSphere Software(Trial included) partially supported fully supported fully supported fully supported fully supported fully supported
Rational Application Developer, integrated with Rational Software Architect for WebSphere (separately available) fully supported fully supported fully supported fully supported fully supported fully supported
IBM Assembly and Deploy Tool for WebSphere Administration, built on Eclipse fully supported fully supported fully supported fully supported
IBM Rational® Application Developer assembly and deploy module for WebSphere, built on Eclipse partially supported fully supported

Key: fully supported = fully supported, partially supported = partially supported, blank = not supported
Table 2: Programming Model and Integrated Tooling support by IBM WebSphere Application Server configurations

WebSphere Application Server Community Edition V3.0 WebSphere Application Server – Express V8.0 WebSphere Application Server V8.0 WebSphere Application Server Network Deployment V8.0 WebSphere Application Server Hypervisor Edition V7.0 WebSphere Application Server for z/OS® V8.0
Administration and Performance
Flexible management fully supported fully supported fully supported
Runtime provisioning service partially supported fully supported fully supported fully supported fully supported fully supported
High performance extensible logging (HPEL) fully supported fully supported fully supported fully supported
Enhanced performance features, including edge-of-network services fully supported fully supported fully supported
WebSphere business-level applications, expanding the notion of “application” beyond Java EE fully supported fully supported fully supported fully supported fully supported
Simplified install and maintenance fully supported fully supported fully supported fully supported
Centralized installation and maintenance fully supported fully supported fully supported
Managed directory-based Java EE application install, update and uninstall fully supported fully supported fully supported fully supported
Advanced Security
WebSphere secure proxy fully supported fully supported fully supported
WebSphere security domains fully supported fully supported fully supported fully supported fully supported
Security auditing fully supported fully supported fully supported fully supported fully supported
Kerberos authentication and single sign-on fully supported fully supported fully supported fully supported fully supported
Security Assertion Markup Language (SAML) token support fully supported fully supported fully supported fully supported fully supported
Use of z/OS security environment without affecting the application interface fully supported

Key: fully supported = fully supported, partially supported = partially supported, blank = not supported
Table 3: Administration, Performance and Security support by IBM WebSphere Application Server configurations

[repost ]Jetty vs Tomcat: A Comparative Analysis

original:http://www.webtide.com/choose/jetty.jsp

prepared by Greg Wilkins – May, 2008

1. Introduction

Jetty and Tomcat are often cast as direct competitors. This paper is short comparison of the technical and non-technical aspects of these two open source servlet containers.

2. Technical Comparisons

2.0. Architecture

The view from 20,000 feet is that Tomcat and Jetty are rather similar, they are both java applications servers offering implementations of the 2.5 servlet specification with optional extras giving many JEE features.

However, on closer inspection, the architectures of the two servers differ greatly, mostly because each project as historically had a different focus:

Tomcat is first and foremost an application server. Its default incarnation is as software installed onto a system, into which one can install applications. Tomcat can be stripped down to be embedded or built up the be an full JEE server, but both are difficult exercises. Jetty is first and foremost a set of software components that offer HTTP and servlet services. Jetty can be invoked and installed as a stand alone application server or it can be easily embedded in an application or framework as a HTTP component, as a simple servlet engine, as a feature rich servlet engine or as part of a full JEE environment.

It is the flexible component based architecture of Jetty that allows it to be flexibly deployed and integrated in a diverse range of instances:

  • From mobile phones to large clusters of big iron servers
  • In software frameworks and tools: OSGi Equinox, OSGi Felix, Spring, Plexus, Cocoon, Tapestry, Maven, Continuum, Fisheye, Grails, JRuby, Xbean, etc.
  • In JEE application servers: Geronimo, Jboss, Sybase EAServer, JOnAS and Glassfish
  • Embedded in applications, products and services from IBM, HP, Cisco, BEA, Yahoo, Eclipse (see http://docs.codehaus.org/display/JETTY/Jetty+Powered)
  • As the basis for enhanced services such a SIP (www.cipango.org), Ajax JMS (www.activemq.org), Asynchronous SOA services (Apache Camel)

As the servlet specification continues to grow and add additional features (annotations, automatic web services, etc.) the cost of a standard servlet server is increasing. While Jetty will always continue to support the standard incarnation, its modular approach allows deployments to be targeted at precisely the set of services required without the additional complexities, inefficiencies and security concerns of unused features.

2.1. Performance

Both Jetty and Tomcat offer good request per second performance and for any non-trivial web application it is highly unlikely that either will be the main bottleneck.

General benchmarks are difficult to provide and web load profiles are greatly influenced by the actual application and there is no substitute for specific application benchmarking. However, some generalized observations can be made:

  • Tomcat tends to have slightly better performance when there are few very busy connections. It has a slight advantage in request latency, which is most apparent when many requests/responses are sent over a few connections without any significant idle time.
  • Jetty tends to have better scalability when there are many connections with significant idle time, as is the situation for most web sites. Jetty’s small memory footprint and advance NIO usage allows a larger number of users per unit of available memory. Also the smaller footprint means that less memory and CPU cache is consumed by the servlet container and more cache is available to speed the execution of non-trivial applications.
  • Jetty also has better performance with regards to serving static content, as Jetty is able to use advance memory mapped file buffers combined with NIO gather writes to instruct the operating system to send file content at maximum DMA speed without entering user memory space or the JVM.

2.2. Features

Both Jetty and Tomcat implement the core standard servlet 2.5 specification. Both servers offer a range of EE inspired features such as JNDI, JTA, JMS, Mail servers, etc. Tomcat has an easy migration path for full EE towards Jboss and Geronimo. Jetty has an easy migration path for full EE towards Geronimo, JBoss, JOnAS, Sybase EAServer and, to some extent, Glassfish.

In the last 18 months, there has been an increased focus on web-2.0 features, specifically Ajax Push and Comet. Jetty has been a leader in supporting the web-2.0 use-case from within the servlet model and Webtide has formalized the Jetty approach in a proposal to JSR315 for the Servlet 3.0 that is likely to be accepted as the standard way to provide the asynchronous servlets that are needed by web-2.0. In comparison, the Tomcat project was slow to accept the Web-2.0 use-case, but are now offering an async IO API that does fulfill the requirement. However that approach is not from within the servlet model, so standard frameworks (JSP, Struts, etc) and techniques cannot be used.

3. Non-Technical Comparisons

3.0. Market Share

Selecting the market leader is often used as an important selection criteria. While market share is often a good indication of technical strength, there are often many non-technical and/or historical reasons that may contribute to and devalue market share as a selection criteria -specially in a market heavy influenced by standards.

More over, the dominant market share once held by Tomcat is in decline, while Jetty’s market share has been steadily increasing over the last 18 months to the point where it now has 80% of Tomcat’s market share as reported in the Netcraft server surveys:

Graph of Jetty vs. Tomcat over time

The Netcraft (http://www.netcraft.com) report surveys only measure a fraction of installations as many servers have had their identifies disabled or are hidden behind load balancers or other web servers such as Apache. If installed base is to be considered, then Jetty’s use in many frameworks and tools (e.g. in the Eclipse IDE from 3.3 onwards) would give Jetty a regular usage basis in the millions.

3.1. Reference Implementation

Tomcat was the reference implementation for servlets 2.4 and thus was often selected on that basis. From version 2.5 onwards, Tomcat is no longer the reference implementation. Sun Microsystems forked the Tomcat server to create Glassfish as the reference implementation for servlet 2.5 and servlet 3.0 as well as for JSP 2.1 onwards.

Jetty pays close attention to the specification and faithfully implements it. The Jetty developers were also very active on JSR-154 for servlets 2.5 and now on JSR-315 for servlets 3.0. Thus Jetty not only follows the servlet specification, but is able to influence the ongoing enhancement of the specification and to anticipate upcoming changes.

3.2. Development Community

Jetty enjoys a stable development team and process, and has the same for more than a decade. Jetty has been developed by the same core team since 1995 (using java 0.9) and has been supported by Mort Bay Consulting and now by the partnership between Webtide LLC and Mort Bay. The project lives at the independently minded codehaus.org project repository. The active group of people developing Jetty is of moderate size and of a healthy, friendly and collaborative nature. The extended community in which Jetty has developed includes close collaborations with many other open source projects including Maven, ActiveMQ, Spring, Eclipse, JBoss, Geronimo, etc.

Tomcat has unfortunate history of a fragmented development community that is characterized more by revolution than by collaboration or evolution. The transitions from Tomcat 3 to 4, 4 to 5, 5 to 5.5 and 5.5 to 6 have often resulted in the community splitting or of core developers leaving the project. The governance and development issues of Tomcat have culminated in:

  • The loss of the status as Reference Implementations
  • The forking of the project to Sun’s Glassfish
  • The project has switched from Commit and Review development to Review and Commit.

The upcoming move to Servlet 3.0 is going to require non-trivial enhancements to all servlet servers. Having a unified harmonious, experienced and proven development team and process will be key to the smooth transition to the new specification and the services and features that it will support.

4. Summary

The Tomcat project is a reasonable quality Java application server that has an established brand and large user base. When used for it’s prime role, Tomcat well fulfills the requirements. However it does lack the flexibility as a software component and the capability as a project and community to adapt to changing requirements and new innovative usage.

The Jetty project/team has an attitude and a history of being responsive to innovations and changing requirements. This has resulted in a well architected software platform that has been integrated and deployed in almost every environment and that is supported by a sizable, healthy and growing community.

For more information about Jetty, please check out the official Jetty website at http://jetty.mortbay.org/jetty/.

[repost ]IBM WebSphere Application Server V8发布,完全支持Java EE 6

original:http://www.infoq.com/cn/news/2011/06/was8-released

上周IBM有两个里程碑事件:2011年6月16日是IBM的百年华诞,第2天IBM WebSphere Application Server(WAS)V8发布了,提供了对Java EE 6的完全支持:

  • EJB 3.1
  • Contexts and Dependency Injection for Java(CDI)1.0
  • Bean Validation 1.0
  • JavaServer Faces(JSF)2.0
  • Java Servlet 3.0
  • Java Persistence API(JPA)2.0
  • Java API for RESTful Web Services(JAX-RS)1.1
  • Java API for XML-based Web Services(JAX-WS)2.2
  • Enterprise Web Services 1.3(JSR-109)
  • Java Architecture for XML Binding(JAXB)2.2

除了Java EE 6标准外,WebSphere 8还集成了大量的特性包,之前这些特性包是需要单独安装到WAS V7上的:

  • OSGi应用。模块化框架OSGi已经应用在WebSphere Application Server内部很多年了。在WAS V8中,现有的组件可以在OSGi应用内部导出为SCA组件。这样,OSGi与Web应用就可以在WebSphere Application Server中部署为OSGi bundle了。
  • 基于Apache Tuscany项目的Service Component Architecture(SCA)1.0。
  • Java Batch,提供了一个批处理容器服务,集成了批处理编程模型,同时提供了一些管理功能,如任务定义、任务状态、检查点与重启等等。
  • Communication Enabled Applications(CEA)。CEA编程模型增加了对通信功能的支持,比如单击调用、调用通知及协作浏览等等。
  • XML编程模型的改进,包括对Extensible Stylesheet Language Transformations(XSLT)2.0、XML Path Language(XPath)2.0及XML Query Language(XQuery)1.0的支持。IBM Thin Client for XML可以在WebSphere Application Server中加速那些使用了XSLT 2.0、XPath 2.0及XQuery 1.0的客户端应用的开发速度。

WAS V8拥有两个特性包。“Web 2.0 and mobile”包(WAS V7与6.1也拥有)基于Apache WinkDojo项目。其目标是将WAS的触角延伸到桌面与移动应用上,包括流行的智能手机与平板电脑,比如Apple的iPad与iPhone、运行在Google Android OS上的产品以及RIM的黑莓系列产品。“dynamic scripting”包只能用于V8,借助于该包,PHP与Groovy用户可以在WebSphere环境下编写程序。

IBM在平台系统管理方面的改进下了很大功夫。WAS 8成为该系列中首个运行IBM安装管理器的软件,这样可以简化部署、对于那些需要在不同硬件平台上安装软件的组织来说会起到很大的帮助作用。安装管理器为产品与修复包的安装与卸载、修复包的升级与回滚提供了单一的安装技术。深受用户欢迎的一个功能就是可以一次性安装所需的服务包,这样就无需先安装GA产品,然后再单独安装修复包了。

WAS V8包含了一个Application Migration Tool(AMT),这是在V7时发布的一个工具。AMT会分析源代码以寻找到潜在的迁移问题。

WebSphere是第3个通过认证的完全支持Java EE 6 Profile的应用,紧跟Oracle的GlassFish Open Source Edition 3.x和TmaxSoft的JEUS 7。通过Web Profile认证的产品有JBoss Application Server 6.0、Caucho Resin 4.0及GlassFish Open Source Edition 3.x Web Profile。

WebSphere 8发布感兴趣的读者可以在这里找到更详细的信息。

查看英文原文:IBM WebSphere Application Server Version 8 Released with Full Java EE 6 Support

 

[repost]PaaS shouldn’t be built in Silos

Last year I wrote a post titled Platform as a Service: The Next Generation Application Server? where I was referring to the shift from  application server into platforms.

On my 2011 predictions I referred to a new emerging PaaS category targeted for those who be looking to build their own custom PaaS offering.

The demand coming from many SaaS providers to offer their own platform to their ecosystem players (a good example on that regard is Salesforce force.com) as well as the continues pressure of enterprises on their IT to enable faster deployment of new application and improve the utilization of their existing resources will force those organizations to build their own specialized PaaS offering. This will drive a new category of PaaS platform known as Cloud Enabled Application Platform (CEAP) specifically designed to handle multi-tenancy, scalability, and on-demand provisioning but unlike some of the public PaaS it needs to come with significantly higher degree of flexibility and control.

One of the immediate question that came up in various follow-up  discussion was  “how is that different from the Application Servers of 2000?”

I’ll try to answer that question in this post.

The difference between PaaS and Application Servers

Lori MacVittie wrote an interesting post, “Is PaaS Just Outsourced Application Server Platforms?,” which sparked an interesting set of response on twitter.

Lori summarized the aggregated response to this questions as follows:

PaaS and application server platforms are not the same thing, you technological luddite. PaaS is the cloud and scalable while application server platforms are just years of technology pretending to be more that it is..

Now let me try to expand on that:

The founding concept behind application servers was built around the concept of Three Tier architecture where you break your application into presentation, business-logic and data-tier. It was primarily an evolution of Client/Server architecture, which consists of a rich client connected to centralized database.

The main drive was the internet boom that allowed million of users to connect to the same database. Obviously having million of users connected directly to a database through a rich client couldn’t work. The three-tier approach addressed this challenge by breaking the presentation tier into two parts – a Web Browser and Web Server – and by separating the presentation business logic tier into two separate parts.

In this model, Clients are not connected directly into the database except through a remote server.

Why is PaaS any different?

A good analogy to explain the fundamental difference between existing applications servers and PaaS enablement platform is the comparison between Google Docs vs Microsoft office. Google came up with a strong collaboration experience that made sharing of documents simple. I was willing to sacrifice many of the other features that Office provided just because of the ease of sharing.

The same goes with PaaS – when I think of PaaS I think of built-in scaling, elasticity, efficiency (mostly through Multi Tenancy) and ease of deployment as the first priority and I’m willing to trade many other features just for that.

In other words, when we switched from desktop office to its Google/SaaS version we also changed our expectations from that same service. It wasn’t like we took the same thing that we had in our desktop and put it over the web – we expected something different,.  This brings me to the main topic behind this post:

PaaS shouldn’t be built in Silos

If I take the founding concept of Application Server – i.e. Tier based approach – and try to  stretch it into the PaaS world the things that pops up immediately in my mind is the impedance mismatch between the two concepts.

Tiers are Silos – PaaS is about sharing resources.

Tiers were built for fairly static environment – PaaS is elastic.

Tiers are complex to setup – In PaaS everything is completely automated. Or should be.

Now this is an important observation – even if the individual pieces in your Tier based platform is scalable and easy to deploy the thing that matters is how well they can:

  1. Scale together as one piece,
  2. Dance in an elastic environment as one piece.
  3. Run on the same shared environment without interfering with one another… as one piece through multi-tenancy.

Silos are everywhere ..

In the application server world, every tier in our infrastructure is built as a complete silo. By “silo,” I mean that they are not just built separately, but that each component comes with its own deployment setup, scaling solution, high availability solution, performance tuning and the list goes on…

All that individual deployment and tuning in the context of a single application, well, if you stretch that into multi-tenant application, it becomes much worse.

Silos are not just the components that make our products. Silos are also a feature of those who build the components.

If you think of Oracle Fusion as an example or IBM for that matter you’ll see silos. Messaging, data, analytics, all broken into a separate development group with different management, individual development groups.

Each component has a different set of goals, different timelines, different egos, and in most cases they are even incentivized to keep those silos in place simply since they are not measured on how well their products work with other pieces but solely on how well their thing does its (siloed) job which leads into even greater focus on silos – functionality that works as an end to itself and not a contributor to general application development.

Oracle Fusion is an interesting attempt to break those silos. In the course of creating Fusion, they even came up with an interesting announcements of bringing Hardware and Software together.

Is “bringing hardware and software together” good enough? It’s certainly an attempt but if you look closely you’ll see that most of it is a thin glue that tries to put together pieces that were bought separately through acquisitions and are now packaged together and labeled as one thing.

However most of it is still pretty much the same set of siloed products. (Oracle RAC cluster is still very different than Weblogic cluster, etc.) That doesn’t apply to Oracle only – think of VMware and its recent acquisition now labeled under VFabric.

Now imagine how you can scale together an erlang based messaging system with other pieces of their stack as one piece.. The sad thing about VMware is that it looks like they went and built a new platform targeted specifically for PaaS world but inherited the same pitfalls from the old Tier-based application server world.

Silos are also involved in the process by which we measure new technology.

Time and time again I see where even those who need to pick or build a PaaS stack go through the process of scoring different pieces in the puzzle independently, with different people measuring each piece rather than looking on how much those pieces work together.

A good analogy is comparing Apple with Microsoft: Microsoft would have probably score better on feature by feature comparison (they can put a checkmark in more places) but the thing that brings many people to Apple is how well all of its pieces work together.

Apple even went farther and refused to put in features that might have been great – just because they didn’t fit the overall user experience. They often win with users because of the scarcity of features, even though it may not look as nice on a bullet list of features.

Sharing is everything.

The thing that makes collaboration so easy in the case of Google Docs is the fact that we all share the same application and underlying infrastructure. No more moving parts. No moreincompatible parts.

All previous attempts to synchronize two separate documents through versioning highlighting and many other synchronization tools pale compared to the experience that we get with Google Docs. The reason is that sharing and collaboration in Office was an afterthought. If we work in silos, we’ll end up… in silos. Synchronizing two silos to make them look as one is doomed to fail, even if we use things like revision control systems for our documents.

We learned through the Google docs analogy that sharing of the same application and its underlying infrastructure was a critical enabler to make collaboration simple.

There is no reason that that this lesson wouldn’t apply to our Application Platform as well. Imagine how simple our lives could be if our entire stack could use one common clustering mechanism for managing its scaling and high availability. All of a sudden the amount of moving parts in our application would go down significantly, along with lots of complexity and synchronisation overhead.

We can measure the benefits of having a shared cluster based on the fact that it comes with less moving parts compared with those that are based on Tier based model:

  • Agility – fewer moving parts means that we can produce more features more quickly without worrying if once piece will break another piece.
  • Efficiency – fewer moving parts means that will have less synchronization overhead and network calls associated with the each user transaction.
  • Reliability – fewer moving parts means lower chance for partial failure and more predictability in the system behavior.
  • Scaling –  fewer moving parts means that scaling is going to be significantly simpler, because scaling would be a factor of a “part” designed for that purpose.
  • Cost – fewer moving parts means fewer products, a smaller footprint, less hardware, reduced maintenance cost, even less brainpower dedicated to the application.

First Generation PaaS – Shared platform

If we look at the first generation PaaS platforms such as Heroku, Engine Yard, etc., we see that they did what Oracle Fusion does. They provide a shared platform and carve out a lot of the deployment complexity associated with the deployment of those multi-tiered applications. (This makes is marginally better than Oracle Fusion, but not good enough… certainly not as good as it could or should be.)

I refer to these as “PaaS wrappers”. The approach that most of those early-stage PaaS providers took was to “wrap” the existing tier-based frameworks into a nice and simple package without changing the underlying infrastructure, to provide an extremely simple user experience.

image

This model works well if you are in the business of creating lots of simple and small applications but it fails to fit the needs of the more “real” applications that need scalability, elasticity and so forth. The main reason it was built this way was that it had to rely on an underlying infrastructure that was designed with the static tier-based approach in mind. An interesting testimonial on some of the current PaaS limitations can be found in Carlos Ble’s post, “Goodbye Google App Engine (GAE).”

Toward 2nd Generation PaaS

In 2010, a new class of middleware infrastructure emerged, aimed at solving the impedance mismatch at the infrastructure layer. They were built primarily for a new, elastic world, with NoSQL as the new elastic data-tier, Hadoop for Big data analytics, and the emergence of a new category (DevOps) aimed at simplifying and automating the deployment and provisioning experience.

With all this development, building a PaaS platform in 2011 will – or should – look quite different than those that were built in 2009.

The second-generation PaaS systems would be those who could address real application load and provide full elasticity within the context of a single application.

They need to be designed for continuous deployment from the get-go and allow shorter cycles between development and production.

They should allow changes to the data model and introduction of new features without exposing any downtime.

The second-generation PaaS needs to include built-in support for multi-tenancy but in a way that will enable us to control the various degrees of tradeoffs between Sharing (utilization and cost) and Isolation (Security).

The second-generation PaaS should come with built-in and open DevOps tools that will enable us to gain full automation but without losing control, open enough for customization and allowing us to choose our own OSes and hardware of choice as well as allowing us to install our own set of tools and services, not limited to the services that come out of the box with the platform.

It should also come with fine-grained monitoring that will enable us to track down, trouble-shoot  our system behavior through a single point of access as if the platform was a single machine.

The 2nd generation PaaS systems are not going to rely on virtualization to deliver elasticity and scaling but instead provide a fine grain level control to enable more efficient scaling.

At Structure 2010, Maritz said that “clouds at the infrastructure layer are the new hardware.” The unit of cloud scaling today is the virtual server. When you go to Amazon’s EC2 you buy capacity by the virtual server instance hour. This will change in the next phase of the evolution of cloud computing. We are already starting to see the early signs of this transformation with Google App Engine, which has automatic scaling built in, and Heroku with its notion of dynos and workers as the units of scalability.

Final words

Unlike many of the existing Platforms, in this second-generation phase, its not going to be enough to package and bundle different individual middleware services and products (Web Containers, Messaging, Data, Monitoring, Automation and Control, Provisioning) and brand them under the same name to make them look as one. (Fusion? Fabric? A rose is a rose by any other name – and in this case, it’s not a rose.)

The second-generation PaaS needs to come with a holistic approach that couples all those things together and provide a complete holistic experience. By that I mean that if I add a machine into cluster, I need to see that as an increase in capacity on my entire application stack, the monitoring system needs to discover that new machine and start monitoring it without any configuration setup, the load-balancer need to add it to its pool and so forth.

Our challenge as technologists would be to move from our current siloed comfort zone. That applies not just to the way we design our application architecture but to the way we build our development teams, and the way we evaluate new technologies. Those who are going to be successful are those who are going to design and measure how well all their technology pieces work together before anything else, and who look at a solution without reverence for past designs.

References

Written by Nati Shalom and Joseph Ottinger

original:

http://natishalom.typepad.com/nati_shaloms_blog/2011/01/paas-shouldnt-be-built-in-silos.html