It’s been a while, so here’s something more social and less technical again. And I get to join the lodge writing about Linus Torvalds! Let me first write this: any dispute on style or approach to problem solving must be second priority if your main product – Linux – remains one of the most stable and secure software ever produced. This is not just any software. We’re talking about millions of lines of code changed between every point release, provided by tens of thousands of developers worldwide. Software working with a broad number of hardware architectures, “talking to” unnumbered amount of peripherial devices. Finally, a piece of software causing discussions like “If Linus is gone, what will happen to the kernel?”.

I believe it was worthwile summarizing in these few sentences what is the true achievement there. I had to start with that brief summary, otherwise I felt I’d be joining the group that might have been well described by Linus in the following words some time in 2014:

“And there’s a classic term for it in the BSD camps: “bikeshed painting”, which is very much about how random people can feel like they have the ability to discuss superficial issues, because everybody feels that they can give an opinion on the color choice. So issues that are superficial get a lot more noise. Then when it comes to actual hard and deep technical decisions, people (sometimes) realise that they just don’t know enough, and they won’t give that the same kind of mouth-time.”

You can say a lot about Linus and his approach to people or dispute. Dispute will always happen if you work with people of strong character, who have devoted parts of their lives to master an area they then have to prove in production. But not everyone you get to work with will be following this principle. And yet, understanding the root cause of some debates and efficiently not wasting any energy on them is a decent treat of a leader – one that doesn’t often appear in the popular coaching memes. Probably because it is also painful and not entirely neutral.

But can you make big achievements and remain neutral?

Improving the VoIP foreign number solution

It has been a while and I’ve noticed a few issues in my solution (more info here) allowing “assigning” a foreign number to your smart phone. Since solving them was a nice little achievement, I’ll share the description here. It was quite an investigation, too!

The first problem was that the connection keeps timing out from time to time. Not always, but I couldn’t determine a pattern (ah, I love these situations!). In such cases there’s no other choice but to get your hands dirty… and in this case it means some deep packet inspection. Asterisk makes this task fairly easy, so tcpdump was not required. Using sip set debug ip/peer on/off allows finding how my asterisk and the SIP client on my mobile are talking. That’s possible even if you don’t have a good understanding of the session initiation protocol – simply googling it’s workflow is enough to see how it should look. Then all you have to do is comparing the expected flow with what you actually get.

Because of my intermittent issue, I had two sets of SIP debug data – when it works, and when it doesn’t. Comparing the two showed me that when the timeout happens, it is actually the phone that stops responding to SIP INVITEs. Having tried a few other SIP clients on the phone, I had a strong feeling this was not going to be a client issue. So maybe the network? Bingo! As soon as I switched off from my wifi and landed on 4G, the connection worked flawlessly and never failed. As this is weird, I went on to research why that migth happen and found some content explaining how most home routers have a faulty implementation of application layer gateway for SIP. Indeed, it was SIP ALG messing my SIP traffic in failed attempts to “secure my traffic” by inspecting source/destination addresses in the SIP packets. In my case, it would filter out my SIP traffic as soon as the router “forgets” the addresses and mappings, which in my case was 30 seconds from registration (TCP handshake from the mobile to my VPS).

Considering the minimum frequency at which SIP clients can re-register is once every 60 seconds and that my router would time out after about 30s, I was only left with half of the register time working. That’s way below my expectations. I can’t reconfigure my home router (thanks to the ISP), so what do? There’s no way of setting the registry time lower in the client itself without dirty hacks. I ended up doign the following: switch from SIP to IAX2 (Asterisk’s preferred protocol for VoIP), and then I wrote a small patch to my ebuild for Asterisk on Gentoo to define the re-register frequency as 25s, using the following:

$ grep sed /usr/portage/net-misc/asterisk/asterisk-11.25.1.ebuild
sed -i 's:EXPIRE.*60:EXPIRE 25:' "${S}"/channels/iax2.h && ewarn patched IAX2 registry timeout

After re-compiling (making such tweaks is very easy thanks to Gentoo) and restarting Asterisk, even though my client kept asking for 60 second sessions, Asterisk would “demand” a new session (from which all it gets is updating the actual IP address of the smart phone) every 25 seconds anyway. And the timeout problem is almost gone!

Almost, because Asterisk has a security setting called “nat”. It has to be set to “no” regardless if it is SIP or IAX2, which means that when the agents register, Asterisk doesn’t inspect the IP addresses in the header – and those do fail since NAT would translate the IP address of my phone from local LAN to the public IP address of my router. Since I control access to my Asterisk using multiple factors and layers (iptables and user/pass), I consider it safe for disabling.

Improving the efficiency of technical teams

Happy New Year to all the regular readers!

Recently, I had a very interesting chat with a fellow IT leader; we discussed the efficiency of tier 1 technical support and how we usually try to achieve the optimal 80% efficiency mark (80% of the cases to be solved within self-service or the first help desk line). While common techniques are indeed… common (by seeking common denominators in root causes), when it comes to tier 2 and above, there were fewer obvious solutions. And that’s natural, given that complexity becomes a major factor and is implied by the higher tier. So what can leaders do to gain improvement in this area?

I did share one recommendation which works for well for me. It caught some attention therefore I’ll cover it briefly here. The method is called obtaining a minimal working example. It is mostly popular among software developers who are more likely to stumble across a block while working on a complex software project. What do? Involve more brains then, right? Well, of course, but who has the time to go through a litany of complex lines of code, while everyone has their own work to do? Especially if you consider sharing the problem with an open source community, you will need to come prepared. You’ll get no input if the question is presented in a way which might resemble “hey, do my work for me, would you”.

A minimal working example is a complete (ergo: working) piece of code which has to be well crafted before can be presented via collaboration tools to narrow down the scope and yet be able to present the issue. That is required to allow a group to investigate quickly and efficiently. Building an MWE is a method, but even more, it is an exercise for the author. The developer has to be able to collect only the required code, leaving the remainder out to avoid obscuring the root cause of the issue and slowing down the investigation. During the process of building the sample, this method requires considerable effort to be put into evaluation of every step and… yes, about 80% of these get resolved during the preparation of the MWE!

While it is certainly a trick software developers and their managers should consider, it is not limited to programming. System administrators can also benefit from this approach, especially when working on complex configuration files, sometimes including vast and compelx scripting. As tier 2 or 3 support teams gain the ability to build a minimalistic setup with the problem bit captured in it, they surely will also be much more competent and empowered to solve and prevent other technical issues. Naturally, they will also be very efficient when working with the vendor (if eventually required). Building an MWE is also encouraging team work through empathy – after all, the MWE is prepared for someone else to understand and gain insight.

So, that’s one method; please share what works best for you!

Enter the commoditized IT, pushing the boundaries

Commoditization of services might sound like a new trend. After all, all those Ubers and Airbnbs seem like fresh ideas, appearing just recently. We still call them “market disruptors”, right? But probably only those working with IT every day realize that the same trend, with aim for the smallest item performing an unique function, has been present in the IT industry for decades. In this article, I will present the trend as I see it and share my observations. For the casual reader – I promise to keep it as user friendly as possible!

With a certain level of simplification, I believe I can make a statement commoditization in IT started when the “distributed environment”, as the IBM people call it, took off with the approach of creating simple, stand alone computing platforms we refer to now as servers. The attempt to offer services installed on multiple servers, dispersed globally for optimal customer experience and resilience is still popular even with the obvious faults of this approach. For example, servers had a set of resources at their disposal, as the vendor designed them to be applicable for majority of use cases. That usually doesn’t match with what the hosted application really needed. These servers were not as resilient as the mainframe, but at a reasonable price, they allow much faster concept-to-software-service process. These inefficiencies naturally lead to costs that normally wouldn’t have to be implied, but also to indirect outcomes such as developers, especially in the high performance computing sector, having to perform low level optimizations of their software.

The second level of infrastructure commoditization I call the concept of defining key resource areas commonly used by software and creating platforms which allow administrators looking after resource pools. Typically, this is referred to as server virtualization. Imagine your developers work on two projects where the product in each case is an application, but with an entirely different behavior. An application doesn’t store much data, but performs difficult computations – no problem, the admin can spawn (yes, spawn!) a new server with some memory but multiple processors (as long as the app can make use of them). The other application does little math but needs to load huge objects into memory? The admin could now use the memory resources saved on the first project and allocate them here. Running out of resources in the pools? Just insert (hot-swap) another blade of CPUs, RAM or expand the SAN for data storage.

Around the same time, the CPU itself has undergone even further commoditization, we could call it level 3. Multiple solutions have been implemented on processors to improve their efficiency without increasing the clock speed or when further miniaturization of the manufacturing process was not yet achievable. One of the key optimization areas was based on the observation that a lot of potential is lost during the processor cycle itself. As a result, various instructions have been implemented, like SMT for physical cores of a CPU, HT for logical cores, but also VT instructions for the actual virtualization. As a result, we get logical cores in physical cores forming a modern CPU.

Level 4 is a more recent tale, when the definition of SDNs, or “software defined networks” appeared. In simple words, the virtualized stack of standard commodities could be expanded to cover the network as well, which in the internet era is a commodity in itself. The idea is to present a complete set of infrastructure items to meet the development design, which naturally speeds up the whole infrastructural design phase of a project and most importantly, offers a great deal of simplicity to everyone involved in the development. Deployment of new applications of services has never been this easy.

With software defined networking and pools of virtual resources at hand, it is not hard to notice this approach still borrows from the good old “application hosted on a server” concept from what I called “level 1” era. This means each virtual server comes with a lot of overhead, including the operating system and its “wealth” of features. An OS is usually prepared with the idea to just work for as many setups as possible, which then by definition makes it “not the most optimal piece”. Level 5 of commoditization comes to the rescue – containers, among them the most popular container technology – Docker. A single server can run multiple containers, which on the outside look like virtual machines themselves, however they contain only the bare minimum of the OS that the applications hosted in them need to operate. Brilliant, isn’t it? Add to that software to operate multiple containers such as Kubernetes.

So what’s next? Commoditized infrastructure pieces, commoditized operating system allow granular choice of elements to operate applications or services. It doesn’t look like much more can be achieved here. Who can further push the boundaries? The answer is based on the fact that, just like the OS, almost all concepts in popular technology are presented in a way to allow 95% of the use cases to succeed. But what happens, when you’re in that remaining 5%? And who usually ends up there? For the last decade, in my opinion, two areas fall in the 5%: high frequency trading and high performance gaming. Add to them extreme data center owners (aka hyperscale), such as Google or Facebook and you’ll notice they all already have the solution. Software will only be software – it gets loaded into standard memory, operations executed using a standard core. But if the same operations applied to a virtual container happen million times per day on a standard piece of commodity, why not move them to hardware?

FPGA, or field programmable gateway arrays are becoming popular, because they allow just that. The software developer’s work doesn’t have to end as soon as the code is sent to the compiler. The compiler allows the code to be loaded and executed by a typical CPU, which by design is universal and can do a lot of things. Most software however perform a set of standard operations and then something unique to their nature, which gets repeated millions of times. FPGAs allow commoditization of that unique, repeatable activity, which when compiled onto the programmable board, can give it a performance boost of 10-100x at only 20x power increase. There is an immense cost reduction, instead of simply scaling the pool of CPU/MEM resources.

Does it mean application programming has to again become very low-level, make a huge turn around from the era of rapid development? Not at all, there are tools available that make it very easy, for example by utilizing Verilog. Certain standard blocks (DSPs) are pre-installed on the boards, to allow the developers to actually implement only the higher level logic. At the same time, programmable boards are available at reasonable prices and they can be re-programmed, unlike the super-expensive boards produced on demand for HFT trading companies.

FPGAs are the next big thing – if the above combination of breakthroughs did not convince you, take into consideration the battle to purchase Lattice, a vendor of FPGAs only, for $1.3 billion. Consider the rise of Xilinx, specializing in programmable SoCs. Last but not least, Intel acquired Altera about a year ago with the goal to join precisely this promising business.

So what the CIO/CTO can do? While it might not be very easy to find Verilog/VHDL specialists who also are capable developers understanding time-to-market and quality programming concepts, it was a matter of time until other vendors try to fill in the gap. Amazon is already offering EC2 instances with programmable hardware. OVH also offers a similar solution called RunAbove, which at the time of writing this article got completely sold out. Last but not least, there’s also, offering a Google Go language compiler optimizing the code developers wrote to be directly installed onto programmable boards.

What’s next? Maybe containers hosting micro services could be moved to FPGAs?

3 questions to…

Here’s something much easier to read hopefully, compared to the previous, quite technical posts. MoneyGram International runs a “3 questions to…” series in the corporate newsletter with the aim to bring the team closer and shed some light on the profiles of senior leadership in the company. My turn to answer 3 questions came last week and I’m glad, because that’s always an opportunity to practice the non-technical writing. I didn’t expect much out of it, but the feedback was exceptionally positive. Well, positive enough to convince me it might be worth sharing with LinkedIn. What do you think?

You’re managing multiple IT Teams at MGI. What skills do you find exceptionally useful in your role?

Empathy, the queen of all skills is probably worth mentioning on the top spot. This is especially important if your teams work from all around the globe and come from a variety of cultures. Leading such teams is often a challenge, even in IT, where information is crisp and precise. Same message is worth conveying in a variety of ways, staying considerate of how others might look at challenges or upcoming projects. Likewise, sometimes substantially different encouragement is needed in order to gain valuable input and uncover true potential of individuals. Being considerate about those differences and yet not losing track of the technical bits and the end goal is a great challenge to have. I believe that empathy is the key to victory in this aspect.

What are the biggest challenges you face at MoneyGram and how do you address them?

I’m sure everyone mentioned time zone difference between Europe and the US, so I’ll skip that and mention something from technology perspective. As such, while we deliver interesting solutions to the market, I believe we can still do better from the perspective of internal and customer facing technology. While staying abreast is an area dedicated to roles outside of IT Operations, I’m putting extra efforts to bring up some ideas and gain resources to new projects.

Based on your professional experience, what career advice would you give to your colleagues at MoneyGram?

I try to give advice to my team (then it’s called “direction”;) ) all the time, so to give one piece of advice now in general is not an easy task without sounding trivial, but let me give it a try. I believe that many people underestimate the power of research. For example, every time I hear or read anything I don’t know or am not sure about, I make sure I write it down. I then have a dedicated time slot, negotiated carefully with my wife, where I follow up on each item on my research list. Sometimes reading is not enough and I end up like building a proof of concept. I never let information get past me without verification – if there’s a chance to broaden knowledge in the area I’m working in, then it is certainly worth following through. Having strong understanding of all aspects results in working less on assumptions, which gives confidence a great boost. And what’s a leader without confidence?

Could SHA-1 and Dirty COW have something in common?

SHA, or Secure Hash Algorithm is a hash function initially announced in 1995 by the United States’ NSA. It become widely popular with appliances for password hashes, certificates and a variety of software. The implementation made it to SSL (and later TLS) collections, SSH, PGP and many more. From the very moment of publication, SHA-1 was contested by cryptography researchers from all over the world, but not to much success. It took 10 years after the initial publication for the first papers to appear claiming weakening SHA-1 to some extent. The papers remained theoretical due to the cost – it would take almost $3mil of CPU power to execute the attack. It took another 10 years for a group of security researchers to further weaken SHA-1 and actually demonstrate an attack by moving the computation to 64 Nvidia GPUs. And why am I writing this? Mainly because this is a story of great success – for a hash function – to remain unbroken for over 2 decades. Still, around 2015 various security authority boards have decided that, by Moore’s Law, within the next 2-3 years, the cost of attacking SHA-1 by brute force was going to be economically viable and generally available. Based on that SHA-1 was to be gradually removed from public use.

On a side note, here’s one very intriguing case with lots of food for thought. Due to the wide adoption of SHA-1, the ban was instated by various decision makers at different times. In 2015, the Browser Forum decided that SSL certificates using SHA-1 can no longer be issued after the 1st of January 2016. Was this enough to stop all CA’s from issuing the popular SHA-1 certificates, sometimes even hard-coded into proprietary software? Dit auditors save the world as it is widely expected by various company boards? Read the full story and brilliant analysis here.

Back to the original subject, I got a bit nostalgic for a reason, and it is not because I hadn’t had steak for a while. Dirty COW is a funny acronym for a rare race condition introduced into the Linux kernel Copy-On-Write code around 2007 (kernel 2.6.22). It is not however a new vulnerability. Linus Torvalds revealed that even though it was discovered long time ago, the race condition leading to privilege escalation was rare enough that it was actually discarded. It was concluded that computation resources required to trigger the condition are not realistic. And almost 10 years later anyone can execute a local exploit and bypass internal security countermeasures companies spend huge sums on. The exploit is easy to obtain, execute and has a very high success rate.

Two completely different cases and security risks. And a complete contrast in strategy. Or the lack of. A decision to obsolete SHA-1 well in advance of vulnerabilities, despite a decent design. And no decision for a ticking bomb. I have read many quotes by Linus on security (or actually against security). Don’t get me wrong, he still is a brilliant lead for the kernel development, but why wouldn’t the Linux Foundation add the missing strategy? Track security bugs that are closed for a reason like this one and react on time? Someone might say “that’s not their job”. If reality requires it, it has to become someone’s job.

VoIP idea: foreign number to your mobile

I realized I haven’t written anything about VoIP yet in this blog. It is a very interesting subject and a great way to deliver your employer decent “buck for bang” once you get to know how it works. In this post I will explain how to configure a public DDI (direct dial in) number to point to your mobile phone.

Tools used

  • Asterisk PBX
  • iptables
  • SIP/IAX2 client for Android/IOS (anything from the app store)

Use cases

  • Give people (friends, relatives, coworkers) a number that is local to them to cut their costs.
  • Use a foreign number to register to foreign services.
  • Show off 😉
  • EDIT: this solution had some isssues. Ironing them out is explained here.

    The idea is to get a DDI via SIP trunk through any VoIP provider. Some used to offer this service for free, I got it from a good colleague in London. Yes, I will be using a London based number in this case, but the geo-location is agnostic to this proof of concept. Here’s how it would work:

    [PSTN Cloud] –(POTS)– [VoIP Vendor] –(SIP/Internet)– [VPS/Asterisk] –(SIP/3G)– [Mobile/SIP-client]

    PSTN Cloud is the network over which regular landline phones operate. POTS is the plain old telephony system, again – the landlines. VoIP Vendors integrate POTS with the Internet and as a result I can purchase a DDI like (+44) 0207 1234 567. The VoIP Vendor will pass calls to my number by initiating a SIP session to my VPS (virtual private server) IP address, where I will have my Asterisk PBX listening on the SIP and RTP ports specified.

    I will summarize security concerns later, for now focusing on the functional side. I use the SIP protocol in this example, although IAX2 is a good alternative. For Asterisk to handle incoming connections, little configuration is needed. I need to have two peers configured in sip.conf. One for my vendor, and one for my SIP client on the mobile phone. The SIP client would. as per the standard, register every 60 seconds to ensure Asterisk has a recent enough IP address to which it could redirect incoming calls. Here’s an example (comments start with semi-colon):

    root@rzski ~ # cat /etc/asterisk/sip.conf
    ; general, security and performance settings

    context=nonexistent ; in case someone gets up to here, they will not be able to make any costly calls.


    Then, naturally Asterisk needs to know how to handle the incoming connections. This is achieved in extensions.conf.

    root@rzski ~ # cat /etc/asterisk/extensions.conf
    exten => 442071234567,1,Dial(SIP/context_for_mobile,,)
    exten => 442071234567,n,Hangup()

    There are hundreds of other settings that Asterisk can use, it’s power comes from the excellent customization options and flexibility. I recommend reading the well commented configuration file samples bundled with the source code, as well as visiting the online documentation on Digium’s wiki pages.

    Finally, I’d need to configure the SIP client on the mobile. All it takes is to specify the IP:Port, username:password of the VPS and job done.

    Challenge: Security

    I mentioned I will use iptables. Asterisk is great at many things, but it only has basic countermeasures for cyber threats. It is optimal to deal with the security issues as much as possible on the network level and leave the session security and functionality layer to Asterisk.

    I try to keep my iptables neat – default policy is set to DROP and only a few rules to enable chosen traffic. While for the vendor-VPS communication it is fairly simple – I can white-list connections based on the source IP address (the vendor’s) and the destination port/protocol (to accept SIP and RTP traffic only from them), the other half becomes a bit more problematic. Over 3G or LTE, my mobile can pick a lot of various IP addresses.

    I could narrow the area down using GeoIP module, which would allow me to connect from a single country only, but that’s still not ideal. I’m open for a whole country and, what if I travel?

    Another option is to simply tighten the password and use fail2ban. While fail2ban works great in many areas, on a busy server having a system daemon working on 50 log in attempts per second is just not the type of workload I want on my server. Plus, they all get a few tries before future connections are dropped, polluting the log files.

    I believe security is always a compromise of performance/comfort, but should always be considered depending on the use case. In my case, I control 2 ends: the VPS and the mobile. All I need to do is ensure these two have a token they both know about and filter everything else out. Such token could be a certificate, but I’d need to spend some time coding that into the SIP client. I decided to use the string matching module for iptables to only allow traffic coming from my client based on it’s UserAgent ID. Each (well written) client tries to identify itself with a vendor string when communicating with the server and so do many SIP clients. Even better if that string can be configured – in such case you can append some non-trivial string which then you can tell iptables to allow on exclusive basis.

    To obtain or verify the string used in communication between the phone and the server, it would be required to temporarily enable SIP debug (sip set debug on) and review the messages.
    Iptables configuration:

    ### Mobile SIP and RTP access
    # SIP
    /sbin/iptables -N SIPREG
    /sbin/iptables -A INPUT -p udp --dport 5060 -j SIPREG
    /sbin/iptables -A SIPREG -m string --string 'User-Agent: whatever' --algo bm -j ACCEPT
    /sbin/iptables -A SIPREG -j DROP
    # RTP range
    /sbin/iptables -A INPUT -d $PUB_IP -p udp -m udp --dport 5500:5600 -j ACCEPT

    And in case something starts spoofing the string somehow (what’s the chance) and try to guess the password, we can throttle that:

    # SIP brute force
    /sbin/iptables -I INPUT -p udp --dport 5060 -m recent --set --name ASTERISK
    /sbin/iptables -I INPUT -p udp --dport 5060 -m recent --update --seconds 15 --hitcount 10 --name ASTERISK -j DROP

    Note the SIP user agent string check is in a separate chain to allow managing this traffic in the right order.

    One potential pitfall would be if your phone updates the client and thus re-sets the string you’re looking for. Matter of caution.

    And that should be all needed to get inbound calls directly to your mobile. Questions / comments / concerns?

    Device-as-a-Service from HP

    Hewlett Packard have announced a new type of service called DaaS, or Device-as-a-Service, based on which for a fixed regular fee, enterprises could use PCs and printers. Makes sense to me, but what part of this service is actually new? Allowing others to use property is known for centuries under different names: renting, leasing, etc. There are many legal forms and the difference is usually in the approach to ownership.

    Ownership in most cases comes with costs and responsibilities which enterprises but also end users are better off ceding to others, who specialize in the matter and are able to implement optimizations to make the business profitable. Most times the issue is with cash flow, the possibility to spread a large expense over time. A good example are enterprise class printing multi-functional devices. They are big, complex and expensive, yet every medium to large firm needs at least one to function today. What made that possible was the multiple capex and opex options of contracting. Another example are mobile phones added by vendors to call plan contracts, nothing unusual.

    So what is different now? I have read many comments about HP simply trying to hook up to the catchy “X-as-a-Service” buzz word. I think it is undeniable that whoever launches a business line based on anything they can call “as-a-Service” is making a good commercial for themselves these days. Nevertheless, isn’t there a major gap on the market for something that seems to make perfect sense? In most enterprises now, every employee is a user of the IT infrastructure and is very likely to be equipped with some end point device. These devices, multiplied by the number of employees (assuming 1:1 ratio) continue to be a major cost. And that again, multiplied by whatever is defined in the technology lifecycle management policy of the company they work in. Given the above, why aren’t most enterprises moving towards a (ok, I’ll bite…) DaaS model for PCs? Perhaps it is not a well known option and the buzz word approach has the chance to change that? If that works, HP are going to be very profitable, as well as all their partners who are going to offer this as a local service.

    Nevertheless there’s something that seems missing. I read the articles and well, they all mention enterprises. Why the limitation? Not long ago I equipped my parents with a Linux PC, ending an era of dealing with performance issues and virus infections on their home PC. While it didn’t take much time to prepare, I’ll probably need to do some upgrades once the new HD, 4K or other fancy buzzword kicks in. If I had the possibility to sign a good desktop support service for non-tech savvy relatives, I’d probably go for it (or let them do it by pointing them at the offer). A colleague recently made a good comment I could not agree with more: the world has more and more technology users and fewer and fewer of those who actually understand the technology and are able to repair it when required – similarly to car drivers and those who understand what happens under the hood. The answer is moving to shared services – an approach enterprises are already adopting. I presume, households will follow soon. I will also add this to my list of business ideas 😉

    Is there a future for 3D printing?

    I want to dedicate this post to innovation in technology and entrepreneurship. The question in the title is probably a silly one because a recent event taught me that 3D printing is actually already a 30~ year old idea. In the recent years however it managed to break into the mainstream, probably thanks commoditization and availability in the retail area. This seems to have worked as an eye opener for the wider audience, including people ready to invest into this technology – and including myself.

    Like many people, when I read about 3D printing, I tried to find additional information describing the process, innovation and use cases. Nevertheless whatever I found did not really explain all the hype powering this subject. I mean – OK, it is a new thing, allows creating, designing, but where is the big selling point? Is it a matter of having a new toy for the kids with focus on boosting their creativity? Or maybe this is all about small markets for catchy goods like these rings from Japan? For a long while I could not find anything better beyond that. What further made me think “oh well, time to move on to other things” is a post on Slashdot about a year ago, asking the readers to share their use cases and ideas. The result? Many comments simply said “nothing”. Some brought up the possibility to reverse-engineer and produce parts which are no longer in sale. That’s something, but not much. After all, the trend today is to make devices that only last a couple of years. Plus, not every material can be used in the 3D printing process.

    The actual eye opener for me came on the recent CIONET event dedicated to start-ups (kudos to Krzysztof Frydrychowicz and Bartosz Górczyński at this point for making every CIONET event so worthwhile coming to). Among the start-up presenters was one not so much of a start-up but a lively developing company called 3D Makers Zone presented by its founder, Herman van Bolhuis. This Dutch company was a start-up in the 3D printing business in Amsterdam not so long ago. Now they have a solid, diversified business and are looking to scale up. I have to admit that with the outcome of my previous on-line researches I was rather sceptic. Nevertheless after Herman’s passionate presentation I couldn’t help myself but approach him for a discussion. The goal for me: understand what he sees in the 3D printing business that I am currently missing.

    The first mistake might be obvious by now. I had focused on the retail market, for which there might be no better future than what I mentioned above. The real business is the niche that remained between contracting factories for mass production and the smaller businesses, that needed affordable and easily available production on a smaller scale. Imagine a workshop on your street where you could go and have almost anything you need designed and printed with a decent level of quality in 50-100 pieces only. If you run a repair shop or anything similar that could be a godsend.

    But Herman takes it further. With the miniaturisation of technology, he’s able to produce “smart” materials – with embedded sensors, or even something that can change its shape depending on environmental circumstances. But what really impressed me is what he called “distributed manufacturing”, meaning production of goods at their destination. Taking into consideration the amout of items that are easily produced but then their price increases drastically due to shipping – this is just brilliant! I need a full ship cargo of mugs I produced shipped to Brazil? No problem, have a printing shop set up across the Pond and all that becomes easy and without the risks or insurance costs needed to cover the actual logistics.

    When asked about printing electronics, Herman said this is not yet available. No wonder, I thought, since mass chip producers like Samsung or Micron run billion dollar businesses to further shrink the transistors and optimize the complex production processes. That seems to be out of reach from the affordable printing business although Herman suspects it is not far away – perhaps a matter of a couple of years.

    Still, printing electronics actually got me thinking about the possibilities and development paths. I still remember the college classes where we’d be coding an 8051 circuit board with what could be designed in VHDL. I remember how painful it was. Trying to focus on the solution yet keep coming back to the strict rules of low level programming. I can imagine that the big players in electronic manufacturing can simply afford all the low-level programmers, for whom the development process simply became less painful over the years of practice. How would affordable 3D printing change this process? Would people like Herman’s R&D team be able to commoditize and popularize electronics manufacturing like it is possible today with mobile phone apps, where you can now create applications with limited programming knowledge? Imagine you’d be able to have a working board from just the logical design of your new solution.

    Today I am looking at the 3D printing business with a different perspective. I believe a bright future lies ahead.