There’s a saying that goes something like: to err is human, to really screw up big time takes a computer. But if you really want to have some fun, connect that computer to another computer, and you soon have a veritable nuclear chain reaction. The key to unlocking this energy? The lowly API, a programmer’s best friend, the little enabler that placed Google Maps in the center of mashup mania, drove the Ajax revolution, and is now generating over half of SalesForce.com’s revenues.
You may have read about our mountain trek, new release cycle, and the increased pace of delivering. We’ve climbed our first mountain and we’re happy to announce the availability of our first release in our trek: Andes! This delivers major usability improvements around our platform, new connectivity to applications such as Marketo and ZenDesk, and expanded API management capabilities. We’ll summarize what’s new for you here and we’ll be doing deeper dives over the coming days for you to learn more.
In a recent post, James outlined how MuleSoft is using Lean Startup principles to build Enterprise Software. We have been doing this for a while in our cloud platforms – CloudHub, Anypoint Service Registry and Dataloader.io; however, our core enterprise tools and products – Mule ESB, Mule Studio, Anypoint DataMapper, and Mule Management Console have always been on a much longer release cadence. Mule ESB Enterprise is the core platform on which many of our customers build hundreds if not thousands of services and integration processes on, so frequent releases and updates can be expensive for them to consume. Typically we release new Mule ESB enterprise versions every 9 months. As a hybrid product company with multiple products, we need to manage the demands of both the cloud and on-premise. Recently, we decided to make some changes to our development cycles and team orientation. We’re using names of famous mountain ranges for these new releases, the first is named Andes after the iconic mountain range in South America (relatively) close to our development labs in Buenos Aires, Argentina. The next is Big Horn, Cascade and then Dolomite.
There is a lot of talk about the lean startup and whether it works or not. Some proclaim it is critical to the success of any startup and that it is even the DNA of any modern startup. Others claim that it’s unproven, unscientific and gets your product to market in a haphazard way that is ungrounded in quality.
But the lean startup model, when you boil it down, simply says that when you launch any new business or product you do so based on validated learning, experimentation and frequent releases which allow you to measure and gain valuable customer feedback. In other words, build fast, release often, measure, learn and repeat.
Working with JPA managed entities in Mule applications can be difficult. Since the JPA session is not propagated between message processors, transformers are typically needed to produce an entity from a message’s payload, pass it to a component for processing, then serialize it back to an un-proxied representation for further processing.
Transactions have been complicated too. Its difficult to coordinate a transaction between multiple components that are operating with JPA entity payloads. Finally the lack of support for JPA queries makes it difficult to load objects without working with raw SQL and the JDBC transport.
In the new enterprise, the “one big database” paradigm is being progressively eroded as it becomes more apparent that the ACID qualities of traditional SQL databases are not always needed, and can actually get in the way of massive scalability. In order to respond to the imperative of cloud deployments, new data stores have emerged.
One of them is Riak, a highly-available, fault-tolerant and scalable distributed key-value store built by Basho Technologies, Inc. on the design principles laid out in the famous Amazon Dynamo paper. One of the key features of Riak is that it “embraces failure” in the sense that, instead of sweeping under the carpet the problematic scenarios (like net-splits), it provides developers with the tools needed to deal with these issues as part of the normal operation mode instead of a leaving them to a (seldom addressed) failure mode. As such, data in Riak is said to be “eventually consistent” because it is only when all the pending replications have been done and the related conflicts have been resolved that data is consistent.
The new Riak Connector for Mule allows you to interact with this data store from your Mule applications, opening the door to new integration scenarios. Let’s review an example of such a scenario.
Eclipse users have always felt at home in Mule Studio, but users have often asked for Studio to “play well with others” — specifically, that it support plugin-style installation into existing Eclipse environments they already use every day.
With Mule Studio 3.4, we have delivered this wish list item. Specifically, users of Eclipse 3.8 can now install Mule Studio as plugins into their existing environments.
The old-fashioned way to do this is via the Eclipse Update Manager, using the update site http://studio.mulesoft.org/3.4/plugin:
After creating a basic Mule App, you might be wondering how to automate the process of deploying a Mule App to CloudHub. In this post, we are introducing a Maven plugin that enables that use case. As a result a Mule App will be deployed automatically to CloudHub after a Maven build. This is achieved using the goal cloudhub-deploy from the Mule AppKit Maven Plugin.
In a ideal development workflow, each time the project builds the Mule Application will be deployed to the cloud providing a cutting edge instance that can be used for QA of the latest snapshot. Both Bamboo or Jenkins can be configured in order to run Maven and deploy the Mule App to CloudHub.
It’s pretty common to hear and read about how everything in the IT business is going “as a service…”. So you start hearing about Software as a Service (SaaS), Platform as a Serivce (PaaS) and even Integration Platform as a Service (iPaaS, which is where our very own CloudHub platform plays on). But what about data?
Lack of Connectivity Limits Marketing and Sales Engagement with Customers
As more companies adopt SaaS sales and marketing applications, SaaS providers are under the gun to create and offer functionality that supports the business process and automation requirements of these individual and sometimes silo teams. In any given organization, sales and marketing use upwards of 10 – 15 applications to engage, onboard and maintain customer interactions. Believe it or not, here at MuleSoft our marketing and sales teams use over 30 different applications. Yes 30, and we have less than 30 people in our marketing organization! Sample applications include, HootSuite, Google Apps, Confluence, Yammer, Salesforce, SurveyMonkey, WebEx Events, Eventbrite, Cloud9 Analytics, KISSmetrics, Google Adwords, GetSatisfaction and the list goes on. Each of these applications are used to engage the customer in a different stage of the buying process: