Written by Andreas Björnberg, VP Product Management
After 24 years of using C++/C and Python SDKs, and also developing special low-level SDKs for others, I will share my personal reflections on why it’s better to go with an SDK rather than “Do It Yourself” (DIY), implementing low-level functionality from scratch.
Software Development Kit
First, what is an SDK? SDK is short for Software Development Kit and is a set of programming libraries, tools, documentation and code examples that enable software developers to create applications. Libraries are files that contain pre-built pieces of code. With pre-built functionality, a product gets faster to market since developers don’t need to acquire the expertise on how to implement and optimize special functionality. You also save a lot of implementation time compared to the tedious and time-consuming process to develop everything from scratch. Using SDKs, you as a software developer can focus on your own product and its core features instead of struggling with low-level functionality.
Functionality, stability and reliability
“But I have time and it’s fun learning the low-level stuff!”. I hear you, and I agree. If you have time, it can be well spent learning how the low-level stuff works. It can also make the future process of selecting the best SDK much easier. However, what about testing and reliability? Since an SDKs functionality has been carefully tested and its stability not only verified by the SDK provider, but also by their customers, the end product is more reliable. And what about product development resilience? What happens when the product is to be scaled up, when more developers are recruited and need to get productive quickly? And wouldn’t it be much more rational using the same and comprehensive code base for all products in the portfolio, that would drastically increase the opportunities for rational operation and growth? Finally, what happens when the developer that developed everything from scratch leaves the company?
High performance machine learning in a box
Simply, most often Doing It Yourself (DIY) from scratch is not sustainable. In Ekkono’s case, the SDK is specifically designed for bringing high performance machine learning to very small embedded devices that usually have very limited memory and execution abilities. We’ve invested thousands and thousands of hours researching and implementing functionality for this special task, and by using our SDK you can reap the rewards and get further quicker than if you started from scratch. One recent example of a customer that drastically decreased the time to market is Öresundsbron. We teamed up with our partner Acobia, who built a system for condition-based monitoring and maintenance of critical assets on the bridge, using our SDK. The product went from scope to implementation in less than three months, which would have been impossible if they had taking the DIY route of trying to develop it from scratch.
The selection of which functions to include and also their design is the result of feedback from the market and customers, often over several iterations, before reaching the right functionality. And we’re not stopping, we are adding more functionality, optimizing performance, getting compliant with more hardware platforms, etc.
Data scientists and machine learning engineers teaming up
“So SDKs are only for hardcore C++ developers”? Well, not really. With a clever set of APIs, you can make your low-level functionality available to more roles in your organization than just developers.
For example, in the field of edge and embedded machine learning, it’s common that a machine learning development team consists of at least two roles: a data scientist and an embedded software developer. The data scientist does the data understanding, modelling, training and evaluation of the machine learning model that is handed over to the developer who integrates it into the application, assures quality, develops automated routines for deployment, operation and monitoring of the system. Often included in the team is also an engineer, responsible for the overall design and operation of the system.
Ekkono’s SDK – for edge and embedded platforms
Ekkono’s SDK is a comprehensive machine learning toolkit for edge and embedded platforms. So it’s all there. The way we address the above roles is to have them all work with the same SDK by adding different APIs on top of the C++ implementation. The data scientist and the engineer use the SDK through a Python API, a .Net developer uses it through a C# API, and the embedded developer uses the SDK through the C and C++ APIs. Underneath the APIs there’s the same C++ and C implementation, and all functionality is available in all APIs, which improves the understanding and collaboration between the roles. It’s even possible for a data scientist or engineer to check how their machine learning model would work in a simulated system on their own PC or in the cloud. It might not yet be the target hardware, but it’s the same code base as it will be in the final system.
Automating the data understanding process
With that said, we see the definition of these roles changing. We are currently adding more high-level code blocks and AutoML tools that will speed up and automate the data understanding and modeling tasks. With these new technologies, we estimate that engineers can take a larger part of the machine learning tasks, decreasing the distance between design, operation and machine intelligence. And with the revolution in the maker / DIY space, making embedded hardware much more user friendly and accessible, we also see that engineers and data scientists start implementing end systems (or at least proof of concepts) on target hardware very soon.
Sustainable operation and maintenance
All in all, using an SDK over implementing it yourself is smart. Using SDKs results in more stable and reliable systems in a shorter time, and makes development, maintenance and operation scalable and sustainable. And selecting an SDK with a carefully designed API layer, the same base code and functionality can be used by multiple roles in the product development.
With SDKs you can simply reap the rewards – someone else has already done the heavy lifting.