I mentioned earlier this week on Twitter that there was a deluge of software releases, additions and other goodies that would be released in the coming days. Earlier this week Jeremiah @peschkaj & OJ @TheColonial released the CorrugatedIron .NET Client for Riak. Big news for my .NET cohorts out there! It makes life uber easy to use Riak with. So don’t hold back if you’re in .NET land bumping up to some hard core data back end capabilities with Riak and Riak Cloud Storage.
This second release is the Amazon Web Services AMI Release. There’s been a number of customers that already use Riak & related OSS Tooling with AWS but this now makes it crazy easy to get up and running. I mean, it’s already really easy from an ops perspective, now with the .NET love and more for the dev perspective. Basho has a lot of happy for the DevOps out there – or the ops or devs if you’re still in segmented teams. 😉
For more information about the AWS AMI check out the Basho AWS Marketplace Page.
More Key Information on Distributed Options
Riak comes by default OSS but there are the additional CS & MDC options. CS stands for Cloud Storage and MDC stands for Multi-Data Center Replication. A short description of each is CS is an S3 compatible object storage that you can setup on your own machines, very powerful and built on core Riak. MDC is built to provide geographically dispersed multi-data center replication, which is kind of obvious from the name. The skinny is, MDC can help you avoid those East 1 outages that seem to plague certain non-distributed sites every year or so. If you want to learn more about these technologies feel free to message me @adron on Twitter or @adron on ADN, or fill out the standard Basho Contact Form if you want to jump right into purchasing CS or MDC.
These two options are paid for options, with Riak CS being the core OSS Offering. That you can get to try out for free, just check out the docs and they’ll point you to the places to get started or dive deep and hit the code on github.
The Amazon Web Services AMI, MDC and CS Notes
The AMI doesn’t have CS/MDC features but if you want to setup a multi-node example this is definitely the perfect starting point. In the next week I’ll also have some examples up from the perspective of setting up individual nodes and trying out the database. Shortly thereafter I’m going to dive into some much deeper distributed conversations from an architectural point of view and respectively diving in deeper with actual implementation details. So be sure to subscribe and I’ll be bringing the infos this way. Cheers!
How distributed can Riak be?
A lot of ERP Systems are multi-site. Set up on a single fat server for ‘medium big data’. When many of the users are in Asia, the Citrix box is set up in a Hong Kong office. US users access the same box (and latency is not that bad). But this limits the number of users on typical affordable client server ERP to about 300 concurrent users on single SQL server db (more due to the locking scheme employed by the ERP client).
Running the same ERP application, another larger company ends up with about 10 servers (all on premise) supporting about 2100 users (again 300 seats limits any one ERP administration instance). Locations use a common item master. NY, FL, OR, Ireland, Netherlands, Indonesia, Vietnam, China (x2), Hong Kong. Synchronized hourly, daily or sometimes weekly depending how the ETL jobs run ok (about 25 percent of jobs fail).
What would be much cleaner is if the database could automate selective synchronization of about 6 tables on each instance out of about 80 tables. Real-time sync is not really required because users time zones are following the sun and cross the date line. Reliability, predictability and the ability to automate is turning far more crucial because inventory demand is converting to direct demand via the web (not a sales forecast). Generally factories in Asia supply the locations in the EU/US.
Glad you asked about Riak. I’ve got that answer coming in some following blog entries. 😉
As for that Citrix + ERP + distribution architectures, sounds like some interesting situations. One of the biggest bottle necks to me sounds like the nefarious seat limitation. That isn’t even a hard limit on reality… 🙁
Nefarious indeed. Yet many of worlds ERP apps were architected following common Windows client server patterns and practices and are still widely deployed. Fat client, beefy server, opens 6 to 24 connections, performs optimistic locking. Upgrading to latest SQL server makes little difference.
The core ERP apps need rewriting for distributed databases capable of handing direct demand via the web; for teams of people collaborating together in geographically distributed locations. Looking forward to the coming blog entries.
Oh heck yeah, that’d be a good project to be on! Getting the world caught up with itself! 😉