Question

Challenging the multi-app environment

0

Few weeks ago I joined this meeting on the ‘multi-app environment’: one application was split into about six different apps. The arguments presented were: 1. maintainability – smaller apps are easier to maintain; 2. performance – smaller apps have smaller databases therefore performance is better; 3. continuity – if one app is down, the whole application need not be down. Now, a few weeks later, I wonder whether these arguments are always valid. I fear that in many environments these arguments can be questioned. Maintainability: the Mendix model allows one app to be split into several modules. This approach offers the same advantages as split into several apps? Performance: most database management systems contain intelligence to split files and tables into several parts and store these on (different parts of) different disks. 30 years ago it was already advised to developers to NOT split database because databases can and will do this better. Even different databases are managed within one big datapool by one databasemanagement-instance nowadays. I wonder whether the performance arguments hold. Continuity: this argument certainly holds if the apps have no connection at all. However, in this case they would not be have been combined in the first place! Hardware failure also is not an issue, because shadow environments and replication are common processes in modern datacenters – so if there is a hardware failure the app keeps on running somewhere else. The only reason an app can really be down is because the software itself is not reliable. In that case the software testing and deployment process has a bug and the real question is: how to assure the quality of other apps and the quality of features that cover downage of the other apps. In financial companies the only possible decision is: if one is app down, the others have to shut down also – because of contingency and integrity and auditability requirements. So, it is still not very clear to me why one would consider to split óne app into multiple apps. It seems to me it will create less performance and more risks

asked 2017-01-09

Gerard Veurink

4 answers

Christiaan Westgeest · Answer 1 · 2017-01-10

A very fair question. I would say the answer depends entirely on your circumstances (because when doesn't it?).

If you're building an app that does a few very interrelated things, say: an app where a user can request a mortgage and manage his/her outstanding mortgages, and where back-end users can take these mortgages through the request-workflow.
That's one app. I can see no reason whatsoever to split it up.

However, I've also worked on an app in the past that'd grown to encompass around 40 modules and did so many different things it became hard to keep track of it all. An app like that becomes hard to maintain. If you want to do a proper regression test before a new release (as you should), that becomes a *lot* of work, even with partial automated testing. In addition, if a new developer or ops-engineer would join the team, it'd take forever to get him/her up to speed. Even the core team had a hard time overseeing the whole thing.
It's an extreme example, of course, but somewhere between a simple, straightforward app and a monster like that, lies a cut-off point where you should really consider splitting up.

It may also depend on your available (human) resources. If you're building an application that is going to provide access to a number of very different products or services and you have the resources to form a specialized team for each of these, it might be quite powerful to create separate apps, tied together through an orchestration app and making use of shared central resources (SSO, masterdata, etc).

You can then develop, release and maintain in parallel. In addition, the separate apps are more compact and easier to oversee. Also bugs in one application don't impact the greater system.

Nevertheless, so far I've only occassionally run into a situation where I would make a solid case for going multi-app, so perhaps I'm also overlooking additional advantages.

(Apologies if I repeated points for the workshop, I didn't attend)

Martin van Es · Answer 2 · 2017-01-09

Hi Gerard,

We are in the process of evaluating Mendix, and we had the exact same thoughts. We heard the same arguments why we should consider splitting up the application into smaller separate applications.

I totaly agree with your arguments against this, and just use one big application. Indeed if you structure your application good, and use a good separation into modules, I think it can be very good to maintain. And since all oure modules have links to other modules, having them all in one application makes it a lot easier to maintain in stead of creating and maintaining all the cross app connectors.

And since all of oure modules are connected to other modules, the continuity issue will always be there. Even if they are in separate apps. If you update one app, it has some down time, but during this downtime all the connections are down to. So the other apps will suffer also. In fact, since part of them will be up and some parts which use the connections are down, it only makes it less clear to the end user.

The only reason I can come up with right now is security. If you physically split up the apps, it won't be possible for users of one app to reach unwanted pages or data in a other app. But if you have your security rules in order, this should not be a problem when building everything in one app also.

I'm really curious if there are some other good arguments for using separate apps over one big app.

Pieter van de Braak · Answer 3 · 2017-01-10

Another reason I did not see here yet is best of breed. If you keep your apps small and let them handle core functions only it becomes easier to replace them when a better app come along. This allows you to use the best app for the job. Be it developed in mendix or one right of the shelves.

Martin van Es · Answer 4 · 2017-01-11

Another point not yet taken in considderation in this discussion is "costs". All pro's and con's discussed are from a technical point of view. Which is also the first thing to look at ofcourse, but if splitting up in multiple apps is technically a better way to go, then costs come into play also.

Maybe this isn't a issue for some bigger users, but for a smaller company this might be a big issue. Splitting one big application into several smaller apps greatly increases yearly mendix subscriptions.