Home United States USA — software "Serverless is next-generation PaaS"

"Serverless is next-generation PaaS"

332
0
SHARE

At NDC Oslo, InfoQ spoke to Udi Dahan, founder and CEO of Particular Software. He spoke about trends in the software industry – like serverless and microservices – the Particular product suite, and the history of NServiceBus.
At NDC Oslo, InfoQ booked some time to talk to Udi Dahan, the founder and CEO of Particular Software. Particular is the company behind NServiceBus, an enterprise-grade messaging and workflow engine for. NET solutions, and they provide tools for monitoring and administration. InfoQ asked Udi about current trends in IT and in industries powered by IT, the future direction of Particular software, and the path from open source project to enterprise product.
InfoQ: What does « serverless » mean to you?
Udi Dahan: Serverless is the next-generation Platform as a Service, from a hosting and environment perspective. The main value proposition is for the smallest companies rather than the largest ones – it allows them to drastically reduce their costs for when things aren’t running. What I think is exciting about serverless is not for mainstream enterprise IT, it’s for the next generation of startups from India and China.
InfoQ: In your session at NDC Oslo, you presented a different take on microservices. What is a « microservice »?
Dahan: When people say the word « service », they’re usually referring to something that can be called remotely, over HTTP or TCP. Where I’m coming from – calling something over the network is slower than calling it in-process, and adds complexity and other concerns like security. What I’ve started to hear more of, is that microservices is an attempt from people who understood SOA to correct the mistakes of Web Services, under this new rebranding.
InfoQ: We’re seeing a lot of cross-platform drive in the. NET world, with. NET Core running on Linux and running in containers. Do you think there’s really an appetite for that in the marketplace?
Dahan: I think there’s some segmentation in the marketplace. In mid-sized organizations, maybe a 20-30 year-old organization with modest IT needs – they’re on one platform. If they’re a Windows shop, they run on Windows. I think that they don’t see the need to run cross-platform. On the startup side, startups tend to pick a platform they know. The third segment is larger enterprises, who have acquired a whole bunch of technology stacks. They’re really more of a conglomerate of a bunch of smaller organizations, but there are small pockets of environments where they have very large scale. They may want to leverage the benefits of saying we want to stick with C#, but we need to run this on a thousand servers, so the cost servings of running on Linux over Windows start to add up. But I’d say that this is not a widespread industry phenomenon.
InfoQ: What sort of problems do you see with the companies you work with at Particular?
Dahan: There are certain verticals we see a lot – retail, e-commerce, healthcare, financial services, insurance, media, telecoms. Those domains turn to us because our value proposition is more long-term, you want your systems to be reliable, to make sure they’re not losing data in the event of failure, to make sure the code remains maintainable over time. They don’t have access to the top 0.1% of developers, they’re not based in San Francisco, London or Tokyo. Their infrastructure environment is very mainstream, their focus is – with this team of developers that we have, how can we make the code we’re writing maintain the level of scale we need, stay reliable and upgrade cleanly. We solve problems for them in a practical manner, that they can deploy tomorrow.
InfoQ: If the core of that is moving to async communication with publish-subscribe messaging, what message queue systems are you seeing people use?
Dahan: MSMQ – while it’s not very popular among the cools kids – is easy to install and configure so that you don’t lose data. People may say they want to use RabbitMQ. NServiceBus supports RabbitMQ, but to set up a RabbitMQ cluster is a non-trivial thing to do, and there’s a recommendation to run it on a specific version of CentOS because that’s been tested the most. In the marketplace still lots of people are using MSMQ with a lot of success. Out in the cloud, you’re going to want to use whatever your provider has – so in Azure that’s Azure Service Bus, or Azure Storage Queues.
InfoQ: So NServiceBus is the core, and you can use whatever transport you like – what are the other parts of the Particular platform?
Dahan: NServiceBus is an abstraction on top of all these queueing systems, that allows you not to worry about retries, and transaction management and threading and how to implement long-running processes. One of the things NServiceBus provides, is if a message fails all the retries it moves it to an error queue – we have a separate process feeding off the error queue, we call it ServiceControl. ServicePulse gives a monitoring and management environment on top of those errors, where you can replay messages and have everything succeed.
The second part is auditing. Every time a message is processed successfully in NServiceBus, you have the option to take that message and put it in an audit queue. We make it so that the audit becomes valuable – the audit log contains a trail of breadcrumbs to say – this message came from that other message, which came as the result of publishing an event from that other endpoint. We ingest that into ServiceControl and make it available to our visualization tool called ServiceInsight, which can show you sequence diagrams of what actually happened in your production environment.
InfoQ: You’ve been on the path of taking NServiceBus from an open-source project to an enterprise product. What was your thinking behind that?
Dahan: The tragedy of success for most open-source projects, is that you get many more users who are sending many more bug requests and feature requests than you can handle. As an independent consultant I was spending a lot of time doing consulting and training on NServiceBus and messaging, but I couldn’t spend a lot of my time coding and adding features to NServiceBus. So progress on NServiceBus kind of slowed to a crawl. I felt that if this thing is going to continue, then there has to be a revenue stream that’s connected to fixing bugs and adding features. I felt the only path forward would be to start charging some reasonable price for licensing.

Continue reading...