Month: March 2025

In this blog post we till take a look under the hood of Open Source Cloud (OSC) and more specifically how our OSC architect is build. The purpose with the OSC architect is to guide and help business developers, solution architects and developers to build solutions based on open web services. Solutions that are based on open source offers flexibility and freedom from vendor lock-in.

The OSC architect is available in the web console or as a GitHub copilot chat participant in Visual Studio Code.

Retrieval-Augmented Generation

Our OSC architect is built on latest GPT large-language models and to produce answers more accurate for an OSC user we use RAG as the AI architecture. How it works is that when a question is asked, the system first searches through a database containing knowledge of OSC (guides, SDK documentation, blog posts, etc). This retrieved information is augmented and added to the context or prompt before passing it to the language model. Then the GPT model generates a response based on both the original query and the retrieved context.

Continuously updating the knowledge database

The knowledge database is a vector store of documents that is uploaded. For example markdown files of the documentation, HTML files for the SDK reference and blog posts. To maintain a database that is up to date with latest and relevant information we need an automatic way to update the vector store.

The document files from the various sources are uploaded to an S3 bucket and then we use an open web service in OSC to synchronize the contents of an S3 bucket with the files in the vector store. If a file is not available in the store it will be uploaded and if a file in the store is no longer on the S3 bucket it will be removed from the vector store.

This synchronization is triggered by a GitHub action workflow that is executed when the documentation site is updated for example. When the vector store is synchronized with the S3 buckets the knowledge base for the RAG has been updated.

This open web service and concept can be applied to other contexts where you want to augment the responses from a language model with domain specific knowledge. To get help in setting this up you can read the user manual for the “S3 sync vector store” open web service or ask the OSC architect for help.

OSC architect in your VS Code IDE

Based on above we offer a chat extension to Visual Studio Code where the developer can get help from the OSC architect when developing solutions. Install the extension and let the Copilot participant called “@osc” assist you in building solutions based on open web services. In this example I asked the OSC architect for help in storing Common Access Tokens in a database.

In addition to the knowledge base that is augmented this extension prompts the OSC architect to enhance the response with code examples as that is relevant in the context of a developer environment.

We are continuously improving the OSC architect as we augment the model with a larger knowledge base and on the roadmap is to support remote MCP (Model Context Protocol) to enable a seamless integration with AI agents and AI chat applications. So stay tune for more!

Open source as a service

The SmoothMQ project is a message queue that is a drop-in-replacement for SQS. It is open source and there is nothing preventing you from hosting it in your own private or public cloud infrastructure. To reduce the barrier to move to a solution based on SmoothMQ and open source in general we developed Eyevinn Open Source Cloud. A service where open source projects are made available as a service, an open web service, and SmoothMQ is one of those.

This makes it possible for you to start shifting your messaging over to open source message queues without having to build up a self-hosting infrastructure for it first.

Feasibility study with open web service

Start with a practical feasibility study in the form of a proof-of-concept by taking a part of the workloads that your current web service handles and place it on a SmoothMQ open service. Develop an adapter that consumes messages from your current web service queue and place it on a SmoothMQ instance in Eyevinn Open Source Cloud. This adapter can be deployed and running as a Web Runner. Then have some of your workers to consume work from the SmoothMQ message queue. This gives you the opportunity to validate, identify gaps and estimate the effort to make the move without having to invest time and money in building up your own infrastructure first.

By now you should have the necessary information to scope and initiate a transition project.

The transition project can use the same approach by off-loading some of the workloads from your current web service and shift it over to open web services. Gradually make the move under the comfort that you can always fall back to current web service if you discover any problems along the way. Also, you have not had to make any large up-front infrastructure investments before you know that everything will work.

Move from open web service to self-hosted infrastructure

When you are comfortable that the open source based solution works you can start the project to build up your own infrastructure for this. As the open web service is open source and not bound to either Eyevinn Open Source Cloud or its underlying infrastructure you can run the very same software in your infrastructure. What provider of cloud (or on-prem) infrastructure you choose is fully up to you.

No larger modifications to the open web service based solution would be necessary as it is the very same software running.

Stronger independence

Now you are in a stronger position as the video transcoding part of your media solution is not bound to one single vendor. To further strengthen your independent position, you can take on the next component of your solution where there might exist an open source equivalence and use the same approach.