Software design decisions are always trade-offs. You can build software that does one specialized thing and does it extremely well. You can build software that does everything in a problem-space and does it acceptably well. But you can't build software that is both extremely flexible and extremely effective. Depending on the situation, you want to choose one over the other.
Consider Mac OS X and Windows. Mac OS X runs on a very limited subset of hardware. It has very limited customizability - as they joke, with Apple, you can have it in any color you want... as long as you want black. It's an entirely inflexible architecture, but what it does, it does really well. Windows has to run on every piece of hardware under the sun, as the PC hardware market is incredibly commoditized. It is extremely customizable and flexible, with exposed interfaces deep into the operating system. But it's at best a merely acceptable operating system. It lacks the elegance of Mac OS X. The same distinction can be made for iOS and Android.
I've been working at Red Hat for a little over six months now, and given that Red Hat acquired Ansible mere hours before I received the job offer, and that Ansible still operates pretty autonomously from its crimson haberdashed overlords, my interactions with Red Hat culture and product teams has been pretty limited, but I watch us struggle with this choice.
If the software you're building can do pretty much anything, but only pretty well, you're building a platform. If the software you're building does a pretty limited subset of things, but does them extremely well, you're building a product.
Django is a platform. By itself, Django actually doesn't do anything. But Django is a fantastic platform for building web apps on top of. And Django has been a successful platform precisely because it provides the scaffolding to do what you really want to do faster and easier than you could have on your own, no matter what kind of web application you want to write.
It's because Django's authors made the design decision to make a platform versus a web publishing product that it has been so impactful. Other web publishing products, like Wordpress, made other design decisions. And WordPress quickly found that its users wanted to do more than the product's design allowed, and so after the fact they've tried reworking their software to be more of a platform. The result shows in their code - it's a poorly engineered platform, but an excellently engineered publishing product. And still their greatest successes continue to be simply in the web publishing space versus more general web applications.
Red Hat's most successful software offering by far has been Red Hat Enterprise Linux. Revenue from subscriptions to RHEL continue to be the overwhelming majority of our income. RHEL is a platform. It by itself doesn't do anything particularly interesting. But using RHEL, you can do anything on top of it. Whatever application you want to write or run, in whatever language you want to write it in, on whatever cloud or iron you want to run it on, it's a solid foundation and effective vehicle to do it.
Ansible's entry into the Red Hat ecosystem has been so disruptive because it's a platform and a vehicle to automate all the things. It's agnostic as to whether you're running on Windows or Linux or Solaris. It doesn't care if you're in AWS, Azure, Google Cloud, Rackspace, or running bare metal. It has no opinions about Kubernetes or Docker. It just works with everything.
But Red Hat has other offerings that are products. Red Hat Satellite will manage your RHEL infrastructure far better than Ansible ever will, because Red Hat Satellite focuses on being awesome for Red Hat products. If you have Windows infrastructure too, you're shit out of luck - Satellite cares where Ansible is agnostic. Red Hat Cloudforms will manage your cloud infrastructure, be it in VMWare, Amazon, Open Shift, or whatever cloud - but only if it's in a cloud. And it will manage your cloud infrastructure in superior ways than Ansible can by itself - but that's because it limits itself intentionally to cloud-based infrastructure.
Neither products nor platforms are categorically better. What is, however, categorically better is using solid platform when building products.
Look back at my little graph above. Note the overlap between the red and the blue boxes. Building each one of those boxes is an investment of human labor and time to create, and the overlap is wasteful repetition of software development effort companies like Red Hat can avoid. Mac OS X didn't have to build its own underlying operating system - it borrowed from the Mach and BSD platforms that were already out there.
What will continue to fuel the success of companies like Red Hat will be focusing development efforts on building the platforms out laterally and the products out vertically - ensure platforms continue to cover more use cases and ensure products continue to do their limited aims better. If you take the red box and stack it on top of the blue one, the same amount of labor generates that result.
Make the design decision early on whether you want to be platform or product. Great platforms set out to be platforms, great products set out to be products. Software projects that set out to be both crash and burn, because they can neither cover the breadth of use cases nor do any of the use cases particularly well.Share on Twitter Share on Facebook