Welcome Guest! To enable all features please Login or Register.



Hosted Gridnodes
#1 Posted : Sunday, October 2, 2016 9:07:11 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 10/28/2014(UTC)
Posts: 49
Location: United Kingdom

Thanks: 4 times
Was thanked: 4 time(s) in 4 post(s)
Hi all,

We use NCrunch pretty much exclusively in Gridnode only mode (so tests aren't run locally). To do this we have a small cluster of nodes configured to accept requests. Obviously with the overhead of building the solution multiple times (as each node compiles the code itself) we've found that larger nodes are more efficient than smaller ones. One thing we are looking at is the possibility of configuring fewer larger servers to do the processing. This, combined with the 'cloud' in general, brought us on to an idea about having a 'hosted' version of NCrunch Gridnodes. The idea would be that a monthly fee would be charged and, for that, you'd get time-shared slot on a large server for your processing. Initially, it would probably only support basic
tests, so no SQL instances or other dependencies but these could be added later.

The main considerations we'd have are around the area of security. We would isolate the processes so that it would not be possible to interfere or observe anyone else's NCrunch session. We would also look at limiting outbound connections from the service so that it could not be used to conduct attacks. It would probably have to come down to trust that we would not look at the source code that came through the system (the same way that you trust any 'cloud' provider with your data).

Does this sound like something anyone would be interested in? Also, as a question for Remco: would you be OK with us trialling a service like this? We'd be happy to make it clear that we're a third party.

#2 Posted : Sunday, October 2, 2016 12:09:28 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,373

Thanks: 705 times
Was thanked: 878 time(s) in 835 post(s)
Hi Matthew,

This is an idea that has received some attention in the past. It was actually a business model I considered pursuing when designing the distributed processing. I eventually rejected it for several reasons. A few people have since approached me with the idea asking my opinion about it. So far, as far as I know, no one has yet implemented it.

My reasons for not taking the distributed processing in this direction are as follows:

- Trust issues. As you've identified, there needs to be considerable trust between the provider and the customer for such a service to work. Or at least, very sophisticated systems to prevent a customer from damaging the service or performing illegal activities.

- Investment. Such a service would require quite a bit of investment to make it into a tidy package that could easily be used. This may or may not involve further development of NCrunch itself. Basically, it would need to be a serious project handled with controlled costing etc.

- Liability. The legal risk of setting up such a service would need to be explored in a great deal of detail. If the service were to operate internationally, this would be very complex as you may be exposed to many different regulatory environments.

- Appliance. Unfortunately, most of NCrunch's users never touch distributed processing. I can only assume that multi-core for them is fast enough, or they use it only for unit testing. Distributed processing will likely continue to be a niche but high value feature of the product.

- Complexity:
This is the big one. As developers we tend to underestimate the environmental complexity of projects that we aren't directly involved in. It's natural to expect that on our first day on the job, we should be able to check out source code from a repository and be able to build the solution with minimal effort. If NCrunch has taught me one thing, it's that development environments can be infinitely complex in ways that can never be accurately guessed or assumed up-front. When NCrunch was first released, it was free of defects from every angle I'd thought to test it. It had been thrashed for over a year in real world environments, and I thought it was ready. As soon as it hit the real world, I then spent the next 18 months picking up on every crazy unexpected detail that I had never known about or even imagined could exist. The size of the .NET tool stack is immense, and it is moving at breakneck speed. There is no telling just what people are doing with their tests or what sort of dependencies their code has.

When you provide developers with a well tested product that behaves in a (mostly) predictable fashion, they are usually very effective at finding ways to use this product and configuring it for their own environment. As soon as you stop treating it as a product and start treating it as a service, you take on much more responsibility for that environmental complexity. For such a service to be worth paying for, you would need to commoditise these environments and try to find configurations that will work with minimal effort from your users. I expect that the support overhead of such a service would be very high.

Finally, it's worth being aware that the tests most likely in need of grid distribution are complex tests with external dependencies. Most external dependencies would be hard to provide with commodity environments.

My personal belief is that it just isn't worth it. When you weigh up the costs, the risk, and the payoff, I don't think such a service would be profitable.
#3 Posted : Thursday, October 6, 2016 12:37:29 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 10/28/2014(UTC)
Posts: 49
Location: United Kingdom

Thanks: 4 times
Was thanked: 4 time(s) in 4 post(s)
Hi Remco, Thanks for the detailed response. I'd taken most of your points into consideration individually, but hadn't really weighed them all together. It's something that I may toy with the functionality of while setting up our own cluster. One of the reasons that I thought it would be useful for the tests without external dependencies is keeping the fast tests fast. I know there's an option for pipelining etc in the product, but one of the things that we've found when setting up our small cluster (3 nodes) so far is that if we make one of them run our tests with external dependencies and 2 of them just run traditional unit tests then it means everyone gets a smooth process compared to all 3 of them being capable of integration tests. This is because the 2 nodes serve more of the team as opposed to getting stuck on the bigger tests.

We'll probably wait until Windows Containers hits GA and try again then. That should provide the amount of isolation required (without too much overhead) for processing
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.059 seconds.