Open Source Well Architected

We are increasingly seeing the rise of Open-Source Software (OSS) solutions. Also, more and more organizations are now using Open-Source projects as part of their solutions — Whether it means, integrating with a single open-source solution or a combination of open-source solutions to come up with a unified product, there may be several challenges.

This article discusses prospective solutions/processes that would help design well architected products that are built using primarily open-source solutions as its sub-components, in-turn driving the adoption of open-source.

Motivation

Recently, as part of the “Future Products and Innovation” team at the “Emerging Technologies and Incubation” group at Cisco, our team has been working on exploring several open-source solutions for a holistic data landscape.

We researched several open-source solutions, trying to see how these would fit into a data landscape. This got me thinking-How can we design processes around easing open-source adoption?

Ideally, it would be similar to how cloud vendors have built processes and tools to ease their cloud adoption journey.

Problem

As we combine several open-source solutions and try to build a product based on that, integrating those with our in-house product, things start to get complicated.

• Which open-source solutions do you use?
• How do these open-source solutions rate on various factors? Licensing, developer community, ease of use, ability to contribute, design and architecture, customer adoption, product roadmap etc.
• How do these open-source solutions interact with each other — Are they compatible — do they complement or contrast each other?
• Are they modular enough to be plug n’ play solutions — so you can pick and choose the right features from each?
• Do they expose enough APIs that will help integrate — how convenient is it to add more?
• How easy is it to modify the interfaces to make them seamlessly work with each other?
• Can they be deployed standalone or have dependencies — what’s the deployment strategy?
• How do these open-source solutions fit into the overall product architecture?
• How do you ensure you integrate with them, while not violating good architecture principles?
• How do you make all this a time efficient process?

And the list goes on …

Well, let me ask you this? How about if we had a framework, a toolkit to guide us through the process of architecting our products that are based on open-source solutions or maybe hybrid solutions using open source and in-house developed projects.

With all major cloud vendors, there is a well-architected toolkit or a well-architected framework that provides guidance on how to build and architect your products on the cloud. As an example, AWS offers the AWS Well architected framework and the AWS Well architected Tool, which helps you review the state of your workloads and compares them to the latest AWS architectural best practices, while guiding you through the process. This is true for other cloud vendors as well.

There are cloud solution architects that offer help with architecting products on the cloud. There are solution architects, enterprise architects, technical architects that help with designing solutions using a multitude of products.

But do we have either of those dedicated to open-source? NO

- There is no Open-Source Well architected framework/ toolkit per say. There are several resources that we can refer to, but coming from disparate sources, it is a rather time and effort consuming process.

- There is no explicit Open-Source Solution architect position in the industry. Engineers/Architects/Solution Architects/Product leaders replace them. They need to keep themselves up to date with the evolving open-source community and the new solutions that are launched.

Solution

There cannot be a ‘one size fits all’ kind of solution to this problem. But can there be a middle ground?

Can we have a hybrid solution — combining an Open-source Well architected framework, an Open Source Well architected toolkit, supervised by an Open-Source Solution architect?

- Open-Source Well Architected Framework

This could focus on the architectural principles that have commonalities with the microservices design patterns and general distributed system design principles, focusing more on the factors that would ease the integration between open-source solutions as well as building hybrid solutions comprising open-source and in-house products.

- Open-Source Well Architected Toolkit

This could be designed as a toolkit that could provide users with different options for open-source solutions that can be used based on the filters and preferences they enter.

Provide important insights like concise reports on the open-source options, compatibility scores with other open-source options etc. Additionally, indicate if the choices adhere to the Open-Source Well architected framework and provide tips on design modifications. Of course, this would include a human in the loop.

- Open-Source Solution Architects

This is mostly an extension of the current role performed by say, Engineers/Technical Architects/Solution Architects. This is different from an open-source advocate/evangelist role, that focuses more on advocating specific open-source products. The distinction being that — an open-source Solution architect would primarily be responsible for evaluating different open-source solutions to see how they would fit into the current product landscape.

Benefits

• Would increase the adoption of open-source solutions.
• Would help design and architect solutions based on open-source with a quicker turn-around time. This is especially important for the “Design Thinking” approach used for Innovation products.
• A single repository of good design patterns, around designing products using open-source solutions.
• A single product to help you in designing products using open-source solutions.
• For open-source enthusiasts — a new position dedicated to working in open-source.