Subscribe: Paul Fremantle's Blog
Added By: Feedage Forager Feedage Grade A rated
Language: English
based  carbon  cloud native  cloud  esb  google  log  message  model  paas  platform  server  service  stratos  wso esb  wso 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Paul Fremantle's Blog

Paul Fremantle's Blog

SOA, Cloud, Web Services, Synapse, Tin Whistles, Blacksmithing and me

Updated: 2018-03-20T06:10:10.997-07:00




Inspired by #FirstSevenLanguages here is a complete list (apart from the one's I've forgotten).

Z80 / 6502 / 8086 Asm

LISP / Scheme
Lotus 123 script
Batch/Shell scripts (DOS, OS/2, Bash)
Visual Basic 
Pascal / Delphi
SAS Language
CAML Light
Synapse ESB Language

(edited to include the last three which I'd forgotten)

OAuth2 Introspection with WSO2 ESB and WSO2 Identity Server


If any of you are following the GNU Terry Pratchett discussion on Reddit, BBC or the Telegraph, then you might be wondering how to do this in the WSO2 ESB or Apache Synapse. Its very very simple. Here you go. Enjoy.
Loading ....

Understanding Logging in the Cloud


I recently read an interesting pair of articles about Application Logging in OpenShift. While these are great articles on how to use log4j and Apache Commons Logging, they don't address the cloud logging issue at all.What is the cloud logging issue?Suppose I have an application I want to deploy in the cloud. I also want to automatically elastically scale this app. In fact I'm hoping that this app will succeed - and then I'm going to want to deploy it in different geos. I'm using EC2 for starters, but I might need to move it later. Ok, so that sounds a bit YAGNI. Let's cut back the requirements. I'm running my app in the cloud, on a single server in a single geo.I do not want to log to the local filesystem.Why not? Well firstly if this is say EC2, then the server might get terminated and I'm going to lose my logs. If it doesn't get restarted then they are going to grow and kill my local filesystem. Either way, I'm in a mess.I need to log my logs somewhere that is:1) designed to support getting logs from multiple places - e.g. whichever EC2 or other instance my server happens to be hosted today2) separate from my worker instance so when that gets stopped and started it lives3) supports proper log rotation, etcIf I have this then it supports my initial problem, but it actually also supports my bigger requirements around autoscaling and geos.Stratos is an open source Platform-as-a-Service foundation that we've created at WSO2. In Stratos we had to deal with this early on because we support elastic auto-scaling by default.In Stratos 1.x we built a model based on syslog-ng. Basically we used log4j for applications to log. So just as any normal log4j logging you would do something like:Logger logger = Logger.getLogger("org.fremantle.myApp");logger.warn("This is a warning");We automatically setup the log appenders in the Stratos services to use the log4j syslog appender. When we start an instance we automatically set it up under the covers to pipe the syslog output to syslog-ng. Then we automatically collate these logs and make them available.In Stratos 2.x we have improved this.The syslog-ng model is not as efficient as we needed, and also we needed a better way of slicing and dicing the resulting log files.In the Stratos PaaS we also have another key requirement - multi-tenancy. We have lots of instances of servers, some of which are one instance per tenant/domain, and some which are shared between tenants. In both cases we need to split out the logs so that each tenant only sees their own logs.So in Stratos 2.x (due in the next couple of months) we have a simple Apache Thrift interface (and a JSON/REST one too). We already have a log4j target that pushes to this. So exactly the same code as above works in Stratos 2.x with no changes. We are also going to add models for non-Java (e.g. syslog, log4php, etc).Now what happens next? The local agent on the cloud instance is setup automatically to publish to the local central log server. This takes the logs and publishes them to an Apache Cassandra database. We then run Apache Hive scripts that slice the logs per tenant and per application. These are then available to the user via our web interface and also via simple network calls. Why this model? This is really scalable. I mean really, really scalable. Cassandra can scale to hundreds of nodes, if necessary. Also its really fast. Our benchmarks show that we can write >10k entries/second on a normal server.SummaryLogging in the cloud isn't just about logging to your local disk. That is not a robust or scalable answer. Logging to the cloud needs a proper cloud logging model. In Stratos we have built one. You can use it from Java today and from Stratos 2.0 we are adding support to publish log entries just with a simple REST interface, or a super-fast highly scalable approach with Apache Thrift.[...]

Synapse and WSO2 ESB myths


There are a few myths about Synapse and the WSO2 ESB I'd like to address. Its amazing they still come up.Not an ESB?The first and oldest myth is that Synapse is not an ESB. This dates back to the initial creation of the project - before there was even any code! Dave Chappell was at Sonic at the time and he said "This project is related to ESB , but it is not in itself an ESB".Well, firstly, since at that time Sonic was the ESB leader, he would say that! Secondly, this was purely theoretical - no code had been written at that point. While I love the internet's ability to archive everything for years, to quote this several years later (like the ServiceMix guys do here: is disingenuous to say the least.The fact is that Synapse - both as a pure Apache project and when packaged as the runtime engine of the WSO2 ESB is an ESB. Rather than argue about the definition of an ESB, it would be simpler to describe a few of the many usecases it is in production for:* Getting the latest trades from a legacy financial system and reporting them to third-parties to meet regulatory requirements.* Linking an SAP/R3 system with a .NET-based Point-of-Sale (POS) system in 40+ retails stores to distribute the latest price updates.* Integrating between BMC Remedy, Salesforce and Peoplesoft.* Providing a full SOA bus for a telecom operator linking to provide a common fabric for payment services, SMS top up and other integrations.* Lightweight Service Orchestration (what we call Service Chaining) - providing simple non-persistent flows across multiple services.* Integrating FIX messaging to existing systems.* etc etcIn addition, the beauty of the Synapse ESB (and WSO2 ESB) is that it can also provide very high performance lightweight routing, load-balancing, failover and security management, so it is often used for high throughput scenarios as well - for example at eBay where it handles well over 1bn request/response interactions/day.Synapse (and WSO2 ESB) only support SOAP or translate every message into SOAPThis is also a complete myth. The WSO2 ESB has a very effective model for dealing with content that only parses the content as needed. This model is based on the concept of a message formatter and builder. These objects handle the internal representation of content and are very flexible. For example, the normal approach to handling non-XML data is to keep it as a binary stream. In addition, a new transport in the WSO2 ESB (the Passthru transport) supports even higher performance routing of messages where the message body is simply passed from one HTTP endpoint to the next, while still supporting useful functions like header-based routing, authentication and authorization, logging, throttling and cacheing.For XML data, we have an internal model that unifies SOAP and non-SOAP. What this means is that for non-SOAP payloads, there are two extra objects in memory that represent the envelope and body. This makes it very easy (and performant) to handle scenarios like taking the SOAP body and publishing it (without the SOAP wrapper) onto a JMS queue. Because the XML object model we use (Apache Axiom) supports streaming (via StAX), the message is only built into a tree if a mediator such as the XSLT transform requests it.I think this is where the mistaken belief lies. This is a bit like Heisenberg's Uncertainty Principle! The act of observing a quantum level action affects the action. Similarly, if you examine the message, then if you ask for it as SOAP, we will build it into a SOAP message and give it to you. Of course that doesn't mean it was a SOAP message until you asked for it as SOAP. If you were to ask for the message as pure XML then you would get it as a pure XML element. In both cases it remains as a binary stream until the point you ask for the message. If you simply route the message out to another system, it will not have been converted to or from anything:  Sy[...]

Understanding ESB Performance & Benchmarking


ESB performance is a hot (and disputed topic). In this post I don't want to talk about different vendors or different benchmarks. I'm simply trying to help people understand some of the general aspects of benchmarking ESBs and what to look out for in the results.The general ESB model is that you have some service consumer, an ESB in the middle and a service provider (target service) that the ESB is calling. To benchmark this, you usually have a load driver client, an ESB, and a dummy service.+-------------+      +---------+      +---------------+| Load Driver |------|   ESB   |------| Dummy Service |+-------------+      +---------+      +---------------+Firstly, we want the Load Driver (LD), the ESB and the Dummy Service (DS) to be on different hardware. Why? Because we want to understand the ESB performance, not the performance of the DS or LD.The second thing to be aware of is that the performance results are completely dependent on the hardware, memory, network, etc used. So never compare different results from different hardware.Now there are three things we could look at:A) Same LD, same DS, different vendors ESBs doing the same thing (e.g. content-based routing)B) Same LD, same DS, different ESB configs for the same ESB, doing different things (e.g. static routing vs content-based routing)C) Going via ESB compared to going Direct (e.g. LD--->DS without ESB)Each of these provides useful data but each also needs to be understood.MetricsBefore looking at the scenarios, lets look at how to measure the performance. The two metrics that are always a starting point in any benchmark of an ESB here are the throughput (requests/second) and the latency (how long each request takes). With latency we can consider overall latency - the time taken for a completed request observed at the LD, and the ESB latency, which is the time taken by the message in the ESB. The ESB latency can be hard to work out. A well designed ESB will already be sending bytes to the DS before its finished reading the bytes the LD has sent it. This is called pipelining. Some ESBs attempt to measure the ESB latency inside the ESB using clever calculations. Alternatively scenario C (comparing via ESB vs Direct) can give an idea of ESB Latency. But before we look at the metrics we need to understand the load driver.There are two different models to doing Load Driving:1) Do a realistic load test based on your requirements. For example if you know you want to support up to 50 concurrent clients each making a call every 5 seconds on average, you can simulate this.2) Saturation! Have a large number of clients, each making a call as soon as the last one finishes.The first one is aimed at testing what the ESB does before its fully CPU loaded. In other words, if you are looking to see the effect of adding an ESB, or the comparison of one ESB to another under realistic load, then #1 is the right approach. In this approach, looking at throughput may not be useful, because all the different approaches have similar results. If I'm only putting in 300 requests a sec on a modern system, I'm likely to see 300 request a sec. Nothing exciting. But the latency is revealing here. If one ESB responds in less time than another ESB thats a very good sign, because with the same DS the average time per request is very telling.On the other hand the saturation test is where the throughput is interesting. Before you look at the throughput though, check three things:1) Is the LD CPU running close to 100%?2) Is the DS CPU running close to 100%?3) Is the network bandwidth running close to 100%?If any of these are true, you aren't doing a good test of the ESB throughput. Because if you are looking at throughput then you want the ESB to be the bottleneck. If something else is the bottleneck then the ESB is not providing its max throughput and you aren't giving it a fair chance. For this reason, most bench[...]

Carbon's 3rd Birthday


Three years ago I blogged about WSO2 Carbon for the first time. I enthused about a composable server architecture and why it was important for a SOA platform.

At that point there were just 4 Carbon products. Today there are 13 products, the core framework, Stratos, and Carbon Studio all based around the Carbon Architecture.

There are two really important things I think have worked really well:

  • The composability is obviously important and we now have a set of customers doing exactly that - using p2 to combine the correct components and effectively "build your own server" with the right function for their specific needs and requirements.

    But even more interesting for those customers has been the consistency and completeness of the platform that has arisen out of Carbon. The fact that there is a "menu" or palette of low-level components (features) and high level components (products) that all interoperate, behave the same, use the same identity, clustering, registry, key management, etc has really offered customers the opportunity to build out compelling architectures.
  • The kernelization is almost just a corollary of componentization: as you build the components and identify which ones to re-use, we found a common core across those 13 products. The result is that when we came to address cloud - starting later in 2009 - we very quickly realized that there were just a few core places in which to address multi-tenancy, elasticity and metering. I have to admit this was something I for one hadn't thought of, but has been probably the most powerful driver behind the success of StratosLive and Stratos. 
There were certainly people then who doubted that OSGi was a stable basis for an ESB or Server and I hope that the 1bn+ transactions a day that eBay are doing through WSO2 ESB are enough to disprove that.

All in all, it is amazing to see how far Carbon has come and what it has enabled in 3 years.

WSO2 Workshops in Europe


If any of you are interested in Identity, Security and Entitlement and how these fit into a SOA, Cloud and Enterprise Architectures, then I'd recommend you taking a look at our workshop that we are running in London, Paris, Zurich and Frankfurt.

PS I think I'm meant to be the one on the left with St. George's flag!



Introduction to WSO2 Message Broker


Introduction to WSO2 Message BrokerIntroductionWSO2 Message Broker (MB) is a new Open Source project and product from WSO2 that provides messaging functionality within the WSO2 Carbon platform and to other clients in various languages. It works either standalone or in conjunction with products and components such as the WSO2 ESB and WSO2 Complex Event Processing Server. MB is based on the Apache Qpid/Java project ( From Apache Qpid, MB gets core support for the AMQP protocol and JMS API. On top of that WSO2 has added support for Amazon SQS APIs and WS-Eventing support.Understanding how the MB broker fits into Enterprise ArchitectureThe Message Broker provides three main capabilities into an overall Enterprise Architecture:·               A queueing/persistent message facility·               An event distribution (pub/sub) model·               An intermediary where multiple systems can connect irrespective of the direction of messages.To give some concrete examples of these benefits, here are some scenarios:1)   In the WSO2 ESB, a common pattern is to persist the message from an incoming HTTP request into a persistent message queue, and then process onbound from there. MB can provide the persistent queue.2)   The WSO2 ESB already has an event distribution model and eventing support, but the QPid-based broker provides higher performance as well as supporting the JMS API.3)   For example, you may wish to send messages from outside a firewall to a server inside. You could connect an ESB or Service Host within the firewall to a Message Broker running outside the firewall (for example on Amazon EC2). This model is used by the WSO2 Cloud Services Gateway.Where does AMQP fit?AMQP ( is an open protocol for messaging. Whilst the AMQP protocol is still under development, it has released three stable releases (0-8, 0-9-1, and 0-10), with a 1.0 due during 2011. There are a number of implementations of the AMQP standard in production, including Apache Qpid (both Java and C++ versions), RabbitMQ, OpenAMQ and others.WSO2 has been a member of the AMQP working group for several years, and we strongly support AMQP as the way to introduce interoperability and greater openness into the messaging space.The Qpid broker supports a variety of clients on top of the AMQP protocol. The most useful of these for Carbon is the Java JMS 1.1 API, which provides a portable API as well as the main interface with the WSO2 ESB. In addition there are C# and other APIs. WSO2 MB also extends these with WS-Eventing and Amazon SQS APIs for interoperability using HTTP, REST and SOAP.Installing the WSO2 MBYou can download the WSO2 MB Beta from: you have downloaded and unzipped, simply switch to the install directory            cd wso2mb-1.0.0-SNAPSHOT            bin\wso2server.bat  [ON WINDOWS]            bin/ [ON LINUX/MACOSX]Let’s refer to the install directory as from now on.You should see the server startup:[2011-03-16 14:00:12,471]  INFO {org.wso2.carbon.server.Main} -  Initializing system...[2011-03-16 14:00:12,840]  INFO {org.wso2.carbon.server.TomcatCarbonWebappDeployer} -  Deployed Carbon webapp: StandardEngine[Tomcat].StandardHost[defaulthost].StandardContext[/][2011-03-16 14:00:14,147]  INFO {org.wso2.carbon.atomikos.TransactionFactory} -  Starting Atomikos Transaction Manager 3.7.0[2011-[...]

SPDY - 90% of all Gmail Traffic via Chrome/HTTPS


Anyone watching the SPDY-DEV group will have heard something pretty amazing today. SPDY is a proposed alternative to HTTP from Google. It was launched in November 2009 and has been chugging along making progress ever since, but frankly without much further buzz.

Today, Google admitted on the mailing list that 90% of all Gmail and other Google services go via SPDY when the client is Chrome and SSL is used:
Yes, indeed SPDY is enabled in Chrome and on Google servers for all SSL
traffic at this point.  (Actually, we do 90% on SPDY, with a 10% holdback
for purposes of A/B comparisons).
This is pretty damn significant real world usage.

Elastic Beanstalk - a PaaS fairytale


A while back, I blogged about what it means to be Cloud Native. One of the key issues is multi-tenancy. As I discussed in that blog, there is a huge cost benefit in resources to multi-tenancy. This is how we can afford to run and offer multi-tenant Tomcat currently for free beta use.

Today Amazon announced Elastic Beanstalk. They call it a PaaS. Unfortunately Elastic Beanstalk is only multi-tenant at the VM layer - in other words it is fundamentally IaaS not PaaS. In other words you don't get the true benefit of PaaS: every Beanstalk user has to pay for at least one EC2 instance. Amazon tries to put this in a nice light:
Each of your Elastic Beanstalk applications will be run on one or more EC2 instances that are provisioned just for your application. 
WSO2 Stratos is designed to share the cost of the infrastructure fairly. In other words we will be charging for CPU, Bandwidth and Disk space, not for just having an app sitting waiting for requests.

Effectively Beanstalk is a nice pre-packaged runtime with some good tooling. I have no doubt it is a major improvement over the existing model and from the look of it the tooling is pretty slick. But calling it a PaaS is simply a fairytale.

Wikileaks and Governance


Whether or not you support the leaking of 250,000 embassy cables to the now infamous Wikileaks website, it certainly makes you think. Whatever business you are in there always emails or data that would be embarrassing or more likely harmful to our business if they were made widely available. So what is the lesson to be learnt from the Cablegate affair.

The blame for the issue seems to be landing on a certain US private Bradley Manning. But I place the blame directly on a lack of Governance and poor IT systems. And the measures that have so far been announced - things like removing CD drives from classified systems - are simply the wrong approach. The real problem is why any one person - whatever level of clearance they had - should have access to all 250,000 cables.

Without going into the details of XACML and policy-based entitlement models, suffice it to say that the right approach is to base access not only on the person, but the reason they have for accessing the data. Using policy-based entitlement, it is possible to have a well-defined Governance model where a person is given access to just the right data at just the right time for just the right purpose, and that this can be managed in a process-driven, auditable and controlled manner.

If you live in a crime area and you leave your door open, you will be burgled. If you don't put in place good security and data governance, then it is you that will be blamed, not just the guy who steals your data.

And if you want the technical low-down on XACML, start here, here and here.

Using OSGi as the core of a middleware platform


Ross Mason of Mulesoft recently blogged: "OSGi - no thanks". Ross is a smart guy and he usually has something interesting to say. In this case, I think Ross has made a lot of good points:

1. Ross is right - OSGi is a great technology for middleware vendors.
2. Ross is right - Developers shouldn't be forced to mess with OSGi.
3. Ross is wrong - You can make both of these work together.

At WSO2 we went through exactly the same issues. We simply came to a different conclusion - that we can provide the benefits of OSGi (modularity, pluggability, dynamic loading) without giving pain to end-users. In WSO2 Carbon, customers can deploy their systems in exactly the same way that worked pre-OSGi.

Why did we choose OSGi? We also looked at building our own dynamic loading schemes. In fact, we've had dynamic classloading capabilities in our platform from day one. The reasons we went with OSGi are:
  • A structured and versioned approach to dynamic classloading
  • An industry standard approach - hence better understood, better skills, better resources
  • It solves more than just dynamic loading: as well as providing versions and dynamic loading, it also really gives proper modularity - which means hiding classes as much as exposing classes.
  • It provides (through Equinox p2) a proper provisioning model.
It wasn't easy. We struggled with OSGi to start with, but in the end we have a much stronger solution than if we had built our own. And we have done some great improvements. Our new Carbon Studio tooling gives a simple model to build complete end-to-end applications and hides OSGi completely from the end-user. The web admin consoles and deployment models allow complete deployment with zero OSGi. Drop a JAR in and we take care of the OSGi bundling for you.

The result - the best of both worlds - ease of use for developers and great middleware.

Building Cloud Native Software


This is my presentation from ApacheCon. I hope you enjoy it.



I spent the weekend making a lyre. The rough design was to create a seven string pentatonic lyre out of a solid elm plank. In order to create more soundboard area, we carved away a slanting hole through the wood to create two overlapping soundboards.

Its tuned DEGBADE. I'll try and post a sound sample once I've learnt to play something on it!

Taking College loyalty a bit far?


A few weekends ago I was at the Balliol College family day and they had a face painter. I got her to do a large college arms on my face, which came out quite well! Thanks to Jeremy for the picture.

WSO2 Stratos - Platform-as-a-Service for private and public cloud


Yesterday we announced something I believe is a game-changer: WSO2 Stratos. What is Stratos? WSO2 Stratos is a complete SOA and developer platform offered as a self-service, multi-tenant, elastic runtime for private and public cloud infrastructures.What that means is that our complete SOA platform - now enhanced with Tomcat and Webapp support - is available as a  "cloud native" runtime that you can either use on the Web (yes - you can try it out right now), on Amazon VPC, or on your own internal private cloud based on Ubuntu Enterprise Cloud, Eucalyptus and (coming soon) vmWare vSphere. It is a complete Platform-as-a-Service for private and public clouds.I'll be writing more about Stratos over the coming weeks and months, and I'll also provide links and tweets to other Stratos blogs, but in this blog I want to simply answer three questions:I'm already talking to {vmWare, Eucalyptus, Ubuntu, Savvis, Joyent} about private cloud - what does WSO2 add that they don't have?What is the difference between Stratos and the Cloud Images that WSO2 already ships?Why would I choose WSO2 over the other vendors offering Platform-as-a-Service? In order to answer the first question, lets look at the cloud computing space, which is most easily divided up into:Infrastructure-as-a-Service (IaaS): this is where Amazon, Eucalyptus, vmWare, Saavis and Joyent play Platform-as-a-Service (PaaS): Google App Engine, vmForce, Tibco Silver and now WSO2 Stratos play in this space.Software-as-a-Service (SaaS): Google Apps, Google Mail, Microsoft Office Live, Salesforce, SugarOnDemand - these and many more make up the SaaS category.To generalize wildly, most people talking about public cloud today are talking about SaaS. And most people talking about private cloud today are talking about IaaS.SaaS is fantastic for quick productivity and low cost. WSO2 uses Google Apps, Sugar on Demand and several other SaaS apps. But SaaS doesn't create competitive advantage. Mule also uses Google Apps. They may well use Salesforce. SaaS cannot produce competitive advantage because your competitors get access to exactly the same low-cost services you do. In order to create competitive advantage you need to build as well as buy. For example, we use our Mashup Server together with our Sugar Business Messaging Adapter to provide insight and management of our pipeline that goes beyond what Sugar offers.IaaS is of course a great basis to build apps. But it's just infrastructure. Yes - you get your VM hosted quicker. But someone has to create a useful VM. And that is where PaaS comes in. PaaS is how to speed up cloud development.What does Stratos give you on top of an IaaS? It gives you an Application Server, Registry, Identity Server, Portal, ESB, Business Activity Monitor and Mashup Server. And it gives you these as-a-Service: completely self-service, elasticly scalable, and granularly metered and monitored. Someone in your team needs an ESB - they can provision one for themselves instantly. And because it's multi-tenant, it costs nothing to run until it gets used. How do you know how it's used? The metering and monitoring tells you exactly how much each tenant uses. 2. What is the difference between Stratos and the existing WSO2 Cloud Images?The cloud images we started shipping in December are not Cloud Native. Stratos is Cloud Native. In practice, this means that when you log into Stratos (go on try it now) you can instantly provision your own domain, together with a set of Stratos services. This saves memory - instead of allocating a new VM and minimum half a gigabyte of memory to each new server you get a new ESB with zero extra memory c[...]

Cloud Native


Together with Sanjiva and the rest of the WSO2 architecture team, I've been thinking a lot about what it means for applications and middleware to work well in a cloud environment - on top of an Infrastructure-as-a-Service such as Amazon EC2, Eucalyptus, or Ubuntu Enterprise Cloud.One of our team - Lavi - has a great analogy. Think of a 6-lane freeway/motorway/autobahn as the infrastructure. Before the autobahn existed there were forms of transport optimized first to dirt tracks and then to simple tarmac roads. The horse-drawn cart is optimized to a dirt track. On an autobahn it works - but it doesn't go any faster than on a dirt track. A Ford Model T can go faster, but it can't go safely at autobahn speeds: even if it could accelerate to 100mph it won't steer well enough at that speed or brake quickly enough.Similarly, existing applications taken and run in a cloud environment may not fully utilize that environment. Even if systems can be clustered they may not be able to dynamically change the cluster size (elasticity). Its not just acceleration, but braking as well! We believe there are a set of these technical attributes that software needs to take account of to work well in a cloud environment. In other words - what do middleware and applications have to do to be Cloud Native.Here are the attributes that we think are the core of "Cloud Native":Distributed / dynamically wiredIn order for an application to work in a cloud environment the system must be inherently distributed by nature to support operating in a cloud. What does this mean? It must be able to have multiple nodes running concurrently that share a configuration and share any session state, as well as logging to a central log, not just dumping log files onto a local disk. Another way of putting this is that it is clusterable. There are different degrees of this: from systems that cluster up to tens of machines all the way to shared-nothing architectures that cluster to thousands or millions of nodes. Of course its not enough to think of a single application here either. Cloud applications are not just going to be written in a single language on a single platform in a single runtime. The result is that applications are going to have to be dynamically wired: not just able to find their session state and logger but also able to find the latest version of a remote service and use it, without being restarted, and without any limits to where that service has moved to. ElasticIf a system is distributed then it can be made to be elastic. This seems to be the attribute of cloud native that everyone thinks of first. The system should be able to scale down as well as up, based on load. The cluster has to be dynamic and a controller must be using policies to decide when to scale up and when to scale down. In order to be elastic, the controller needs to understand the underlying Infrastructure-as-a-Service (IaaS) and be able to call APIs to start and stop machine images. Multi-tenant A cloud native application or middleware needs to be able to support multiple isolated tenants within the system. This is the ability of Software-as-a-Service to handle multiple departments or companies at once. This compares to running multiple copies of an application each in a Virtual Machine (VM). There are two main reasons why multi-tenancy is much better than just VMs. The first benefit is economics: a tenant has a minor overhead (usually just a row in a database). A whole VM is costly: [...]

Platform-as-a-Service freedom or lock-in


There has been a set of discussions about lock-in around Platform-as-a-Service (PaaS): Joe McKendrick and Lori MacVittie in particular bring out some of the real challenges here.

Lori brings out the difference between portability and mobility. While I'm not in 100% agreement with Lori's definitions, there is a key point here: its not just code, its the services that the code relies on that buy lock-in into a cloud.

So for example, if you use Amazon SQS, Chatter Collaboration, Google App Engine's bigtable data store, all of these tie you into the cloud you are deployed onto. Amazon isn't really a PaaS yet, so the tie-in is minimal, but Google App Engine (GAE) is based on Authentication, Logging, Data, Cache and other core services. Its almost impossible to imagine building an app without these, and they all tie you into GAE. Similarly, VMForce relies on a set of services from

But its not just about mobility between and Google: between two PaaSes. The typical enterprise needs a private cloud as much as public cloud. So there is a bigger question:
Can you move your application from a private PaaS to a public Paas and back again?
In other words, even if Google and Force got together and defined a mobility layer, can I then take an app I built and run it internally? Neither Google nor Force is offering a private PaaS.

The second key question is this:
How can I leverage standard Enterprise Architecture in a PaaS?
What I'm getting at here is that as the world starts to implement PaaS, does this fit with existing models? and Google App Engine have effectively designed their own world view. VMForce and the recent Spring/Google App Engine announcement address one aspect of that - what Lori calls portability. By using Spring as an application model, there is at least a passing similarity to current programming models in Enterprises. But Enterprise Architectures are not just about Java code: what about an ESB? What about a Business Process engine (BPMS)? What about a standard XACML-based entitlement engine? So far PaaS has generally only addressed the most basic requirements of Enterprise core services: databases and a identity model.

So my contention is this: you need a PaaS that supports the same core services that a modern Enterprise architecture has: ESB, BPMS, Authentication/Authorization, Portal, Data, Cache, etc. And you need a PaaS that works inside your organization as well as in a public Cloud. And if you really don't want any lock-in.... hadn't that PaaS better be Open Source as well? And yes, this is a hint of things coming very soon!