All posts by Ken Oestreich

Why We Make Our Product Roadmaps Public

“Can you please share your roadmap?”

“What are your plans to engineer feature xxx?”

“Great product, but does your vision match ours?”

We get these questions all the time, from customers, partners, and analysts.

As the leading open source API integration company, it seemed antithetical to be open and transparent about our code, financials, and priorities, but not about our actual product roadmaps.

So we’ve now opened-up our product and solution visions and roadmaps for each of our integration-related products, all part of our Integration Agile platform:

Why would we do this?

There are a number of reasons we chose to take this bold step – a step that most high-tech companies shun as competitively risky, and thus guard their plans with absurd paranoia.

  • Public roadmaps are consistent with our open source community
  • We trust our community to work with us, and they can only do so if they know our plans. That way they are always involved in the technology and will be able to best deliver meaningful new features, contributions, and roadmap suggestions.

  • Public roadmaps signal our transparency
  • Transparency is key to building trust between partners. A public roadmap helps committers, partners and customers to know we’re pulling no punches with our direction. It’s also consistent with our no-lock-in approach… and that means there’s no lock-in to our roadmap either. With a transparent set of roadmaps, our technology partners know what to expect… and have a proactive vehicle to comment on the direction.

  • Public roadmaps are good for our customers’ trust
  • When our customers buy-in to our integration platform, they’re putting technology direction on the line. They want to know if we’ll be evolving in the direction they want. For them, it’s all about mitigating long-term technology risk. This way, we’re “opening the kimono” and boldly stating direction.

  • Public roadmaps show our pride, confidence, and vision
  • WSO2’s technology has been evolving for over 13 years. Over 350 engineers currently work on technologies like API management, identity management, ESBs, enterprise integration, and related integration architectures. This is one way of showing-off our vision and capabilities.

  • Public roadmaps are good for business
  • In sales situations, customers often ask pointed questions about specific (missing) features. And the usual answer “Yup, we’re working on supporting it” is always received with skepticism. Our public roadmaps put our money where our mouth is… either it’s on the roadmap, or it’s not. Or, we work with our partners to change the roadmap… for everyone else to see.

Next, what’s on our Roadmap roadmap?

This is the first of many more steps we’ll be taking toward increased openness and transparency. But the other critical component is your feedback. So if you have thoughts about our roadmap- positive or negative – there are many avenues you can use, including our Contact Us button – and include your feedback.

Everything I know about Integration I learned at the Ballet

or, New ways to bring together the world of arts and technology…

Why would the inventors of an integration programming language partner with a Ballet company?

We asked ourselves that when WSO2, launched Ballerina, a new programming language for writing code to integrate software.

The notion of integrating software isn’t new… it’s been around for 10-15 years. And the current market for software integration — the set of technologies used to connect different software components together — is billions of dollars. That’s huge because there is simply so much software and data in the world. It resides not only in the companies that build it, but also in the “cloud”and in the billions of devices that people carry and use.

But when we thought about creating a programming language for integrating software, we didn’t realize how it would lead us to the San Francisco Ballet.

Enter Stage Left: Two entirely different — yet similar — partners

I don’t consider the SF Ballet one of those stodgy steeped-in-tradition companies. Just the fact that it’s in San Francisco means it has access to diverse-thinking, art-loving, Silicon Valley open-to-anything audiences…as well as access to global dance talent. To further appeal to this audience, they offer an annual Sensorium program that synthesizes dance, art, and music. They asked, “What could be possible when we integrate all of these art forms into one evening of celebration?”

Meanwhile, leadership at WSO2 asked something similar. What could be possible if we took a radical, new and open approach to connecting and integrating all software technologies? What would be possible if we developed an internal corporate culture of openness and transparency, of appreciation of our personal diversity?

When WSO2 began developing Ballerina roughly three years ago, we chose the name because of its technical elegance. But we hardly knew how prescient that name would be. So in 2018 when we officially launched the language, we thought that involving a ballet company might be a cool creative move, consistent with the “Ballerina” name. But what we discovered with the SF Ballet was much more. We realized that we had many themes and goals in common.

Common themes in the arts *and* in technology

When the SF Ballet told us about Sensorium and their mission to blend arts and technology, we knew we had a great future together. And so, WSO2 became the SF Ballet’s first technology sponsor.

Together, we found three common overarching themes arose that both patrons of the arts — as well as technologists — could appreciate: the concepts of integration, elegance, and openness.

Integration: Literally and metaphorically, this is the key to all creativity. In the arts, SF Ballet knew that dance, music, culture, and even technology could come together to create new experiences and new ways to engage the public. Integration at the Sensorium was a way to co-locate art, music, and dance exhibitions — and allow guests to interact with all of them. In the arts, integration often means a “synthesis” of diverse media and approaches to its use. And so, in technology, integration is a necessary approach to innovation, building on diverse software components that are often created by others. The beauty with technological integration is that the original developer may never know how the software component might be used by others to create something new, exciting or valuable.

Elegance: This is a word that’s often used with the assumption that it relates to the arts, to fashion or to dance. In those contexts, elegance is the use of resources like the body, fabric or media (or a combination) to create something of beauty — something that makes perfect or unique use of those assets. Often we just know elegance when we see it. As a recovering engineer, I also know there is absolutely an elegance to technology, science, and mathematics as well. Think about a suspension bridge, making perfect use of minimal materials — steel or concrete as support and cables to suspend — not a touch more heft or bulk than needed. Similarly, in mathematics, there are often short, concise formulas that so perfectly describe the physical world. And the same goes for coding where elegant programming makes efficient use (and re-use) of software components.

Openness: This last theme is deceptively simple but powerful. It’s about the importance of openness to new experiences, cultures, media, and perspectives. In technology, openness (i.e. open-source software) is also a well-known concept that means allowing others to build and create on top of your work, to view your code, your instructions, your architecture. In personal relationships — as well business and politics — openness implies trust and even a disruption of power (think: free press). So, openness is a necessary platform for true creativity as well as for effective innovation.

Will Ballerina learn more from SF Ballet?

At WSO2 and with Ballerina, as well as with the SF Ballet, we’re looking to continue thinking about more and different ways to “do integration” — whether it’s a revolutionary mashup of arts and culture, or new code-first approaches to integrate software, data and cloud computing. And that’s the beginning of a beautiful relationship: common goals, common interests, common values.

After all, a more integrated world—in arts and technology — is a more interesting, innovative, and creative place to be.

WSO2 API Management Strategy: Industry Observations and Implications

Recently we at WSO2 were asked by a leading analyst to outline our vision and strategy for the future of API management. We felt that our response captured much of our current and planned execution, so much so that we felt we needed to share it. Our culture at WSO2 has always been one of transparency, and in the past, we’ve even shared our financials.

Following are some of our positions on API management and additional market insights, as well as our vision of the composable enterprise. Stay tuned for additional strategy-related posts that dive more deeply into our technology “big bets” and direction.

How digital transformation is changing the landscape of APIs and digital connections

Current IT trends show that over the next few years, enterprises will find they need to deal with more than 1 trillion programmable endpoints and APIs. These will consist of traditional application APIs, data APIs, data streams, software component APIs, microservices, sensors, and IoT inputs as well. Indeed, everything may become an API.

Knowledge workers know this, and will want/need access to all these APIs/endpoints whether it’s only to create a basic SaaS-to-SaaS connection, or to create a more complex integration. Therefore, over the next 2 to 5 years, we expect that tools and processes will necessarily evolve to address this level of scale and complexity.

Additionally, infrastructures to support this huge quantity of endpoints will gravitate toward those optimized for microservices and serverless underpinnings. From a development perspective, current low-code integration approaches that involve centralized IT orgs and/or waterfall style processes simply will not scale. As a result, architectures will necessarily tend toward more decentralized, cell-based approaches underpinned by microservices and serverless.

With the trend toward trillions of endpoints, WSO2 believes much of what is today considered part of the “development” organizations will evolve to include API integration. The trend will be particularly strong where APIs serve as the core of digital apps and applications that rely on Internet of Things (IoT) data and artificial intelligence (AI). This is at the core of the disruption WSO2 sees in the coming years: that IT organizations tend less toward “development”, and more toward being “API integrators.” We call this new disruptive IT phase the composable enterprise, which will be fueled by the explosive availability and use of APIs and programmable endpoints.

The future of digital connections across enterprise boundaries

WSO2’s position is that API ecosystems across enterprises will expand as today’s software disaggregation (componentization) trends continue. Thus the composable enterprise will become a combination of both internal and external API-based services, each front-ended by private and/or public APIs. This API diversity—and dynamism—will inherently require hybrid API integration capabilities and distributed (rather than centralized) forms of management and governance.

To accomplish this, we see the use of distributed integration technologies, such as microgateways and micro ESBs, which necessarily operate in a decentralized fashion, bridging services from different sources, vendors, and enterprises.

From a business perspective, WSO2 sees ever-tighter service integrations across enterprises, suppliers, partners, and customers—all underpinned by API integration technologies. IT departments will become the “services supply chain managers.”

A perfect example is WSO2 customer Wells Fargo, which has successfully front-ended its organizations and systems with public APIs and gateways to accelerate new product and service delivery, as well as speed integrations with business partners. This form of API marketplace is being adopted by digitally driven organizations that are encouraging partners, suppliers, and even customers, to work more closely with their offerings.

Enter: the composable enterprise

The WSO2 vision of the composable enterprise does not imply a purely internal IT model, but rather an approach that spans the enterprise’s complete external service ecosystem as well.

The notion of the composable enterprise will involve closer, more secure, and more real-time digital interactions between vendors, suppliers, and customers—as well as for internal integrations. API-based interactions will also result in more rapid product and service innovation among all parties, creating new forms of value for customers, partners, and internal business units alike. Already, multiple forms of storefronts, macro-gateways, and monetization models are arising where enterprises are brokering their internal services for use by external entities.

Today, WSO2 customers are pursuing this vision. Wells Fargo, BNY Mellon, and StubHub are just three of many enterprises that are publishing their APIs, as well as basing their internal architectures on disaggregated components front-ended with APIs, gateways, etc.

Indeed, many leading companies are already basing the bulk of their revenue on the API economy, capitalizing on the business wave highlighted in by the Harvard Business Review back in 2015:

“…Salesforce.com generates 50% of its revenue through APIs, Expedia.com generates 90%, and eBay, 60%. Salesforce.com has a marketplace (AppExchange) for apps created by its partners that work on its platform; they now number more than 300. Expedia’s APIs allow people using third-party websites to tap its functionality in order to book flights, cars, and hotels. And APIs allow eBay to list its auctions on other websites, get bidder information about sold items, collect feedback on transactions, and list new items for sale-all of which give additional exposure to eBay items and increase revenue.”

Future drivers and shapers of API management

WSO2 sees the major pressures driving the future of the API management space as grouped into two main categories: the market drivers led by the demand for API business and the technology shapers, led by vendors and innovators.

Drivers of API demand aren’t entirely new, but they have recently risen in their influence on IT behavior:

  1. The trillion endpoints future: the trend toward every digital asset becoming a programmable endpoint and causing IT to create strategies to access these assets.
  2. Digital business competitive pressures: forcing organizations to more quickly find ways to digitally interact with suppliers, partners, and customers.
  3. Knowledge worker information consumption: where organic demand for nearly every digital asset begins with line-of-business users looking for new data and conveniences.
  4. SaaS-to-SaaS app integration: a trend increasing exponentially where every new SaaS app or component is more valuable each time it’s integrated with another.
  5. Machine learning: with applications of ML forcing both data at rest and data streams to become accessible and front-ended with APIs.

Similarly, API management is being shaped by adjacent systems and technologies, quickly maturing the use (and re-use) of software endpoint components:

  1. Microservices and serverless technologies: these are (and will be) driving massive app disaggregation because of the abstractions and simplicities they create for software deployment, directly leading to a world of more broadly distributed micro APIs and microgateways.
  2. Cloud native dynamic systems: growing class of distributed and dynamically changing microservices will cause API discovery and surveillance to become dynamic as well.
  3. Configuration-based integration tools (e.g. ESBs) and code-based integration programming languages (e.g. Ballerina): because, “Software is eating the world,” every company is being forced to make software and agile integration to become a core competency. This creates a world where forms of API integration need to become as agile as developers and organizations want them to be.
  4. API security, access and governance: these requirements are leading to the native integration between integration, access Management, and API management.
  5. The advent of distributed cell-based architectures: these new architectures will allow for decentralized development, test and deployment, speeding integration activities across organizations.

Implications WSO2 sees for the future of API management solutions

  • Implications for architecture: there will be a growing shift toward cloud-native architectures and a need for decentralized composable units of architecture. Each composable unit is what WSO2 terms a “cell”. Cells are defined by, and interfaced through, APIs; are governed by micro- and macro-gateways; include embedded control planes like service meshes; and are developed by decentralized, independent teams.
  • Implications for development agility: with the need to develop and maintain an increasing number of connections across the enterprise, an organization’s ability to remain agile while supporting this expanded connectivity, faces pressures. WSO2’s vision is not only enabling organizations to make these connections, but to empower development teams, DevOps, and operations to increase their adaptive agility while doing integration. Integration teams must become integration agile, adopting the tools, organization, and processes similar to agile development.
  • Implications for tools: all API management and integration tools will need to involve some form of distributed technology, and all will necessarily evolve to be microservice and serverless friendly, i.e.:
    • Provide distributed forms of observability and security
    • Offer multiple control planes
    • Support service meshes
    • Support hybrid orchestration architectures

In closing…

Here at WSO2, we’re betting that all developer organizations will eventually have to adopt integration skills as well — especially as all digital assets become accessible and programmable.

We’re also anticipating the result will be the composable enterprise, shifting business onto a digital ecosystem. And to facilitate that, we’re building open source integration tools, integration agile methodologies, and even programming languages, to help digitally driven organizations achieve this future.

Stay tuned for more of our technical “big bets” in a future blog.

Announcing the WSO2 Serverless Solution

Most enterprises today looking for serverless solutions have few options without cloud lock-in. Remember that public serverless offerings will capture a customer’s data, lock out external event streams, and likely limit developer language choice. This lock-in hinders application migration, multi-cloud scaling, and the use of private cloud resources. A more palatable solution ought to allow organizations to tap serverless for disaggregated architectures, and allow them to utilize both public and private cloud resources, event models, and programming paradigms.

In response, customers today are mostly forced to use public serverless offerings from AWS (Lambda), MSFT, GOOG, etc., with limitations placed on the supported programming languages for each. Users are further locked-in because of the need to use adjacent proprietary services like the cloud’s storage services. And if a company wants to use an alternative, they’ll require considerable investment to manage.

Enter the WSO2 serverless solution

Today we’re introducing the WSO2 Serverless Solution, a private function hosting environment based on Apache OpenWhisk and Kubernetes. And it’s immediately available, though on a limited-access basis.

To develop the solution, WSO2 has been working with Rodric Rabbah and Perry Cheng, co-founders of CASM LLC and co-creators of Apache OpenWhisk. They bring in-depth knowledge on custom deployments and backend optimizations to the overall solution, and both continue to be active members of the OpenWhisk community.

The solution allows organizations to leverage their existing event sources and programming languages. Underlying the open source function platform, Apache OpenWhisk allows developers to plug existing event sources into the solution. It also allows developers to use their preferred programming language as a function runtime which will allow them to re-use most existing code, and allows users to define their own custom resource limits. These combine to provide greater overall agility to a serverless solution. And you’ll have freedom from cloud lock-in.

And the best part is that the WSO2 Serverless Solution is a private hosted platform managed by WSO2, so it ought to significantly reduce learning, set-up and maintenance overhead for DevOps teams.

A little more detail…

The serverless solution is fundamentally powered by Apache OpenWhisk and Kubernetes to allow IT orgs to provide a uniform, elastic, and secure platform for reactive, event-based, and batch workloads.

The Solution offers several unique capabilities:

  • Private function platform – powered by Apache OpenWhisk deployed on top of Kubernetes
  • Managed hosting environment – provided by WSO2, mapped to internal private resources and events, with customized elasticity.
  • Private, dedicated servers and operations – provides segregated tenancy
  • Support for any programming language – broader support than any single public cloud vendor
  • Leverage any existing event source – no matter where you deploy
  • Transparent computational elasticity – to support both short and long running computation
  • Guaranteed computational capacity – because it is a private function environment
  • Secure platform, plus service isolation, and encryption of data in motion
  • Local development environment – for developer teams
  • Dev tracing and operations of event-driven apps with logging, monitoring, and analytics

Why did we do this?

WSO2’s mission is to help digitally-driven organizations become integration-agile. And we do that with a platform of open-source Integration, API Management, Identity Management and related products. One core motive of ours (and of the overall open source model) is freedom from lock-in… So it stood to reason that if we wanted to simplify integration tasks, it would require simplifying deployment tasks too. So we developed this cloud-vendor-neutral deployment approach to complement our products.

Availability

As mentioned, the solution is immediately available on an early-access basis. Pricing is offered at a flat rate, on either a monthly or annual billing. For more information see the WSO2 Serverless Solution.

Four Warning Signs an Integration Wall is Approaching

The Integration and API Management markets are growing, expanding in both popularity and use. Enterprise App integration will surpass $33b by 2020, and other markets like iPaaS and Data Integration are growing at double-digit CAGRs. Enablers, such as containers and serverless technologies are only accelerating the move toward increased disaggregation of applications.

All seems rosy. And it mostly is.

But with the explosive growth of APIs and endpoints, traditional centralized tools like ESBs will become unsuitable, and simple low-code snap-together tools won’t scale to address the broader scope. We’re potentially about to hit an “integration wall” at high speed.

Consider the following four warning signs – some technical, some process – that I find are beginning to plague the integration market:

1. Waterfall Development for integration is hitting a wall.

Although most code development has shifted to an Agile Development model, the same can’t be said for Integration tools. As the quantity and diversity of endpoints increases, and as Integration projects become more diverse and complex, use of the waterfall model is beginning to slow down integration projects. And with a future where there will be billions of Integratable endpoints, it’s obvious that an Agile Development model for integration will need to become the norm.

2. Existing tools and programming languages aren’t optimized for Integration-at-scale.

Enterprises that currently use low-code, snap-together, centralized integration technologies (including iPaaS) will not be optimized for orchestrating, integrating, observing and governing the expansion of constantly-changing endpoints. Nor are traditional centralized approaches (think: EDI and older ESBs) prepared to handle increasing endpoint scale or diversity. Many of these existing tools are well-adapted for Line-of-Business or Citizen Integrators of relatively small-scale implementations but are far from well adapted for more complex integration-at-scale projects.

3. Current programming languages are not optimized for Integration.

With languages like Java/Spring or JavaScript/Node, developers can engineer flow, but must take responsibility for solving the hard problems of integration. With these languages, developers have to write their own integration logic or use bolt-on frameworks. Clearly a new programming paradigm will be needed long term.

4. The Exploding Endpoint Problem is very real.

As I referenced above, IT is ill-prepared to address the oncoming wave of service disaggregation, the diverse types of APIs, differing sources of service endpoints, challenges from Big Data, and multiple approaches to serverless IT. The industry is about to hit a scale and diversity wall. To wit,

  • 917 apps in use per enterprise (Netscope, 2016)
  • 893-1206 average cloud services used per employee (Kleiner Perkins, April 2017)
  • 19,000 APIs as-of January 2018 (Programmable Web, 2018)

And if you don’t believe those numbers, Matt Eastwood of IDC recently pointed out that the number of containerized services has expanding well beyond where VMs ever were. Yep, billions of programmable endpoints aren’t kid’s stuff.

Where does this leave us?

A new approach to addressing the future of integrating thousands-or millions-of endpoints could lie in a new programming language, Ballerina.

Ballerina is a simple programming language whose syntax and runtime have been optimized for the hard problems of integration. Its focus is integration – bringing concepts, ideas and tools of distributed system integration into the language. Based on the concepts of interactions within sequence diagrams, Ballerina has built-in support for common integration patterns and connectors, including distributed transactions, compensation and circuit breakers. And it supports JSON and XML, making it simple and effective to build robust integration across distributed network endpoints.

So, watch this space for future developments. And in the meantime, beware of the approaching wall.