Open Source Software – Part 3

In the previous post, I discussed the two most widespread misconceptions about OSS, that OSS is for free and that it does not create any lock-in.

In this final post about OSS, we will discuss the role of OSS in the IT world of today and what it means for us.

A changing world

As I wrote in the first post of this series the triumph of OSS in IT mainly took place between approx. 1990 and 2015. But between 1990 and today a lot of things changed in IT. Especially the success of cloud technologies gave rise to a complete new breed of offerings: The managed services.

Cloud computing started around 2006 with low-level infrastructure services (IaaS): AWS EC2, S3 and SQS. Around the same time a different class of Internet based services became popular: SaaS (Software as a Service) ¹. The Internet connections became beefy and reliable enough that it became possible to source IT services from the Internet instead of hosting it on-premises.

First, only non-critical applications were sourced this way. But over time, more and more critical applications were sourced as SaaS. Over time also other offerings between IaaS and SaaS emerged – not only PaaS, but also offerings that supported developers building applications more easily. Those services expose powerful APIs that make the services easily integrable in bigger applications. This way these services are sort of “SaaS for developers”.

These services come in two flavors. The more traditional one is an already successful SaaS that can also be accessed via API. Shopify ² is an example for this type of managed service. You can use it as pure SaaS without any programming experience to create, run and manage an online shop. On the other hand, Shopify also offers a powerful API that developers can use to implement online shops without having to develop and run the shops themselves.

The other, increasingly popular flavor are purely API-based managed service. commercetools is an example for this other type of managed services. commercetools does not offer any frontend functionality. You have to develop your frontend(s) yourself. It is purely meant for integration via API. It offers all required e-commerce functionality via its API and the company behind commercetools runs the platform themselves, i.e., as a company you do not need to take care of installing the product on your servers, running it, maintaining it, and so on.

There are many more managed services, e.g., Stripe for payments, contentful for content management, Algolia for search or Auth0 for IAM, just to name a few popular examples. Actually, meanwhile almost everything is available as managed service. Not only heavyweight powerful products are available as managed services today, also relatively limited, but useful functionalities like, e.g., IFTTT can be used via API.

This means, managed services have become a viable alternative to traditional commercial off-the-shelf products and OSS solutions. Unlike the other two, managed services are “serverless”, i.e., you do not need to care about setting up the required hard- and software, configuring everything, hardening it, operating and monitoring it, installing all the updates and security fixes (before some cybercriminal exploits the vulnerabilities), and so on. Someone else does it for you. You just need to use the service via the provided API.

In the end, managed services represent a “shift to the right” on a Wardley map. Instead of building the solution on your own or sourcing it as a product solution (no matter if commercial or OSS), you simply “use” it. The functionality is provided as a commodity and fittingly the payment model typically is either a subscription or a pay-per-use model, i.e., you rather rent the functionality instead of buying it.

Recalculating the business case

Yet, for different reasons many developers still try to avoid using managed services above the pure IaaS level. Many of them have a strong bias towards OSS, often for vague reasons. In those cases you often hear the misconceptions regarding OSS that I debunked in the previous post.

This often leads to bad business case calculations, as managed services greatly changed the business case landscape for IT solutions. Let me illustrate the changed situation with a little example ³:

A client needed a monitoring solution for the newly created microservices solution (it was the first microservices solution in that company). The solution approach of the lead engineer of the development team was:

• Write formatted JSON log messages including the required data to derive the desired metrics from
• Use ELK for log aggregation
• Use Kibana to create the required monitoring dashboards

I asked the lead engineer why he suggested that solution. His reasoning was: It is a very flexible solution, can be adapted easily to future requirements, is scalable and as it is OSS, it does not incur any license fees.

I asked him why he did not assess a commercial APM solution. His response basically was that it would be too expensive, probably not flexible enough for future needs and that he did not trust the scalability.

I then had a little discussion with the engineer. I started with the pricing topic:

• Implementing all the required log messages takes about 50 PD (it was a bit bigger application).
• Then you need to set up and configure ELK and the Kibana dashboards – usually at least another 10 PD, typically longer.
• Calculate another 20 PD until things are mostly as desired (figuring out unexpected production bugs, tracking missing log messages, etc.)
• Then this company does not have any knowledge regarding ELK or anything similar yet. This means, they need to hire new administrators (training the existing crew was not an actual option for various reasons ⁴).
• In a production context you need the commercial version of ELK as you need a monitoring if your monitoring is still up and running ⁵.
• Implementing the monitoring on your own will delay the project by approx. 2 months as these activities are added to the critical path and cannot be parallelized too much.
• Additionally, maintaining and evolving the monitoring solution (without adding new features) will be another 10-20 PD/year after the initial release.

If you sum all these efforts up, you end up with almost 100.000 EUR development costs plus about 200.000 - 700.000 EUR/year operations costs depending on the number of additional administrators you need to hire (if you find them at all on the job market).

At the same time I happened to know the price of a befriended APM vendor. It was 67 USD per node and month (independent of CPUs or memory). The production installation would have required about 20 nodes which means approx. 15.000 EUR/year (note that the node price was USD, not EUR). In other words: For the development costs alone, you could have run the APM solution for almost 7 years.

You do not need additional administrators as it is a managed service. Learning to create a dashboard is a no-brainer compared to learning the ELK platform. The agents configure themselves. New endpoints are detected automatically. New product features become available without requiring you to do anything.

You may add a few grains of salt here and there, but no matter how you turn it: It is hard to prefer the OSS solution for economic reasons.

Regarding flexibility: The managed service solution provides all standard metrics out of the box. As it also does request correlation out of the box, yo can drill down in any odd request to understand where the problem is – an extremely valuable feature that the solution suggested by the lead engineer did not include at all. That would have been at least 50-100 PD additional development time providing a solution not as good as the managed service solution.

And if all the provided metrics should not be sufficient, the managed service offers on the one hand options to add custom metrics in the application it picks up and on the other hand an API where you can query the whole data set and build your own dashboards if you need to.

While not impossible, usually you never get the budget in a regular project to implement the degree of flexibility the managed service provides out of the box. Thus: It is also hard to prefer the OSS solution for flexibility reasons.

Finally scalability: I happen to know that the APM solution is running in installations where it monitors several 10.000s of nodes in production. The service was designed from bottom up with such settings in mind. Most companies (including the one we are talking about here) have orders of magnitude smaller installations – and always will have.

Hence, it is also hard to prefer the OSS solution for scalability reasons.

So much for the little example. I will not reveal how the discussion ended as it does not add anything to this post. But you may ask yourself how you would have decided if you would have been the lead engineer.

While of course it is not possible to generalize the findings of this little example (I did not intend anything like that by any means), it should make obvious that rashly going for the OSS solutions no longer is the obvious choice. While in the make-vs-buy decisions 10 or 20 years ago, OSS often was the more sensible choice, the new make-vs-buy-vs-lease setting totally changed the game. We need to take the changed status quo into account to make sensible decisions.

OSS today

OSS still is an important force in the software market and must not be underestimated. Yet, it is important to include the managed service offerings that emerged in the recent years in the considerations. OSS no longer is the preferable choice by default. These days, often managed services offer a more sensible option from an economic and risk perspective. If we want to find the best solutions for our customers, we need to take them into account.

Nevertheless, I think OSS is here to stay. There are still a lot of places where using an OSS solution is a more sensible choice than using a managed service. I also primarily discussed the economic perspective. This makes sense as most decisions are primarily driven by economic reasonings – even if they are flawed (and the “OSS is for free” misconception is by far not the worst economic misconception I have seen over the years).

Still, there are also other, non-economic decision drivers. E.g., one of the biggest advantages of OSS is that software engineers can try it out and familiarize with it before they have to decide if they want to use it. You can easily try how it feels, test alternatives and then make the decision. You do not have to buy a pig in a poke. Yo do not need to ask for test licenses. You do not feel the breath of a sales representative in your neck all the time while you are trying to test the solution. And so on.

This was a great leap forward for most software engineers, this freedom to evaluate, to familiarize and decide at their own terms. Yet, most managed services solutions also offer free tiers that provide similar degrees of freedom. The managed services learned the lesson that OSS taught the IT word: If you want to win the software engineers over, you need to make your offering as easily accessible for them as possible – including evaluation.

But again, there are more aspects that drive the decision for or against a solution option. So, even if being easily accessible no longer is a unique characteristic of OSS, I am convinced that it will persist.

It will be interesting to see how the IT market will evolve in the future. Managed services will not be the end of the development. New types of offerings will emerge. We will travel the Wardley map from left to right many more times. And OSS – maybe in some new variants – will have its place in there …