New strength for Continuent

It is public news now that Continuent has three new hires. I am particularly pleased with the news, as we are improving the team in three different directions:

• Services and management, with Ronald Bradford, with whom we have crossed paths several times, first in the MySQL community activities, then as colleagues at MySQL AB, and again in community cyberspace.
• Development, with Ludovic Launer, a senior developer with a long experience in development and software architecture. This is an excellent injection of new blood for our development team.
• Sales, with Robert Noyes, who has worked in enterprise sales for 25 years, and comes at the right moment to reinforce our business in the moment of its biggest growth that I have seen since I joined the company.

Welcome to our new colleagues!

Replication stars

Working with replication, you come across many topologies, some of them sound and established, some of them less so, and some of them still in the realm of the hopeless wishes. I have been working with replication for almost 10 years now, and my wish list grew quite big during this time. In the last 12 months, though, while working at Continuent, some of the topologies that I wanted to work with have moved from the cloud of wishful thinking to the firm land of things that happen. My quest for star replication starts with the most common topology. One master, many slaves.

Fig 1. Master/Slave topology

Legend

It looks like a star, with the rays extending from the master to the slaves. This is the basis of most of the replication going on mostly everywhere nowadays, and it has few surprises. Setting aside the problems related to failing over and switching between nodes, which I will examine in another post, let's move to another star.

Fig 2. Fan-in slave, or multiple sources

The multiple source replication, also known as fan-in topology, has several masters that replicate to the same slave. For years, this has been forbidden territory for me. But Tungsten Replicator allows you to create multiple source topologies easily. This is kind of uni-directional, though. I am also interested in topologies where I have more than one master, and I can retrieve data from multiple points.

Fig 3. all-to-all three nodes

Fig 4. All-to-all four nodes

Tungsten Multi-Master Installation solves this problem. It allows me to create topologies where every node replicates to every other node. Looking at the three-node scheme, it appears a straightforward solution. When we add one node, though, we see that the amount of network traffic grows quite a lot. The double sided arrows mean that there is a replication service at each end of the line, and two open data channels. When we move from three nodes to four, we double the replication services and the channels needed to sustain the scheme. For several months, I was content with this. I thought: it is heavy, but it works, and it's way more than what you can do with native replication, especially if you consider that you can have a practical way of preventing conflicts using Shard Filters. But that was not enough. Something kept gnawing at me, and from time to time I experimented with Tungsten Replicator huge flexibility to create new topologies. But the star kept eluding me. Until … Until, guess what? a customer asked for it. The problem suddenly ceased to be a personal whim, and it became a business opportunity. Instead of looking at the issue in the idle way I often think about technology, I went at it with practical determination. What failed when I was experimenting in my free time was that either the pieces did not glue together the way I wanted, or I got an endless loop. Tungsten Replicator has a set of components that are conceptually simple. You deploy a pipeline between two points, open the tap, and data starts flowing in one direction. Even with multiple masters replication, the principle is the same. You deploy many pipes, and each one has one purpose only.

Fig 5. All-masters star topology

In the star topology, however, you need to open more taps, but not too many, as you need to avoid the data looping around. The recipe, as it turned out, is to create a set of bi-directional replication systems, where you enable the central node slave services to get changes only from a specific master, and the slave services on the peripheral nodes to accept changes from any master. It was as simple as that. There are, of course, benefits and drawbacks with a star topology, compared to a all-replicate-to-all design. In the star topology, we create a single point of failure. If the central node fails, replication stops, and the central node needs to be replaced. Instead, the all-to-all design has no weaknesses. Its abundance of connections makes sure that, if a node fails, the system continues working without any intervention. There is no need for fail-over.

Fig 6. extending an all-to-all topology

Fig 7. Extending a star topology

However, there is a huge benefit in the node management. If you need to add a new node, it costs two services and two connections, while the same operation in the all-to-all replication costs 8 services and 8 connections. With the implementation of this topology, a new challenge has arisen. While conflict prevention by sharding is still possible, this is not the kind of scenario where you want to apply it. We have another conflict prevention mechanism in mind, and this new topology is a good occasion make it happen. YMMV. I like the additional choice. There are cases where a all-replicate-to-all topology is still the best option, and there are cases where a star topology is more advisable.

More on the open core : the pragmatic view

I joined the number of those who have a public opinion on the open core debate. Roberto Galoppini has graciously accepted to host a post on this topic in his Commercial Open Source Software blog. Please read it directly from there: Open to the core - The pragmatic freedom Enjoy!

Free software and business in Sardinia

On June 10th and 11th I attended two interesting workshops, both related to the Italian Free Software conference, and both organized by private institutions that have expanded their boundaries and created two quite lively international events.

The first event was held near Pula, in an innovation laboratory encased in a beautiful forest. The Technological Park of Sardegna Ricerche is a place where research and business boil together to produce new companies and to help consolidate existing ones.
The workshop was titled A community for a new business model and it was a show case of a dozen companies, both local and from abroad. After the presentations and a lovely open air lunch, there were 1-to-1 20 minutes meetings between companies, to dive deeper in technologies, ideas, and friendships. I must say that I enjoyed the event, not only because my presentation on MySQL community and values was quite well received, but also because I met interesting people and found some new ideas that need further exploration.
The main event, the fourth Italian free software conference, was not as exciting. The organizers decided to paint the event with local colors only, thus making it less interesting for me, as my job takes me around more abroad than in my own country. Oh' well. It's the Italian conference after all, and it has the right of being an all-Italian show. IMO, it's a pity, though. Exposure to external ideas is often beneficial, and I would have welcomed at least some openness beyond the national boundaries.
Anyway, the show was rescued by another workshop, organized by a local company, which was not afraid of venturing in international waters. The company is named Tzente, which means People in Sardinian, and true to their name they brought to the event several international companies, with Italian and foreign speakers. Also this event was very lively and interesting.
The hosts (Tzente) are a company to keep an eye on. They produce an open source software, called Java Agile Portal System or jAPS for short. In spite of the name, jAPS is much more than a portal. It's an integrated and versatile system to automate companies and public organizations. Their business model is simple: give the components away for free, thus building a community of users and testers, and sell integration and customization services either directly or through partners. Compared to many other startups, Tzente has a distinct advantage over the competition. They have customers. Not only they produce an excellent open source product, but their monetization strategy has already brought them large customers in Italy and abroad. They have partnerships with well known names (among which MySQL, Pentaho, Ingres, Red Hat) and I think they are going to grow fast. Good job, Tzente!
A personal note. At the first workshop I did my presentation in English, and I felt very comfortable. At the second workshop, I did the same presentation in Italian. I had the feeling that the English version was more effective. Probably I am traveling too much.

stupid things you can do to kill your business

This summary is not available. Please click here to view the post.