Trifork Blog

Posts by Eike Dehling

Heterogeneous microservices

July 13th, 2017 by
(https://blog.trifork.com/2017/07/13/heterogeneous-microservices/)

Heterogeneous microservices

Microservices architecture is increasingly popular nowadays. One of the promises is flexibility and easier working in larger organizations by reducing the amount of communication and coordination between teams. The thinking is, teams have their own service(s) and don’t depend on other teams, meaning they can work independently, thereby reducing coordination efforts.

Especially with multiple teams and multiple services per team, this can mean there are quite a few services with quite different usage. Different teams can have different technology preferences, for example because they are more familiar with the one or the other. Similar different usage can mean quite different requirements, which might be easier to fulfill with the one or the other technology.

The question I’m going to discuss in this blog post, how free or constrained should technology choices be in such an environment?

Spaghetti freedom

If you’ve ever worked in a hectic startup environment where quickly building features is more important than clean sustainable code, you probably know how that ends. People just build things and it all becomes a big spaghetti mess. There is lots of technical debt..

The combination of freedom and high pressure means choices are short-term focussed and there is little attention to keeping things tidy.

Over-standardization

Large organizations can have the opposite policy, any project or change need to be approved by multiple boards, architects and committees. There are strict rules about exactly what technologies should be used.

This can mean there might be some shoe-horning to implement things with a sub-optimal technology, or over engineering because complex technology is used for simple problems.

This can also be de-motivating to engineers, as they’re not allowed to pick their favorite technology.

Inspire!

I think the right approach is a middle ground. Some standardization and preferred languages, frameworks and solutions are very helpfull to promote software being built the same way. This helps engineers working on new services, for example when switching teams or when onboarding new people.

I think this preferred way of working should evolve also and be open for discussion. New insights or new ways of building can be integrated if they prove beneficial.

In my opinion such a preferred approach should serve as a starting point for teams building new services and be open for discussion. Teams should try and build software in a common way, but when needed it should be fine to diverge and do things differently.

Concluding

I’ve shared my opinion – how can technology be standardized in larger microservice environments. How does this work in your company? What’s your insight on this topic?

Machine Learning: Predicting house prices

February 16th, 2017 by
(https://blog.trifork.com/2017/02/16/machine-learning-predicting-house-prices/)

Recently I have followed an online course on machine learning to understand the current hype better. As with any subject though, only practice makes perfect, so i was looking to apply this new knowledge.

While looking to sell my house I found that would be a nice opportunity: Check if the prices a real estate agents estimates are in line with what the data suggests.

Linear regression algorithm should be a nice algorithm here, this algorithm will try to find the best linear prediction (y = a + bx1 + cx2 ; y = prediction, x1,x2 = variables). So, for example, this algorithm can estimate a price per square meter floor space or price per square meter of garden. For a more detailed explanation, check out the wikipedia page.

In the Netherlands funda is the main website for selling your house, so I have started by collecting some data, I used data on the 50 houses closest to my house. I’ve excluded apartments to try and limit data to properties similar to my house. For each house I collected the advertised price, usable floor space, lot size, number of (bed)rooms, type of house (row-house, corner-house, or detached) and year of construction (..-1930, 1931-1940, 1941-1950, 1950-1960, etc). These are the (easily available) variables I expected would influence house price the most. Type of house is a categorical variable, to use that in regression I modelled them as several binary (0/1) variables.

As preparation, I checked for relations between the variables using correlation. This showed me that much of the collected data does not seem to affect price: Only the floor space, lot size and number of rooms showed a significant correlation with house price.

For the regression analysis, I only used the variables that had a significant correlation. Variables without correlation would not produce meaningful results anyway.

Read the rest of this entry »

Writing less code

November 23rd, 2016 by
(https://blog.trifork.com/2016/11/23/writing-less-code/)

Have you had that feeling that you have to write too much code to build simple functionality? Some things just feel repetitive, they feel you should be not have to write them yourself, instead a framework should make your life easier.

Recently I’ve been building a project in Java/Spring, and after some time I started wondering about alternatives and how to build the same functionality with less code.

There is lots of alternative frameworks and multiple ways of building rest endpoints in Java/Spring.

  • Building the controller/service/dao layers manually in Spring ; https://spring.io/guides/tutorials/bookmarks/
  • Using spring-data-rest to export your spring-data repositories ; https://spring.io/guides/gs/accessing-data-rest/
  • Groovy/grails RestfulController ; https://examples.javacodegeeks.com/jvm-languages/groovy/grails/grails-rest-example/
  • Python/django django-rest-framework ; http://www.django-rest-framework.org/tutorial/6-viewsets-and-routers/
  • etc

Examples

Below some abbreviated examples of how a simple rest endpoint looks for each approach. To actually run the examples, you’ll need check out the tutorials mentioned earlier. My goal here is a quick comparison of how you do things in each framework.

Read the rest of this entry »