PHP microframeworks and the Symfony Framework Micro Kernel

A Micro Kernel was merged to the Symfony 2.8 branch on November 5th. This is an alternative to the traditional AppKernel used in applications built with the Symfony Standard Edition (SE) Distribution.

Let's study what is the difference between these Kernels and how they relate to PHP microframeworks like Silex, Slim and Lumen.

The term microkernel might be familiar from Operating Systems where it stands for a minimum amount of software that can provide the mechanisms needed to implement an OS. A monolithic kernel is more full featured and takes full responsibility of low-level functionality.

The Monolithic vs. Microkernel approaches sparks discussions and there has been public debate about this for a long time:

Tanenbaum began the debate in 1992 on the Usenet discussion group comp.os.minix, arguing that microkernels are superior to monolithic kernels and therefore Linux was, even in 1992, obsolete.
-- Tanenbaum–Torvalds debate

The underlying complexities between Monolithic Kernels and Microkernels in Operating Systems are overwhelming, but in the PHP world things are obviously quite a bit more straightforward. It's safe to say that all recent PHP (micro)frameworks would by this split have a microkernel.

Microframeworks

Microframeworks rose to popularity in the PHP world starting from 2010 thanks to the Silex microframework. In conjunction with the popularity of microservices (small applications that serve specific tasks) movement there was a flood of new microframeworks to the market, some of which are Fuel, Fat-free, Slim and Lumen.

These tools borrow their idea from Sinatra for Ruby dating back to 2007 (which probably borrows it from someone else). They are simple enough to display a complete hello world application on the frontpage of the site and are lightweight with a small bootstrap. Each has their own way of adding functionalities. Silex, for example uses included Service Providers or allow you to construct one yourself.

All microframeworks the frameworks are essentially islands in extensibility. Even Silex, a project from the Symfony creator cannot, by design, use Bundles from the Symfony Framework directly. This is why it's become quite a common practise to pair monolithic PHP applications like Drupal 7 with a PHP microframework for specific tasks.

Lured by the promise of performance many have also taken up on using Node, a completely separate technology for content delivery - a field which PHP microframeworks ruled for a few years. There have been interesting advances in asynchrony and PHP with libraries like Icicle and Amp.

These don't make your microframework specific code reusable, but enable the reuse of decoupled PHP code in an asynchronous setting. Code you've written or shared components via Packagist.

If you're interested in microframeworks, these articles are worth reading:

The Symfony Framework

The microframeworks can be used to create complex applications, but when working with large teams on complex software, the structure and functionality provided by a full-blown framework can be invaluable. But with added structure and features comes a learning curve.

Where as Silex is immediately approachable, the Symfony Framework can be quite overwhelming simply because of all the functionality it offers. The situation is rendered worse if you're working on a complex application with a framework that you don't know. This leads to much frustration and fingerpointing towards "the imbesils that created such a stupid thing". Just as with anything, once you've got the routine it looks easy for the outsider.

Being a junior Symfony Framework developer myself I continue learning new things daily. After the initial shock of terminology, mind-boggling number of configuration options I've now got the tools to learn more. One great resource for this are the slides from Sarah Kalil, describing how many options you've got for overriding functionalities and configurations in Symfony2.

Bootstrapping yourself to the stage described above takes patience and requires making a lot of mistakes. It's not very rewarding or budget friendly. You spend hours trying to accomplish something you could've done in "60 seconds" with the old way. Oh and do remember that memories grow sweeter with time...

Once you get more people onboard, the standard methodologies, lingo and online support resources start to pay off as development comes technically as close as it can to a standard factory process. Creativity is needed to solve the problem, but implementation is routine. That's when you're at the top of the learning curve.

The Symfony Micro Kernel

The Symfony Micro Kernel aims to combine the both of best worlds. The immediate satisfaction and the elusive "joy of coding" provided by a microframework and the extensibility and structure provided by the full stack Symfony framework. It does this by adding a trait that you can extend.

This allows you to create a complete Symfony Framework application in a single file (or more) that has everything from bundle loading to routes and actions embedded very much like in microframeworks. Unlike these, applications built with the Micro Kernel can be upgraded to full use the complete Symfony AppKernel. You can also use the standard Symfony Bundles before upgrading.

Finally returning to Operating Systems, there is a third breed of kernels in that world:

A hybrid kernel is an operating system kernel architecture that attempts to combine aspects and benefits of microkernel and monolithic kernel architectures used in computer operating systems.
-- Hybrid Kernel

While not technically equivalent to what we have here, I will still go ahead and categorise Symfony as a Hybrid Kernel system from version 2.8 onwards: One kernel for ease of use and getting started, with an upgrade path to the fully featured one.