singkham - Fotolia
On June 22, open source tools and platform provider Red Hat announced a major addition to its middleware portfolio by acquiring 3scale, a developer of API management tools based in London. Mike Piech, Red Hat's vice president of middleware, and 3scale CEO Steve Willmott spoke with SearchCloudApplications about the acquisition, the increasingly important role APIs play in cloud and mobile application development, and the rise of microservices and containers.
What will the union of Red Hat and 3scale create and provide to the development community in terms of API management tools that does not exist today?
Mike Piech: We've had a rich integration portfolio for years anchored on our JBoss Fuse [open source integration] product. These enabled a next-generation style of integration that's much more lightweight than a traditional enterprise service bus architecture. Where we've not had a good set of capabilities in our own Red Hat stack is in API management.
How does the 3scale acquisition mesh with and extend the capabilities of previous Red Hat acquisitions, such as the FeedHenry mobile app development platform?
Piech: FeedHenry and 3scale are complementary in their development capabilities. FeedHenry was initially offered as a pure as-a-service model. We are open-sourcing the code and creating on-premises packaging of the FeedHenry code. We will do exactly the same thing with the 3scale technology. Services, such as mobile, security, push notification and API management, will ultimately be provided as services running on top of our OpenShift platform as a service. They will all be there as first-class citizens that can be incorporated into applications and microservices-based architectures.
Are APIs growing so fast that their management is out of control?
Steve Willmott: Over the last 18 months, we've seen extreme growth in large enterprise customers. APIs have become the backbone of many infrastructures, but they often lack systems for tracking their APIs. We've been finding that the API management tools market is accelerating. We've always taken the approach that you want a policy-management layer that tracks everything and gives you control over all of the APIs; you can plug into APIs wherever they are, all over the organization. With Red Hat's means to build those APIs on the back end, there's an opportunity to wire in the 3scale platform everywhere.
Why is this the right time for such a union of Red Hat and 3scale?
Willmott: The change that we've seen in the last 12 to 18 months is that companies often had an external API program that was separate from their internal infrastructure. But now, APIs are becoming much more valuable internally. With the trend toward containerizing services and microservices, it's important to know where they are and who has access to which ones. We've seen many use cases where large companies have internal APIs that they move over first to partner access, and then make fully public. API management has matured to the point where it's becoming a core part of a company's infrastructure. Of all the partners we've worked with, Red Hat is the best fit for us.
Piech: Two years ago, API management rarely came up as a top-level requirement. We've seen that rise in importance and become a gap in Red Hat's product portfolio. We were addressing that through our 3scale partnership, but many customers want to buy from a single vendor. They want a strong assurance that the technologies will remain complementary and work together in the long term.
As to why we chose 3scale, we looked at other possible acquisition targets and explored building from scratch in-house. Ultimately, we realized that if we could find the right company, acquisition would be a faster way to get to market with a technology strong enough to address the need for API management.
How does the 3scale API management tools architecture benefit developers?
Piech: By staying out of the request-response path and being able to plug into wherever a customer's APIs currently live makes for an easy insertion ability, without the need to reload all the APIs onto a new platform. It also eliminates the introduction of potential latencies.
Does software as a service (SaaS) render any aspect of open source and APIs as unnecessary?
Steve WillmottCEO, 3scale
Piech: That is a super interesting topic. We talk about this a lot inside of Red Hat. Does the 'servicification' of capabilities render the 'open-sourceness' of an implementation irrelevant? There are many hybrid implementations and adoptions of consuming services from the public cloud as-a-service model. But there is still a tremendous amount of on-premises development and implementation going on. For the on-premises installed base and new customers wanting to build on premises, the open source aspect matters for them. The [really] interesting aspect about open source is less about that the source is open and you can inspect the source code, but more about it as a development model. It's about the innovation coming out of the community being so many times greater than the number of engineers that a proprietary company can hire and put into its ivory tower. What's really important is that the services behind the APIs continue to be rapidly innovated in a way that can be driven only by that open source development model.
Willmott: Some people want to consume a particular SaaS service; you can start using it right away. But, with our own SaaS offering, we still saw a demand for APIs on that, being able to take any part of the system and configure it remotely. Our large customers almost all have a hybrid scenario, with resources on premises and in the cloud. APIs are the glue between on-premises and cloud-based components. The world is divided into enabling technologies and technologies that you consume as an end user. With an API infrastructure and integration software and all of the middleware layers, they are really enablers.
What is the impact of the rise of microservices and containers on API management tools and technology?
Piech: Red Hat has put a lot of energy into the idea of containers and container infrastructure. Docker is at the heart of our OpenShift platform-as-a-service offering. We have lots of ways of building out a container management infrastructure with Red Hat Enterprise Linux up through other infrastructure-layer technologies. We're betting on containers in a major way. Beyond the obvious benefits of containers in terms of managing applications, app deployment and lifecycles, and making it easier to deploy to servers in a repeatable, reliable, secure way, container technology has enabled a fundamentally finer-grained decomposition of applications into small pieces that we call microservices.
Mike Piechvice president of middleware, Red Hat
Containers are so much more lightweight than a traditional virtualized full server. You have stack pieces that allow you to deploy really tiny things and management capabilities through technologies like Kubernetes. Now, you can manage not just hundreds, but tens of thousands of these small entities. That creates a virtuous cycle of architecting applications into finer-grained modules that enable rapid, iterative development and independent lifecycling of smaller pieces so that you can make changes quickly and without disrupting huge swaths of the infrastructure. The demand and adoption of an approach built on containers and microservices is spreading like wildfire. The need to manage how these microservices access each other is driving an explosion of need for API thinking for creating well-disciplined boundaries between services. As you think about architecture as a vast network of APIs and how these microservices talk to each other, the need to manage all of that becomes obvious. I've got thousands of microservices, each with an API describing and governing what it provides. How do I manage all that? The need for API management is just exploding.
To what extent do you see so-called no-code/low-code (NCLC) development tools eating into the traditional discipline of app development and into the tools market where Red Hat is a major force?
Piech: The NCLC environment and NCLC development is primarily predicated on APIs. Think about a business analyst noncoder who is composing workflows. All of those representations of tasks that this person is dragging and dropping in that nice graphical environment are still implemented in code somewhere. The capability that makes those pieces available to be connected is all based on APIs. Even though that analyst has the power and flexibility to make significant changes, the APIs enabling those underlying capabilities still need to be managed. Ultimately, this makes NCLC yet another driver of demand for APIs and API management tools.
Time to move from an ESB to microservices?
Just how bad is open source code security?
What's your API management strategy?
How you can benefit from API management software