The killer app is not really the killer app but the killer framework. The idea came to me when I was watching the keynote from RubyConf AU 2013. Dave Thomas, the speaker, talked about many subjects, however, most notably he talked about developer productivity as it results from the granularity of the language; in his case Ruby and it’s DSL-ness.
I do not particularly care for custom DSLs, however, general purpose embedded DSLs serve a terrific purpose.
Scale or the ability comes in many different flavors and many combo flavors too; and it can effect each point in the stack. It’s also why companies move certain aspects of their applications to the client and sometimes back. There is also a migration to and from distributed computing and the monolithic appliance. However, in most cases the workflow or transaction and the infrastructure are linked together.
Being linked together refers to a number of linkages:
- The source code is literally compiled and linked together
- There is some logical aspect to a transaction that is known to all layers in the stack
- The layers of the application stack are glued together
This simply cannot scale. Whether it’s resources to implement new features, maintenance, or the increase the number of clients and server instances to support them. This will fail all attempts to scale and system availability.
One particular challenge is the server farm. What do you do when you have 100 or 1000 servers with a particular app or service. Do you take everything off the air for maintenance or can you do rolling migrations. What about point in time restores or recovery? What happens when you rolled out that latest patch… it runs for 24hours on the production canary… and is rolled out… only to find a serious bug that needs to be completely rolled back.(I hate hot plugging)
I’m not promoting one particular solution but an idea. The application framework is the application framework. It knows absolutely nothing about the actual transaction. Just that there is a transaction. It also knows how to move packages and route messages; not that it understands the contents of the message. And it knows how to deliver the response. And let it know how to execute some generic workflow.
In an over simplification the application framework can be a desktop app or a desktop app simulation of the web app framework. The web app framework could bloat with features for different classes of businesses but the workflow would stay the same.
As a side note. Many developers start to panic when they see architecture like this. They tend to believe that there is a certain amount of relegation or non-technical-ness that happens. Well this is part of the process. It’s also why I think the DSL needs to be a proper language rather than the base implementation. And the most important thing is that there are so many things a business needs to run successfully that the core app is but only one piece. The other infrastructure elements are so much more important. That’s for another post.