Tag Archives: WSO2

WSO2’s Growth Story and Why Open Source is the Only Way to Solve Your Integration Challenges

Last week, Ken Oestreich, WSO2’s VP Product Marketing, and I were at the AGC Growth Conference, where we discussed WSO2’s growth story. WSO2 continues to be relatively unknown in business development circles, and this was a wonderful opportunity to report on our traction and understand how the broader ecosystem views integration.

Here is that presentation in full.

WSO2 is the largest open source integration vendor by revenue and customers.

WSO2 is the largest open source integration vendor by revenue and customers. We are EBIT and cash flow positive, with subscription growth approaching 60%.

Integration turns out to be the hottest market even though it’s the uncoolest thing.

Integration is everywhere, and it’s $30 billion annually dominated by three types of integration. All three segments will have billion dollar growth in the next decade. While iPaaS gets significant market attention, it’s not sufficient for most kinds of integration. iPaaS is a metaphor for the line of business, which is departmental-driven, repeatable forms of integration. There are 150 competitors in this space and is prime for a shakeout. iPaaS vendors template-based approaches are not well suited to app integration as they cannot expand to reach the breadth and depth of integrations required—they only work in templated formats where the same integration can be repeatedly done, which is ideal for some types of SaaS to SaaS workflows.

In app integration, old vendors like Tibco, Software AG, and Oracle will suffer as the rotational movement to microservices and open source accelerates. In order to meet significant demand, software vendors are disaggregating their architecture in order to scale. The approaches to integration that service highly disaggregated architectures are shifting, and pure open source vendors have modern architectures to address this.

For the past 5 years, WSO2 has been engineering our approach to integration, with a focus on highly disaggregated architectures due to the rise of APIs and microservices.

WSO2 uniquely offers a suite of technologies because point solutions do not address the full integration problem.

Integration historically is the movement of data between two points, for which we do exceedingly well with our WSO2 Enterprise Integrator solution, but integrations complexity has increased because:

  1. every integration is an API—so WSO2 API Manager required,
  2. every integration must be governed—so federated WSO2 Identity Server required,
  3. data is moving from at rest to real time in-motion—so WSO2 Stream Processor required,
  4. as industries understand the power of becoming a digital native enterprise, vertical API solutions for compliance and regulation appear such as WSO2 for GDPR, WSO2 for Open Banking, and WSO2 for Telco.

If software is eating the world, then you can no longer be a software organization with also being an integration organization.

Our integration opportunity increases as 50 billion integratable endpoints grows to 1 trillion over the next decade. Everything will become an endpoint, and when those endpoints are exposed as APIs they will become programmable. Integration becomes a problem for all software integrations as its the discipline for resiliently communicating between these endpoints.

Integration is the unspoken challenge of the cloud, AI, data, and cyber security future.

If you follow Marc Andreesen’s hypothesis of software is eating the world, then you can no longer be a software organization without also becoming an integration org.

Closed source, open core, and iPaaS vendors do not have the community reach or contributions to address the full scope of integration problems.

The protocols, data formats, and APIs of endpoints change frequently. A centralized approach to integration, such as those offered by proprietary or open core vendors, are limited to the support they can provide by the resources they fund themselves. This is limiting and cannot address the full breadth of differences that must be addressed.

Community, collaboration, and shared experiences, such as what we provide with WSO2 open source, are the only way to integrate every type of endpoint that is coming.

WSO2 is one of the largest open source companies. We have received more than 1 million contributions that have lead to improvements in our open source integration runtimes and into connectors and adapters used to integrate the rest of the community.

WSO2 contributes to more than 100 open source projects, which reciprocate by contributing back, making WSO2 the 69th largest contributor to GitHub.

Integration is still waterfall, so we are investing into Ballerina to make integration agile.

Integration technology forces development teams to follow waterfall lifecycle practices. This doesn’t scale, so we are also investing in Ballerina—a cloud native programming language for integration—to give developers quick, agile development for integration. With Ballerina, every developer can integrate anything, with a learning curve in hours, unlike the months required for Java / Spring or JavaScript / Node.

Ballerina represents a unique, new, and improved approach from typical EI and iPaaS products. Their either agile or integration simple, but never both. A programming language and platform whose syntax is integration simple, but works with a developer’s favorite tool chain in an iterative flow creates true agility. This makes it impossible for developers to integrate at scale to adapt to changing requirements and deal with increasingly disaggregated architectures.

Open source is the best defense for mega-cloud and proprietary vendor lock-in.

Open source is the best defense for addressing lock-in that comes from data lock-in of clouds, API lock-in of mega-clouds, and vendor lock-in from proprietary licenses. Almost 90% of operators are focused on avoiding lock-in. Open source solutions offer a great way to provide try-before-you-buy and substitution options to those that adopt it. WSO2’s solutions also deploy in any environment, and we deliver WSO2 on any public, hybrid, and private cloud infrastructure.

Wherever you may be on your digital native journey, WSO2’s subscriptions include the practices, methodologies, & technologies to transform you from integration waterfall to integration agile.

Companies and governments engage us through our consulting and subscriptions that accelerate the evolution of any digital native initiative.

We have 450 enterprise customers reflecting the world’s best brands that already process more than 5 trillion transactions through us each year.

Open source is more efficient than closed-source—with growth, net retention, and NPS rates equal to MuleSoft, but higher profitability and employee efficiency.

We have a unique open source software business model that has fueled our growth. We release our code with an Apache license. However, we package and ship support patch binaries with a WSO2 license to those who maintain a subscription. This offers a balance between the best freedoms of open source and measurable added value.

And, wonderfully, our internal teams do not compromise productivity by perpetually wrestling with where the “for free/for pay” line must be drawn. It is expensive for an enterprise vendor to determine the best model of where for-fee options reside. Not only does the vendor have to develop a strategy, but they must communicate this to all their employees and then justify it to the open market. These costs are passed along to customers and require significantly higher forms of capital from investors. This line does not stay static, either. The nature of open source is that is erodes and impedes upon the areas where a vendor is selling their proprietary extensions. This means the “for free/for pay” line must be rethought. This is a continual process, and this is time where inefficiencies are introduced.

  1. Many companies take credit for open source, but only a few, like WSO2, have all their published software as open source, which allows any company to consume or use the software without first having a relationship with the vendor.
  2. WSO2’s open source software business model is innovative and unique because of the IP we have built around patch distribution and support engagement. This consequently encourages customers to get and maintain a long term subscription. Customers only maintain a subscription with us through the period where we provide immense value, forcing WSO2 to create business practices that embrace a customer’s needs more wholly.
  3. The proof of this is that WSO2’s net retention rates are identical to MuleSoft’s, which is an open core vendor, effectively only selling proprietary solutions, while having much higher profitability.

We take our offerings to market with a territory and inbound sales model that combines channel partners, resellers, distributors, and our customer success team.

We take our offerings to market with a sales model that combines channel partners, resellers, distributors, and our territory-based customer success teams to engage, win, expand, and satisfy every customer.

  • By swarming the customer throughout their lifecycle, we reduce the chance of churn and help derisk the customer’s initiative. This is why we can maintain a 40 Net Promoter Score (NPS).
  • We now have 550 people in Mountain View, Colombo, Manhattan, Sao Paolo, and London. We are opening offices in Australia, Mexico, and Europe this year.
  • The forces shifting the sector rotation from proprietary software to open source are strongest in emerging economies, which is why we shortly anticipate opening offices throughout eastern Europe, the middle east, Africa, LATAM, and APAC.

This is an impressive set of financials…

The market has rewarded us with 52% subscription growth, which has been accelerating, and also a dollar-based customer retention rate which is equal to MuleSoft’s, but with a community and business operating model that is more efficient letting us have EBITDA profitability and positive cash flow. If you are an investor, we will be a 58 this year on the rule of 40.

Our success has largely been organic, with a minimum of outbound marketing and a small sales channel. This is going to change as we step on the accelerator in the coming years.

Our growth story is not ours alone, we can work together with you to growth faster, together.

We communicate our growth story to our customers, employees, investors, partners and ecosystem to help us discover ways to have a bigger impact, and potentially grow faster. Our growth story is not ours alone to be had. We can work together with you to grow faster, together.

We are building relationships that more aggressively expand our territory and technology partnerships, while also building upon our strategic initiatives with Ballerina and connectors.

If you are interested in learning more about WSO2 or to potentially become a partner, you can reach me at tyler@wso2.com.

WSO2Con Insights – How APIs are Driving StubHub’s Business

Transforming a business to an API-centric architecture is a major undertaking, but it’s one that yields many benefits, most notably the ability to grow the business by extending processes to partners. In his keynote presentation at WSO2Con US 2013, Sastry Malladi, chief architect for StubHub, explained how the company has implemented an API-centric architecture to capitalize on this opportunity.

According to Malladi, adopting an API-centric architecture was driven by two factors. First, the company wants to expand from an online marketplace for tickets to become an end-to-destination for fans, including sharing their event experiences and getting information about things to do in event locales. Second, StubHub, which currently has a presence in three countries, plans to expand worldwide.

He observed that to achieve this goal, StubHub needed to build a developer community and enable partners to bring their content and services to the StubHub audience.

For example, Malladi noted, “If you’re at a hotel, and say you want to do something this evening to a concierge—how do we integrate those? You need to go to places where people are instead of expecting them to come to your site.”

Reusable Components Are Key to API Architecture

Before StubHub could extend APIs to partners, Malladi told attendees, the company first had to break down StubHub’s monolithic, hardwired application into shared, usable components, or services. This was necessary, he explained, because an API is an externally exposed “service,” which includes a developer program and typically has a “functional” contact as well as a “non-functional” contract, such as a service-level agreement (SLA). Moreover, the API potentially maybe orchestrated across multiple services, he said.

As part of this effort, Malladi explained, StubHub has established a domain meta model in which each domain is separate and independent and has one or more functions; each of these functions can have one or more APIs, but there is a one-to-one relationship between an API and an endpoint. Additionally, he said, the StubHub team does dependency modeling, so when someone is developing a function or API, the dependency is understood. Finally, he explained that domains are done in such a way that the entities belonging to a domain are owned by that domain, and the only way to access those entities is by going through the domain.

“Bottom line,” Malladi noted, “These APIs are giving us the business agility that we need and the operational excellence.”

API Architecture Opportunities Vs. Challenges

Malladi observed that an API-centric architecture offers several benefits for StubHub in addition to business agility:

  • Sellers have the flexibility to build their own customized solutions, and systems scale well to inventory and traffic.
  • Buyer experiences are enhanced, since it allows the developer community to extend the StubHub fan experience.
  • API brands serve to drive revenue and increase visibility.
  • Developers are encouraged to explore the APIs and see what they can accomplish with them.

However, becoming an API-centric organization presents challenges as well.

Malladi noted that while a new business could start from scratch, an established company, such as StubHub needed to balance the re-architecture with meeting other commitments to the business and customers.

A second challenge according to Malladi is that consumption patterns are not fully “baked” at the time of building an API; you won’t know fully who is going to consume them and what their patterns will be. Similarly, chargeback models and SLAs will not be clearly baked at first.

That is why it is important to build the API in such a way that it is flexible and can adapt to changes, he said. Moreover, exposing APIs to a lot of partners is not free, so architects and developers need to incorporate capacity planning and accountability into their models, he added.

At the same time, fraudsters are looking to make money off of Internet business sites. For this reason, companies need to be able to detect and prevent them from leveraging the API, and impersonating and collecting confidential data, Malladi advised.

The Role of WSO2 API Manager

For its own API architecture, StubHub is using the Store and Publisher in WSO2 API Manager, API Gateway based on WSO2 Enterprise Service Bus, and WSO2 Identity Server, Malladi said. The Publisher is where internal team members publish their APIs and manage the lifecycle of the APIs, he explained.

The Store is where an API is exposed both to the external and internal consumers, so they can create their applications. Malladi noted that the Store works the same way both internally and externally on both the website and mobile apps. He also invited attendees to visit StubHub’s implementation of the Store, the Developer Portal, at https://developer.StubHub.com.

WSO2 Identity Server manages user authentication, key management, JSON Web Token (JWT) assertion, Malladi said. Meanwhile, the WSO2 ESB-based API Gateway routes all incoming requests and works with WSO2 Identity Server to authenticate them.

Malladi noted that the combination of WSO2 API Manager and WSO2 ESB has enabled StubHub to address the need to manage APIs across Web and mobile domains. This is an important feature, since mobile is where StubHub sees the biggest growth, he explained.

Big Data Insights into APIs

To support StubHub and its expanded business model, the company is creating a big data platform to answer key questions, Malladi said. For example: How does the API manage social data and business analytics? How do StubHub APIs use these data sources, process the data, and bring it back in real time?

“It’s not just about creating an API but how it works on the backend,” Malladi observed. ““It’s so important to understand who your customer is and what they are doing.”

As Malladi then closed his session, he noted that building an API-centric architecture is a key driver for business growth, but as with any initiative there are challenges as well.

“The good news is you aren’t alone,” Malladi said. “And there are solutions.”

For more information about StubHub’s process for creating APIs, you can view Malladi’s WSO2Con US 2013 keynote address.

 

WSO2 Mashup Server: Where to Now?

You may have noticed the WSO2 Mashup Server link has been retired from our menus, and seen that the WSO2 Mashup Server page on wso2.com directs you to the WSO2 Application Server product page.  Curious as to what’s going on?  Here’s the whole story, from inception to the present and looking towards the future.

Where the WSO2 Mashup Server led the way

I joined WSO2 back in 2006 as Director of Architecture for Mashup Technologies to explore ways to make the emerging stack of WS-* specifications approachable and efficient for the average Web developer.  The result was the WSO2 Mashup Server, which introduced a number of valuable ideas and features:

  • Expose simple Javascript functions as full-fledged SOAP Web services, bringing Web developer skills into the enterprise.
  • Simplify access to SOAP Web services from within Javascript (mashups or browser).
  • Make dealing with XML payloads easier.
  • Interface with other systems that Web developers are interested in, particularly feeds, data sources, and other web pages.
  • Build a try-it functionality allowing developers to point at a WSDL and get a usable form-based user interface to explore a Web service (or to provide a default user interface for any service.)
  • Make the results available in forms a Web developer cares about: web pages, gadget portals, feeds, instant messages, email messages.
  • Seed an ecosystem of reusable mashups by building community features into a multi-tenant environment, where each mashup exposes services that can be reused and recombined.
  • Host a public site (mooshup.com) for the mashup community.

The resulting product, the WSO2 Mashup Server, broke new ground and gained a lot of interest in the community, proving the value of
many of these ideas.  Here’s what the 1.x version looked like back then:

image

These core features and ideas have over time influenced the WSO2 Carbon platform.  As more of these ideas have been incorporated broadly into the platform, the layer unique to the Mashup Server has become increasingly small.  Here are some ways the Mashup Server informed WSO2 Carbon platform evolution:

  • Multi-tenancy.  The early multi-tenancy (really more of multi-user than full isolation) in the Mashup Server allowed many users to register, author and share their own mashups with others, has evolved into a full multi-tenant architecture across the Carbon system, and has been a core feature cloud-enabling the WSO2 Stratos Platform-as-a-Service.
  • Social enterprise.  Enabling community features like tags, ratings, comments, granular feeds and search embedded those capacities into the underlying WSO2 Governance Registry.  They remain a key part of our governance capabilities and continue to evolve through initiatives such as the WSO2 API Manager’s API Store interface.
  • Try-it. Try-it for SOAP services has been integrated into all our products that focus on exposing services.  I personally think we have lost a bit of the “default user interface” focus over time and hope to push us back to regain and extend that aspect of developer experimentation, but an increasing preference for RESTful services which can be readily explored through simple tools like Curl is making that less urgent.
  • Gadgets.  The Google gadget dashboard and gadget generators made their first appearance as a component of the WSO2 Mashup Server, but were fairly quickly spun out into a separate product.
  • WSO2 Carbon.  It’s my view that WSO2 Mashup Server became in large part the straw that broke the back of the camel of a suite of related, but separately developed, products.  With many capabilities and shared components between WSO2 Mashup Server, WSO2 Data Services Server, WSO2 Governance Registry, WSO2 Gadget Server, coordinated development and releases across these products became untenable and helped motivate the hard but incredibly valuable work of moving towards the world’s first fully componentized middleware platform.
  • WSO2 StratosLive.  The multi-user publicly hosted WSO2 Mashup Server branded as mooshup.com site became redundant as the whole WSO2 Carbon platform emerged through WSO2 StratosLive as a solid public middleware PaaS encompassing the whole range of WSO2 products.  Mooshup.com was retired quite a while back when StratosLive came online.

What remains unique to the Mashup Server at this point is limited to the hosting of Javascript Web Services.

As our WSO2 Application Server product has expanded to encompass a platform for hosting a larger variety of web service and web application types, it makes sense to simply include Javascript services among that set.  So even though there is no longer a separate download for the WSO2 Mashup Server, the capabilities available in the final release remain present in the WSO2 Application Server.

Where the WSO2 Mashup Server missed the boat

It’s worthwhile to review some of the areas where the Mashup Server failed to reach the mainstream.  As a SOAP-centric and XML-centric model, it lost some relevancy as RESTful services and JSON have dominated the API ecosystem targeted at Web developers.  The Mashup Server’s focuses on APIs didn’t provide an easy environment for developing Web Applications – many Web Apps I built on as mashups were comprised of static HTML pages, AJAX and XML, without dynamic HTML creation and relying completely on AJAX to invoke any kind of server-side processing.  Not always the most straightfoward solution.

To address these needs, we’ve got a new approach. Jaggery is a server-side Javascript framework, that allows the Web App or mobile developer to use the same models on the client and server sides: HTML, Javascript, and JSON.  Jaggery makes it easy both to generate dynamic web pages, but also to expose RESTful services.  It brings native JSON processing to the server side and thus makes it much easier to author Web/mobile clients and services and for them to work seamlessly together.

So if you’re using the WSO2 Mashup Server, you’ll find an easy transition to the WSO2 Application Server and I’m confident you’ll find this aggregation to be a straightforward and positive move.  And we encourage you to expand your ability to leverage the advantages of Javascript server-side development with Jaggery.

Jonathan Marsh
Vice President of Business Development
blog: http://jonathanmarsh.net/blog

After Sonic ESB Pioneered, WSO2 ESB Continuously Innovated

After Sonic ESB pioneered the Enterprise Service Bus market and created technology to more readily integrate applications using Enterprise Integration Patterns, WSO2 continually added innovations to the core ESB pattern and created the highest performance, lowest footprint, fully interoperable and flexible ESB, WSO2 ESB.

Progress Software recently lowered their sights on supporting enterprise integration developers, and Progress is has publicly announced intent to sell Progress Sonic ESB, Actional services management, and FuseSource. Progress’ recent strategy shift places Sonic ESB, Sonic MQ, Actional, and FuseSource customers at risk of further obsolescence.

Where did Progress’ corporate strategy fail? By growing through ad-hoc acquisition and superficial integration instead of organic platform development. Progress played a failing game espoused by IBM, Oracle, and Software AG. Progress acquired competitive threats and then invested the minimal amount required to create a ‘SOA Suite’. As often the case, the strategy led to multiple overlapping products, competing business units, lost internal talent,
and a disjointed customer experience.

At WSO2, we have consistently taken a different approach. Our complete, composable, and cohesive platform was built through organic development, which continually enhances our core platform, incorporates market-leading innovations, and delivers a seamless customer experience. Our WSO2 Enterprise Platform enables complete data to screen enterprise integration, SOA, BPM, API management, web application development, and Cloud.

Our WSO2 ESB, WSO2 Governance Registry, WSO2 Business Activity Monitor, and WSO2 Identity Server provide a production proven, high performance SOA middleware foundation. We welcome you review our case studies and learn how WSO2 ESB processes more than 1 billion transactions per day for eBay, streamlines the development and maintenance of smart power grids, supports T24 core banking systems, and enables consolidated reporting across
enterprise applications.

Our Offer to Progress Sonic ESB and Progress FuseSource Customers

WSO2 desires to assist Progress Sonic ESB and Progress FuseSource customers choose a viable, stable, and supported middleware platform. We are offering free Evaluation Support to current Progress Sonic ESB and Progress FuseSource customers, and would be pleased to demonstrate how our market leading WSO2 Enterprise Service Bus and WSO2 SOA Platform meets your evaluation criteria. Feel free to contact us via our Progress customer offer landing page, our contact form or send us an email note.

Chris Haddad, VP Technology Evangelism Chris’s blog: http://blog.cobia.net/cobiacomm/