Blog & Ideas
Our ideas and plans for the future.

Sections

Geruchten over een Slankere Microsoft Xbox One

Date: 13-6-2016
Author: Team BizFusion

Geruchten over een Slankere Microsoft Xbox One


Vandaag, 13 juni 2016, begint E3!

Wat kunnen we deze E3 verwachten? Er is al het één en ander uitgelekt.
Microsoft zal een nieuwe “slankere” versie van de Xbox One aankondigen: de Xbox One “Slim”.
De nieuwe console zal maar liefst 40% dunner zijn!

Red Ring of Death
Maar laten we alsjeblieft niet vergeten waarom de huidige versie van de Xbox One zo groot is.
De Xbox 360 was een krachtige computer in een hele kleine behuizing, en dit zorgde voor oververhitting
van de machine. Gebruikers met dit probleem kregen de beroemde (gehate) “Red Ring of Death”
(RROD) foutmelding.
Microsoft was gedwongen om alle defecte machines terug te halen en dit zorgde voor een
gigantische financiële strop voor Microsoft. Bij de creatie van de Xbox One namen de ontwerpers dus
geen enkel risico, ze kozen voor een grote behuizing met een grote ventilator.

Als de nieuwe slankere versie van de Xbox One ook tot oververhitting leidt, dan is het einde oefening
voor de hele Xbox divisie. De CEO van Microsoft, Satia Nadella, is een compleet andere CEO dan Steve
Balmer. Balmer durfde risico’s te nemen en gaf de Xbox divisie zelfs een blanco cheque om de
problemen met de Xbox 360 op te lossen. Maar Satia Nadella is niet bereid om eindeloos geld te
stoppen in divisies die niet bijdragen aan de winstgevendheid van de onderneming.

Uitstapje: maar waarom heeft hij de Bing divisie dan nooit opgeheven? Satia heeft een lange tijd bij deze
divisie gezeten, dus hij ziet deze divisie vast als zijn kindje. Verder weten we dat de Bing divisie eindelijk
winst maakt, dus deze divisie is veilig.

Maar de Xbox divisie zit in het hondenhok door de Xbox 360, en Nadella gaat echt geen blanco cheque
uitschrijven om ze uit de problemen te helpen. Tel daar nog eens bij op dat Sony een onoverbrugbare
voorsprong heeft op Microsoft, en je komt tot de conclusie dat ze de slankere versie van de Xbox One
beter niet kunnen uitbrengen. Waarom zou je het risico van een nieuwe Red Ring nemen?
Trouwens, was er überhaupt vraag vanuit de markt naar een kleinere Xbox One? Ik denk het niet.

Tot Slot
Gaat de nieuwe slankere versie van de Xbox One de doodsteek voor de Xbox divisie worden?
Ik durf bijna te gokken van wel. Microsoft is niet sterk in hardware en daarom is de Xbox One “Slim”
gewoon dom.



Weird Multi Tenant Software Architecture

Date: 1-6-2013
Author: S. Ramasray

Weird Multi Tenant Software Architecture


Software developers are pretty creative people, but sometimes, their creativity leads to truly bizarre
software architectures. We wrote a bit about our multi tenant architecture in the past, but it feels like
it’s time to do another post on the subject.


Isolated Database
BizFusion is an online accounting solution for small and medium sized businesses.
Each business that signs up with BizFusion gets its own database.
This is a completely isolated database. That’s an important distinction to make when comparing the
software architecture of BizFusion with other business software that’s in the market.

BizFusion is basically a single application that sits on top of a bunch of separate company databases.
Single business applications that can accommodate multiple companies/tenants are called
‘Multi Tenant’ applications (MTA). This is not something new; ERP vendors have been creating these
types of applications for years.

Software developers generally use two approaches when creating a multi tenant application.

Design Choice 1: Single Application + Single Database
A lot of ERP vendors choose this design. They create a single ERP application that sits on top of a
single database. The data of all their tenants/customers is stored in this single database.
This design choice is popular, because it’s simple to design and maintain.

However, this model does have one big drawback. All your tenants’ data is intermingled in this big
database. So you need some way to distinguish the data of tenant A with that of tenant B.
This is often done by adding a specific ‘TENANT KEY’ to each row in the database.
E.g. each invoice record has a tenant key that specifies that the row belongs to tenant A or tenant B.

We’re not very fond of this solution. This approach assumes/requires that the programmer includes
the right key for each database operation. But programmers are not infallible, that’s why we never
liked this solution. There’s always this nagging feeling in the back of your mind that a bug might
cause the wrong database records to be updated. The shit hits the fan when/if this happens.

Using a single database can also cause performance penalties when the database becomes big.
Inserting and updating records lead to updates of table indexes. This can negatively impact
performance. It’s true that most database operations are read operations, but most online
accounting solutions cater to thousands of concurrent users, that’s why there’s always an insert
operation happening.

Design Choice 2: Single Application + Multiple Database
This was the design choice of BizFusion. We chose this option, because we didn’t want the risk of
mixing up tenant/customer data in our system. Hell, we’re dealing with financial data here, that’s
why it’s our duty to create a system that excludes this possibility.
Each business that signs up with us, get its own database. This database is ‘physically’ isolated from
all other company/tenant data. Your company’s records can never be mixed up with the records of
another tenant!

A lot of other vendors don’t like this option, because these systems are harder to maintain.
We have to update several thousand databases whenever a new release of BizFusion requires a
database upgrade. You only have to update a single database with the single database setup.
That’s why we created a database upgrade tool to do this work for us.
It still takes a while to update all of our databases. That’s the real downside of this design choice.

You don’t suffer the performance penalty of the single database approach with this solution.
Most SMB companies have very little data. That’s why their database tables are small.
This creates very little overhead when inserting and updating data.
We have a lot of users, but they’re never logged in at the same time.
That’s why memory utilization is very low.
But there’s another very big advantage to using an isolated database per customer/tenant.
Scalability!

Scalability
Multiple isolated databases enable you to easily scale to multiple servers.
This is especially critical for internet applications. If your application becomes popular, then a lot of
users will be pounding your database server. Some of your customers/tenants may ask (even
demand) that you provide a separate server just for them.

It’s difficult to move the data from company/tenant A into a separate database if you’re working with
a single database model. It’s not impossible, but you need to develop a custom tool to make this
process possible. If you have an isolated database model, then moving databases to another server
becomes trivial. It’s almost as easy as copy and paste.

Weird Alternatives
Most companies choose one of the two described approaches. The single application + plus single
database model is very popular. But we have also heard of other design choices, choices that are
simply put: bizarre.

Weird Design Choice 1: Per Company Database Table
You have a single database in this setup, but each of your tenants get a separate set of tables within
this database. That means that tenant A gets an invoice table called TENANT_A_INVOICES and
tenant B gets an invoice table called TENANT_B_INVOICES.

This design choice tries to merge the best of the previously mentioned approaches, but fails
miserably in the end. There’s only one database, so backup/upgrade of the database is very easy.
However, upgrading the database is not easy. You need to update all the separate tables in the
database. This is the same problem that you have with multiple isolated databases. So you need to
write a custom tool to handle the update.

You also don’t have a true isolated design, because you could still potentially specify the wrong
database table in certain database operations. But the chance of mixing data from multiple tenants is
excluded in this setup. You can never link an invoice of tenant A to a client of tenant B.

But this is the craziest design choice that we’ve encountered to date. The number of database tables
“explodes” when your application gains any traction. And let’s be real here, online business
applications are not meant for only a few hundred users, they should be able to handle several
thousand users/tenants.

We only know of one company that used this design choice and you will never guess who it is.
It’s Fresh Books! The guys at Fresh Books openly wrote about this design choice in a blog post.
We applaud them for sharing this information. There are only a few software companies that
openly write about their software development process and even less that write about the design
“fuck ups” that they made. Hell, we pride ourselves on being open, but we won’t detail major design
errors like this.

Fresh Books has recently switched over to a “single application + single database” approach. It must
have been a true nightmare to maintain their previous system. Any other software developer would
have started from scratch, but Fresh Books is a popular online solution, so they were forced to
gradually move over to a workable MTA architecture.

Weird Design Choice 2: Multiple Application Instances + Multiple Databases
This is not a true multi tenant solution. Companies that follow this approach disagree with us on that.
They see their servers/hardware as a single platform that can be used by multiple tenants.
The fact that they have a separate application per tenant makes this a “fake” multi tenant solution.

There’s no maintenance benefit that you can achieve with this approach. If you need to release a
new version of your application, then you need to update all separate instances of your application.
The same goes for your databases. You need to write a custom tool to update all of the separate
instances of your application. This was the hell that developers had to go through in the past and it
was the catalyst for developing ‘real’ multi tenant solutions.

Wrap Up
Every developer wonders if the design choices that he made will haunt him in the future.
We’re always confronted with a set of constraints whenever we design and implement an
application. Time, money and technical experience affect the eventual solution that we deliver.
BizFusion was created in a very short period of time and on a strict budget.
The first version of BizFusion was created in less than a year. We had created several accounting
system prototypes in the past. That’s why we were confident that we could deliver a working
accounting solution that could rival the offerings of our competitors.

Sailesh Ramasray
Founder / Developer BizFusion



Dare To Ask

Date: 3-3-2013
Author: S. Ramasray

Dare To Ask


I always listen to “Hansel Minutes”, it’s a show about Microsoft Technology and it’s hosted by Scott
Hanselman. A while back, Scott talked about a conversation he once had with a developer.
During the conversation, the other developer mentioned the word “Cardinality”.
Scott didn’t know what that word meant. His professor may have explained it way back in college,
but college was a distant memory. So he asked the developer what it meant.
Scott could see that the developer was surprised that an “expert” like him didn’t know what it
meant, and that developer probably thought less of him because of this “nooby” question.

That brought the Hansel Minutes conversation to “Dare to Ask”. There are a lot of people that don’t
ask any questions, because they fear that they will be seen as stupid.
But what’s more stupid, not knowing something, or not daring to ask something.
As developers, we’re expected to know everything, but the simple fact is that we will never reach the
level of expertise that is often expected of us. It’s simply impossible to know everything.

Scott could have Googled the word cardinality after the meeting, but he did something far more
interesting. He dared to ask. This takes courage, because you can be easily shot down for not
knowing something, but it’s also an opportunity to see how your colleagues tick. If your colleague
helps you out and “truly” encourages you to keep asking your “nooby” questions, regardless of who
you are, then you’re a lucky guy. You landed a job in an environment where “dare to ask” is not just
some hollow sentence, but something that people really believe in.

Did I have a similar experience like Scott? Yep. A colleague of mine suggested that I use Excel to solve
a particular programming challenge. He said that my particular problem could be solved by using the
VLOOKUP function. I totally blanked on the VLOOKUP function, haha. It’s been years since I last used
Excel, so it’s not weird that this isn’t readily available knowledge. But I could clearly see that he was
surprised that I didn’t know this basic stuff.

Wrap Up
The only thing we have to fear is fear itself. So develop a dare to ask mentality and you will be
surprised to see how many of your colleagues are willing to help you out. It’s simply because we’ve
all had a similar experience like the one that Scott described.

Sailesh Ramasray
Founder / Developer BizFusion





Older Posts           Archive