CIOs are often relied upon to determine how open source fits into an organization’s future initiatives. For most IT projects, this boils down to pinpointing where they should land on the spectrum between directly leveraging open source software and just buying an off-the-shelf product.
Like choosing between a bespoke suit or buying one from a retailer off-the-rack, a clear decision must be made up front to properly balance between a desire to avoid vendor lock-in and the cost and complexity of a tailored solution. Using open source technology introduces two main issues:
1. Operational overhead is usually higher because of the need to combine disparate pieces that may be serving a function that differs from other users of that open sourced technology.
2. There is a requirement that IT organizations have to evolve to be more development centric to handle open source technology. On the other hand, addressing these risks and adopting open source technology can bring significant advantages to the business. These include greater flexibility, increased agility and lower license costs. Armed with a framework to:
(a) Analyze the requirements of the project.
(b) Evaluate the available set of tools.
(c) Determine how to integrate the open source components
CIOs can make a rational determination on the risk/reward. Executed properly, they can come out looking like a million bucks and drive long-term value for the business.
Can You Handle the (Open) Source?
Enterprise projects are built one of two ways: build it custom in-house or buy an off-the-shelf solution with whatever specifications it comes with.
Traditional software projects in enterprises used to build the full stack, from zero lines of code to final product. The hardware to run that project was also customized and dedicated. The projects used some source code and components from previous projects if possible. For building large scale integrated systems, enterprises used to build everything all the way from basic libraries to cluster (distributed systems) management.
With off-the-shelf solutions, enterprises get the common denominator of what the software vendor has decided to build. For many small enterprises it is sufficient, but for large enterprises that are looking to their IT to deliver a competitive advantage to their business, vendor software is usually not enough.
With the open source evolution to a code sharing economy, the way products are built enterprises is rapidly evolving.
Now, projects and products are built using a “stack.” Different levels of the stack, including storage, database, clustering, data flow, data processing, analytics, and messaging are all composed together to form the final product. The functional, performance and scaling requirements of the product influence the choice of the pieces of the stack. Some of the pieces of the stack can be off-the-shelf licensed software. A common example is the database used for storage. Enterprises do not build databases anymore.
With the rise of the stack, one significant development has been the way open source components now fit into the stack. Every project now analyzes the requirements and looks to open source software that can achieve cost and time savings from adopting stable open source components into the stack. The rise of micro-services exponentially increases the complexity of fitting open source components into the architecture.
However risky it may sound, there are still enormous time and cost advantages to adopting open source software. As an example, many enterprises now use open source databases as storage engines for their large projects.
Here are a few guidelines to chart a course through the open source ecosystem:
Know Thy System.
Start with documenting the requirements of the product/project/system you are building. Do an exercise on designing and architecting the components and how they would interact. This should be independent of whether existing internal or external (open source or otherwise) components are used in the stack. This will establish the contract and the requirements for each component. Look for the open source components that will serve the contract and requirements. In addition to the licensing, you should also pay attention to the form and programming language of the open source software.
Many times, analyzing the open source software and its design and architecture will point out deficiencies or shortcomings of the original design. This is one of the most useful aspects of trying to use open source software. The reason for the design and architecture of successful open source software includes a lot of community thinking (which is also public) which by itself is a very valuable input into how your system should be designed and built.
Doesn’t matter how many contributors are working on it and how popular it is, no open source software is ready to be used as is. Using support licenses does not always mean your problems can – or will – be solved. Every usage of the open source software might exercise different stress points of the open source software.
You have to be ready to dive deep into it and understand the innards. This does not always mean having to modify the open source software. If the specifications of how it works or the implementation looks significantly different from how you would design the same component, either your design was wrong or your design is right and the open source software you chose is the wrong component to use. Does your IT or developer organization have the abilities to adopt the open source software as their own? Can they handle the source code?
Have the Hot Glue Ready.
Be ready to handle the interface and input/output quirks. Be ready to handle the fact that it might not be stable. Be optimistic but honest. You have to understand that you will be able to use the components as long as you remember that it will not be easy and you have to put effort into it. You have to build the code you are writing to handle these components and still deliver the goals of the system you are trying to build.
Open source software can enable enterprises to amplify their core competencies and significantly ratchet up the agility of their development and processes. There can be significant cost and time savings from integration as opposed to buying solutions or building from scratch.
To be successful at achieving these gains, you have to be ready to roll up your sleeves and adopt a culture of openness to both software and ideas.
(About the author: Kiran Bondalapati is co-founder and CTO at ZeroStack, a self-service and scale-out private cloud startup. Prior to co-founding ZeroStack, Kiran was a founding engineer at Bromium, where he architected Bromium’s security solution based on radically new techniques with hardware virtualization. Earlier, at AMD, he developed fundamental underpinnings for virtualization and power management impacting a wide spectrum of computing, from data centers to laptops.)
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access