Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,124 | Comments: 45,486

filter by tags archive

The difference between Infrastructure & Application

time to read 3 min | 466 words

Recently I am finding myself writing more and more infrastructure level code. Now, there are several reasons for that, mostly because the architectural approaches that I advocate don’t have a good enough infrastructure in the environment that I usually work with.

Writing infrastructure is both fun & annoying. It is fun because usually you don’t have business rules to deal with, it is annoying because it take time to get it to do something that will give the business some real value.

That said, there are some significant differences between writing application level code and infrastructure level code. For that matter, I usually think about this as:


Infrastructure code is usually the base, it provides basic services such as communication, storage, thread management, etc. It should also provide strong guarantees regarding what it is doing, it should be simple, understandable and provide the hooks to understand what happens when things go wrong.

Framework code is sitting on top of the infrastructure, and provide easy to use semantics on top of that. They usually take away some of the options that the infrastructure give you in order to present a more focused solution for a particular scenario.

App code is even more specific than that, making use of the underlying framework to deal with much of the complexities that we have to deal with.

Writing application code is easy, it is a single purpose piece of code. Writing framework and infrastructure code is harder, they have much more applicability.

So far, I don’t believe that I said anything new.

What is important to understand is that practices that works for application level code does not necessarily work for infrastructure code. A good example would be this nasty bit of work. It doesn’t read very well, and it has some really long methods, and… it handle a lot of important infrastructure concerns that you have to deal with. For example, it is completely async, has good error handling and reporting and it has absolutely no knowledge about what exactly it is doing. That is left for higher level pieces of the code. Trying to apply application code level of practices to that will not really work, different constraints and different requirements.

By the same token, testing such code follow a different pattern than testing application level code. Tests are often more complex, requiring more behavior in the test to reproduce real world scenarios. And the tests can rarely be isolated bits, they usually have to include significant pieces of the infrastructure. And what they test can be complex enough as well.

Different constraints and different requirements.



"Writing application code is easy, it is a single purpose piece of code. Writing framework and infrastructure code is harder"

I completely disagree. Perhaps your experience with infrastructures is only for the more complex infrastructures - but if an application is complex it is hard as well. For me, at least, writing application code is harder - because it may be single purpose but that purpose makes no sense in our minds, it makes 'business' sense but it's usually a twisted piece of code, with all those little edge-cases.

Framework code is easy, because framework code makes sense.

No More Hacks

What gets me going is people trying to write applications like they were frameworks and doing everything super-generic thinking that it will be re-used. Applications aren't frameworks and we shouldn't write them; we should extract them from working applications. Then you get "use" before "re-use".



Writing application code is easy, but reading it is hard, especially after few years. When you're writing infrastructure code, you should concentrate on exposing simple and logical API so your users shouldn't need the documentation to get started. And for application code select a tool that will make the code self-documenting because the source code is often the only documentation of application logic. Ayende, by looking at your code example I can definitely say it's infrastructure code - the code is totally incomprehensible, so you probably have been concentrating on keeping the API simple.

Shane Courtrille

I'm trying to understand why at the very least that method couldn't be broken up into a bunch of smaller easier to understand methods?

Ayende Rahien


Sort of, the code is meant to be production ready, that tend to uglify any piece of code you care to name.

Ayende Rahien


It could.

The problem is that then you lose the ability to yield from the method, and the way I am using async invocation here make it very important to yield at the appropriate place.

More than that, we also have another problem. If you look closely at each piece of the code, you'll see that it is mostly error handling that is taking all the space.

And trying to split the error handling to multiple functions would cause an even more probelmatic issue, because the particular error handling that is needed at each stage is different.


this is a very good conversation to have.

Another case can be made that the frameworks in particular establish coding conventions & best practice. So, anything that you do to try to simplify those conventions, or to redefine the scope of the framework, in your own application won't scale well across the organization.

Every good app developer should have their own Rhino Commons.

Ayende Rahien


Actually, not really. I'll have a post riling against Rhino Commons soon


ayende, what do you mean?

"Trying to apply application code level of practices to that will not really work, different constraints and different requirements."

do you mean don't apply biz logic to the queue because the queue is too low level... hence don't write a queue in your biz logic?


Ah really? I'm looking forward to that. Cuz I often write my own stuff like util.MyServiceUtil, wrap up some service call handling as a higher level abstraction that only me and my own biz logic need to know about and then bundle it outside of the application class structure so that it's explicit to maintainer that "hey, I like to do it this way but you don't have to!"

Ayende Rahien


I mean that in many cases, there are totally different requirements from the app code.

For example, an application can puke its guts if there is an error, an infrastructure cannot, it need to recover in a graceful way or crash in a recoverable manner.

Other constraints relates to how you do troubleshooting, monitoring, etc.

App code is things like reserve an order in a concert. There may be a lot of business complexity in it, but there shouldn't be technical complexity.

Infrastructure is usually the other way around.

Those produce different forces for the design.


weird... i typically never disagree with you ayende. i've been following your blog for over a year now and haven't really missed any of your points. Two misses in one night! Is there a ghost in my house?!

By the way that code example is nasty. It's just filthy. I love it.

Ayende Rahien


I am not sure that I understand, misses?

Ayende Rahien


The post about why I dislike common assemblies will show up on the 29th


i missed your point about rhino commons being bad and i missed your point about complexity in app code. i tend to think that complexity in app code is derived from the business & infrastructure constraints. What if the lead says "sorry, we can't support Lucene. You have to figure out how to write search into the app." They'd be telling you to do something that is bad, but it happens all the time.


ayende, I see your point though that even if you must write a search engine into your app (and you shouldn't) but if you absolutely must then you want to write it in a different way and possibly even in a different language.

do you consider writing your infrastructure stuff in C?


Excuses, excuses... :))

Ayende Rahien

If I need to write infrastructure code?

Yes, it is probably going to be C#. I am not messing around with C++ again, had enough of that.

To take your example, if I need a specialized search engine (and I needed that a few times), I am going to write that as infrastructure code, one that can be later be manipulated by the app code.

The infrastructure is going to only know about searching, the app code knows the meaning

Ayende Rahien

No, not really.

Reasons, not excuses


@configurator - You are absolutely right, frameworks are easier because they make sense (which is why in many projects they always end up in the App code)

@ No More Hacks

Sometimes you don't have the time to define & write the framework so it ends up in your application code.

Comment preview

Comments have been closed on this topic.


  1. The design of RavenDB 4.0: Physically segregating collections - one day from now
  2. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - about one day from now
  3. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 5 days from now
  4. The design of RavenDB 4.0: Voron has a one track mind - 6 days from now
  5. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 7 days from now

And 11 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  2. The design of RavenDB 4.0 (13):
    03 May 2016 - Making Lucene reliable
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats