ThoughtWorks Tech Radar is out

Development
1

Hi All,

The latest issue of the ThoughtWorks Technology Radar http://www.thoughtworks.com/radar is out.

If you haven’t heard of it:

“The radar is a document that sets out the changes that we think are currently interesting in software development - things in motion that we think you should pay attention to and consider using in your projects. It reflects the idiosyncratic opinion of a bunch of senior technologists based on our day-to-day work and experiences. While we think this is interesting, it should not be taken as a deep market analysis.”

It’s invaluable as a public resource for keeping up on the latest trends, and learning about up and coming technologies and techniques.

This issue has a heavy focus on cloud technologies that have limited direct relevance to us at OpenMRS at this point. But there’s still a lot of good stuff. A few interesting tidbits:

Hold: Application Servers http://www.thoughtworks.com/radar/platforms/application-servers

Easier automation, easier deployment and a reduction in the amount of infrastructure you have to manage lead us to recommend embedded servers over application servers for future projects.

We should consider ditching OpenMRS Standalone as currently implemented, and approaching this with a simpler “embedded jetty” model.

Assess: Ember.js http://www.thoughtworks.com/radar/languages-and-frameworks/ember-js (as an alternative to AngularJS) Not something we’re going to do right now, but something we should know about for the long-term, as we decide whether to bet on AngularJS, Web Components, or something else for the next few years.

Postman http://www.thoughtworks.com/radar/tools/postman as a recommended Chrome extensions for REST testing. A couple Swagger http://www.thoughtworks.com/radar/tools/swagger alternatives mentioned by name.

There’s lots more. You should read it all yourself. :slight_smile:

5 Likes
2

I like this radar a lot. Thanks Darius for the link. :slight_smile:

Regarding the use of a simpler embedded jetty model, do you simply mean replacing the currently embedded tomcat with jetty?

3

I was thinking that we should explore the idea of not actually having a standalone as a different thing, but that the regular OpenMRS distribution is “runnable” and it fires up an embedded jetty.

I don’t know if it’s a good idea, I’ve spend less than a minute thinking about it. :slight_smile:

(Obviously embedding the database is trickier.)

4

Atlassian’s evolution to convention over configuration:

  1. Ship a war file.
  2. Create standalone (embedded server) as a toy, war file is still king.
  3. Standalone matures to the point it becomes king, war file still supported.
  4. Everyone uses standalone, upgrades are automated, war file is discouraged.

I figured we could walk that same path. In other words, we switch to the standalone when it’s obvious we should switch to the standalone (i.e., the standalone is as robust or more robust for production usage than manually installing the war file). I don’t think we get there by saying we’re switching to using the standalone; rather, we follow Atlassian’s path, continuing to put energy into improving on the standalone until it earns the right to be king.

5

FYI, this has been the case for at least 5 years now at Atlassian, and is the only route OpenMRS has ever gone in implementing their products.

6

We should definitely always provide the WAR. We don’t want to preclude any deployment approaches that people might want.

Let me rephrase: our standalone is really nifty, but with the benefit of hindsight, it is not built on the right technologies for the future. (e.g. a Swing UI, and the MySQL/MXJ connector that was discontinued in 2011).

It would be worth reimagining this from scratch as a tiny HTML+JS webapp with a runnable embedded jetty, and MariaDB4J https://github.com/vorburger/MariaDB4j (need to verify that licensing of this is actually legit).

1 Like
7

I think MariaDB4j should be fine since it is Apache License, Version 2.0 @Darius, do you have any reason why you prefer embedded Jetty to Embedded Tomcat?

8

My question about MariaDB4J is whether it is itself legitimately redistributing MariaDB binaries. (I presume yes, but I haven’t checked.)

I always assumed that Jetty is lighter-weight than Tomcat, is easier to embed, and might perform better on the sort of low-end hardware where you’d run the standalone. But this is a completely uninformed assumption, and I have absolutely nothing to back it up.

9

According to https://github.com/vorburger/MariaDB4j/issues/14 What they do is: include a NOTICE file explaining any of these 3p dependencies with incompatible licenses.

1 Like
10

Michael Vorburger is an OpenMRS friend through his work on Mifos and would surely be happy to answer questions should we need them answered.

11

Burke is correct about the path to standalone products at Atlassian.

As far as the tale goes, JIRA used to be supported in a lot of different containers (proof: https://downloads.atlassian.com/software/jira/docs/v2.1/). This led to all sorts of problems, it was hard to diagnose issues, hard to test in all platforms, hard to set up correctly all containers. One by one the containers support were removed, because it was hard to customers to choose a container, hard for support, hard to develop, test and maintain.

But there was other problems. During upgrades of tomcat, products would break due to unsuspected reasons: duplicated libraries, incompatible jars using resources not yet available, different configurations, lack of -server flag to java, and so on. Also, you have security upgrades of tomcat, something your customers don’t need to care anymore if you have a standalone.

WAR is now considered a legacy thing. Newer projects, like Stash, didn’t even offer that in the first place; I’ve heard it’s an architectural decision, as one could decide to split stash in several different wars or any other type of architecture, and the customers wouldn’t be affected.

About Jetty and Tomcat, I’ve seen several different comments. Depending of your project and how it’s used, Jetty can be faster than Tomcat. Sometimes, it will be the opposite due to the way Tomcat caches resources. It’s something that needs to be tested and monitored case by case; Jetty supposedly can have a smaller memory fingerprint too, but version of Java can impact more than everything else. Also Tomcat security problems are treated very very quickly.

Bamboo moved away from Jetty to Tomcat due to very hard to diagnose and weird bugs, related to performances in some Windows machines, AJP bugs and other hard core issues.

From the licensing perspective, it’s both fine to ship Tomcat/Jetty and JDK with your standalone - even if it’s proprietary. The only thing we had to remove was the MySQL jdbc driver, as it was GPL. We ship the license files for Tomcat, as any other dependencies we bundle. Install4j is used to create the installers. But if I have just one suggestion, is this: creating a JRE for Windows 32 with -server capability is a nightmare. Avoid creating a 32 bits windows installer. You won’t regret.

1 Like
12

As an admin, this was always really annoying BTW because we had to go out and find it during the install process. I imagine it’d be just as annoying if we asked our customers to do it.

I will withhold any licensing opinions because I’m not a lawyer. :slight_smile:

13

Well, yes. It’s boring.

But for that it’s worth, it’s only MySQL. Others drivers have more permissive licenses (even oracle driver!). As well, IMNAL, if OpenMRS decide to support MySQL I suppose it’s something we can ask FSF.