Conferences

After NDC Oslo 2016

Hakan Tuncer

Jun 13, 2016 • 6 min read

NDC Oslo

In my previous post I'd talked about my plans in NDC Oslo, including all the sessions and the 2-day workshop I was planning to attend.

It's been a great experience. I came back with good memories and learned a few things too. NDC conferences usually feature high quality content and good speakers, this one also lived up to the expectations.

I would like to share some of the highlights of the conference which, of course, are based on my perspective and interests.

Workshop: "Microservice development"

Microservices Development Workshop

Jimmy Bogard and two employees from Particular Software ran the workshop. As it happens with all these type of workshops, nearly half of the content was sort of a beginner to intermediate level while the other half was covering more advanced and interesting scenarios. Here are some of my highlights:

Services are automonous. They don't rely on other services to do their work. They also own their own SLA & uptime. They should have explicit boundaries and own their own data.
Isolation of services enable the use of different languages and frameworks per service. However, rather than using the freedom of choosing a different language, it is more useful to have services choose their own data store. Homogenity on the application side and heterogenity on the data side is more encouraged.
Creating service boundaries for actually solving business problems is a good idea. Take a good look at the business domain and how it's compartmentalized within your company. Model your services around that structure. A straightforward example of this is to create a service per business department or independent business unit.
We talked about messaging patterns. A lot of boilerplate code around messaging is handled for you by a product called NServiceBus (from Particular Software).
- Using commands only within a service boundary.
- Using events within and across service boundaries.
- Once you separate your service into a number of granular command and event handlers, try to be as "dumb" as possible inside each of these handlers - avoid using complex patterns and abstractions as much as possible (this at least is what Jimmy is advising).
When building an SOA (service oriented architecture), the rule of thumb is that the first line public service can call multiple downstream services to aggregate data but those services should never call other services. Thus, the depth of services that are called are never more than one. This principle will help you avoid complexity and possible high latency.
For this reason above (downstream services don't call other services) an example in the workshop used a technique where a service codebase contains public interfaces which can be implemented by other services and shared during development time (as nuget packages). Check this code for an example of this use case.
- As an example, if sales domain needs to get something from customer domain, sales service declares an interface and customer service supplies the implementation to that service.
- This means that one service doesn't call the other one at runtime but instead runs that piece of code directly.
- Note that this removes the runtime dependency but introduces development time dependency. If you're doing microservices mostly for reasons around team composition and independence, this might sound less attractive to you.
You can find all workshop exercises here on GitHub.

Microservices Development Workshop

Conference Highlights

Erlang is cool, so is functional programming!

Functional programming was a large and popular track in NDC Oslo. Created a lot of buzz for sure. This photo below was taken at the end of conference day one. I believe at the end of the conference #fsharp, #erlang, #phoenix and #elixir were all sitting high in this top 10 list as some of the most spoken technologies.

I met Erlang for the first time and found it quite interesting. In Wikipedia, Erlang is described as:

Erlang is a general-purpose, concurrent, functional programming language. It is also a garbage-collected runtime system.
Erlang is known for its designs that are well suited for systems with the following characteristics:

Distributed

Fault-tolerant

Soft real-time

Highly available, non-stop applications

Hot swapping, where code can be changed without stopping a system.

Do any of these sound familiar? Welcome to the cutting edge stateful microservices technology, from 1986!

Lightweight processes are the main building blocks of an Erlang application:

Processes are the primary means to structure an Erlang application. They are neither operating system processes nor operating system threads, but lightweight processes that are scheduled by Erlang's BEAM VM.

Based on my first impressions I found many conceptual similarities between Erlang and Service Fabric: the idea of stateful and stateless services messaging each other. Erlang doesn't have the concept of replicas (unlike Service Fabric), all process nodes are peers - no primary & secondary relationship. Which means if a process crashes the state is gone. Of course there are solutions to this - like Mnesia.

My gut feeling after learning more about #erlang in #ndcoslo : #servicefabric is #erlang plus some (large) churn.I still love #csharp though
— Hakan Tuncer (@hakant) June 10, 2016

I think I'll be looking into Erlang, Phoenix and Elixir because I'm sold to the idea that these things are pretty powerful to ignore.

Head to head session with questions from Stack Overflow

Head to head with Scott and Jimmy

Both Scott Allen and Jimmy Bogard are proponents of testing with less mocking. Jimmy said he doesn't like using in memory database tricks or any other unrealistic testing styles. A few tricks that he spoke of were:

Using database transactions without commiting in the end - to get back to a reset state after each test.
Using a nuget package called Respawn that can cleanup the database after each test in a clever way.
Using real storage during tests has been beneficial to these guys according to them (less unforeseen bugs).

.NET Core is shaping up nicely

.NET Core - Mark Rendle

ASP.NET Core looks beautiful even though the roadmap had its fair share of ups and downs for a long period. The talk about making the Kestrel web server performant is fantastic. It turns out that creating a very performant web server takes ridiculous amount of code optimizations. Must watch. Actually most .NET Core talks were very interesting.

Kestrel Web Server