Nowadays we hear about Internal Development Platfo...
# general
h
Nowadays we hear about Internal Development Platforms everywhere, and we strive to build a customized Platform that integrates with all the tools required for a DevOps or Platform engineer to guarantee a high-performing infrastructure to enable rapid software development process. However, building a platform requires a lot of effort to integrate with a variety of tools, each with its own state, different syntax and language. The available platforms in the market target general solutions, and require a subsicription for something that can’t be modified. The market has no framework -yet- to help you build your own platform to solve your own use-cases. HAPE Framework aims to fill the gap in the market, and provide a framework to simplify the work of Infrastructure and Automation management by enabling engineers to build a personlized centralized solution, customized to fulfill different use-cases each time. At the moment it’s still in very early stages, but there is a lot of potential to build a framework that benifits everyone. If you’re interested in contributing feel free to email the Author. Hazem Ataya: hazem.ataya94@gmail.com https://github.com/hazemataya94/hape-framework
c
Hmmm… could you describe where the difference of this against CNOE will be, when there is a bit more than scaffolding in place?
h
of course, I'd be happy to tell you the difference CNOE is already a tool, whereas what I'll provide is a framework to build tools. The problem with pre-made tools is that they already dictate the tech-stack you need to use, CNOE integrates with argocd and backstage and a few pre-defined tools that you must use in order to use CNOE. Also, customizing it would mean customizing the main tool. HAPE Framework will provide you with the framework to build CLI and API tools. Suppose you want to extract data from kubernetes api, and save it to database, you have to create this functionality from scratch. Whereas if there is a framework that auto generates the models, controllers, argument parsers and api controllers, and that already has a kubernetes client integrated with kubernetes. Then all you have to do is generate the MVC files and you'll have a cli/api ready to use. Same if you want to extract data from git (github, gitlab, bitbucket) and prometheus and AWS and process them and save them in one table in the database. You'll have to start development from scratch, but with a framework you can save a lot of time building the database and integrations. HAPE Framework is used to build customized automation tools with ease. However, it's not an automation tool, it's not like CNOE or any other available automation tool in the market, because it's not a tool by itself.
think of the difference between HAPE Framework and CNOE like the difference between Laravel (framework) and a website already running on Laravel (app built using the framework)
Another helpful example, let's say you want to get your DORA metrics based on your development process and tech stack -each of them change from a company to another-. You either need to add a new paid 3rd party tool that you'll need to modify your process to fit. Or need to build it from scratch with no modern framework to develop your cli/api tool, which means a huge amount of work. Frameworks for developers is like a fully equipped workshop for a carpenter. A web framework enqbles you to develop a website in a matter of weeks, days, if not even hours. The same thing will be for platforms with a platform framework. You'll be able to create your own models, logic, using the generated files, database, cli handling, api handling. You just focus on creating your business logic, making the new tool to calculate DORA metrics for your development process and tech stack only a matter of few days away instead of weeks and months. And this is the goal, to simplify developing customized personalized cli/api platforms.
c
I think you need to review CNOE again. First of all, it’s basically a tool to bring components together. What you’re referring to, is the “reference implementation” - including Argo and Backstage - but you could also run a very different setup without them. That being said, I think what you’re trying to build is verily something different. I am not completely sure how I would categorize it, but I would not try to fit it into “building your own platform” arena. From your description, you’re closer to a RAD framework for k8s - just missing some GUI components.
h
To be honest I haven't used CNOE before, but it got my attention. I'm going to dive deeper in it in the upcoming few weeks.