Paremus ServiceFabric on EC2 – day 1
I’ve known the chaps at Paremus since shortly after they set up shop, and I’ve watched the evolution of ServiceFabric since its earliest days. Since it has all the makings of a killer PaaS offering I thought I’d sharpen up my practical cloud skills by getting it running on EC2.
The first challenge is that ServiceFabric uses multicast to communicate between nodes in the fabric, and this isn’t something supported by EC2 (or any other IaaS that I’m aware of). This isn’t a problem though, as I set up CohesiveFT’s VPNcubed, which supports multicast. It also has the side benefit of allowing me to create a network topology that spans cloud and non cloud machines, so I can throw in some boxes from my home network to try out hybrid configurations. I kept things simple, and set up a single manager for the VPN-Cubed for EC2 Free Edition, which went pretty much as described in the step by step guide.
The next stage was to create some workload, so I used Elastic Server to create an AMI that had Ubuntu 9.04 as the base, along with the VPN-Cubed client, Sun Java 6 and Paremus’s Nimble. Nimble wasn’t there already, but it was a few minutes work to upload the package and enrol it into the build system, which then created and provisioned an EC2 instance for me automatically.
Once the Nimble enabled AMI was up and running I got it connected into the VPN overlay, and started up Nimble with:
./posh -sc "repos -l springdm;add org.springframework.osgi.samples.simplewebapp@active"
I recommend giving this a go yourself if you have 5 minutes to spare – it’s a wonderful demo of dynamic provisioning.
Once Nimble had done it’s stuff it was then just a question of browsing to the http://nimble-machine-vpn-addr:8080/simple-web-app and I could see that the plumbing was working.
Snags along the way:
- Firewalls – maybe stating the obvious, but it really is crucial to get the right end points defined as being able to talk to each other, and security groups didn’t quite seem to cut it as expected.
- OpenVPN throwing its toys out of the pram over an SSL verification error because the date was wrong on one of my home VMs. This stuff is much easier to diagnose when using OpenVPN straight from the command line (openvpn vpncubed.conf) rather than via it’s daemon.
So, that’s it for day one, a working dynamically provisioned web application running within a VPN overlay network.
For day two I’m moving on to full fat ServiceFabric, and will join battle properly with multicast and VPN binding issues. Wish me luck.
Following post – Paremus ServiceFabric on EC2 days 2/3
Filed under: cloud | 4 Comments
Tags: aws, cohesiveft, ec2, elastic server, nimble, osgi, paas, paremus, sca, servicefabric, vpn, vpn cubed
Subscribe
Recent Comments
Tim Coote on Ross Anderson RIP iain on Skiing in Espace Killy (Val… Chris Swan on Getting more from a British Ga… Murray Cowell on Getting more from a British Ga… JL on AI MacGuffin 
Pinboard.in bookmarks- Commission proposes youth mobility between EU and UK
- DEA fuels moral panic over ADHD meds to justify its failed drug war
- Meta.ai Oh My!
- Looking for AI use-cases — Benedict Evans
- the biggest threat facing your team
- Why has Hugh Grant settled his phone hacking claim against the Sun?
- Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects
- AI isn't useless. But is it worth it?
- Pluralistic: The true post-cyberpunk hero is a noir forensic accountant
- Subaru battery drain due to missing 3G network
Chris Swan's Weblog 
Nice job Chris.
Relying in multicast for clustering almost always fails because so many LANs don’t support it, and it doesn’t work over WANs.
they should replace it with something like Gosspier from Cassandra
https://svn.apache.org/repos/asf/incubator/cassandra/trunk/src/java/org/apache/cassandra/gms/Gossiper.java
Thanks Bob,
The whole experience has been somewhat reminiscent of getting clustering to work on WLS 6 ;-)
I guess one of the nice things about using a VPN overlay is that once you do get multicast working on it (see day 4) then you’re no longer beholden to the vagaries of whatever you network team (or cloud) choose to support.
I’ve passed your Gosspier suggestion onto the Paremus team.
Bob,
Long time!
A couple of comments / thoughts.
One needs to be careful w.r.t. multicast. At layer II – IGMP based multicast is usually fine in the enterprise. However – as soon as you move to layer III – as you suggest – you are into a whole new level of pain. Protocol Independent Multicast (PIM) is not usually supported across the backbone etc etc.
Also whatever the group protocol – the participating endpoints must be discovered; note that Gossiper allows for multicast discovery – see synchronized void join(InetAddress from).
So local multicast discovery – used in conjunction with a ‘smart overlay’ is a good approach.
With respect to the Gossip protocol itself – it has the same advantages and disadvantages as its social namesake. No doubt useful for propagating information across an unstructured population – its current popularity is a function of Amazon’s use of it (also Astrolabe) – rather than perhaps intrinsic suitability. There are more efficient lower latency messaging approaches that may be used with ‘smart’ populations of self-organizing cloud resource.
We will be making a press release early in the New Year which touch upon this area.
Best Wishes / Merry Xmas
Richard
Hi Richard —
if the problem is non-propogation of multicast, gossiper is a solution. for some reason a lot of people seem to confuse “something like” with “definitely use,” and of course i didn’t mean it that way.
i don’t know what other problems you’re trying to solve.
–b