Read the Kapeta Blog Post from KubeCon + CloudNative 24
Kapeta is a software platform purpose-built to handle the entire lifecycle of the development (SDLC), running and maintenance of cloud-based applications running on a container-orchestration platform such as Kubernetes.
The fundamental theory behind Kapeta is not new. By splitting software into smaller components we can make them modular. What Kapeta introduces towards this aim is the concept of a “Block” – which is a self-contained software component that – in its definition – contains all “inputs” and “outputs”. By detailing what a block needs or provides down to a protocol level we can start sharing software much more consistently and have much better insight into what the domain boundaries are for a given block. And by giving the software platform access to this detailed knowledge it turns out – the software platform can actually do most of the heavy lifting – all the way from code generation og boilerplate to detailed monitoring, scaling and debugging of large production systems.
Because of the isolated nature of blocks and their self-documenting definitions, blocks can be easily shared without any pre-existing knowledge about what they require or how to operate them. Blocks can be developed in-house or companies can leverage the Blockstore which contains many common-purpose blocks such as authentication, subscription management and more.
This fundamental concept enables many user cases and further allows much simpler collaboration across countries and continents in that it gives software engineers a language in which to describe software – what it needs and what it provides. This builds on the already rapidly expanding concepts of remote working and digital nomads.
Many companies have dedicated teams to create development tools and devops frameworks in order for the other teams to work efficiently. And on top of that, there are teams monitoring pipelines and production performance. Kapeta takes care of this and unleashes the true devops spirit for each team. Kapeta comes with developer productivity out-of-the-box. Through code generation Kapeta creates all infrastructure code, it takes care of deploying to the cloud provider of choice, it dimensions the systems based on actual usage and it reports back on performance through meaningful metrics. With Kapeta, software engineers can write code that creates business value and not wasting time writing infrastructure and boilerplate code.
In the following documentation we explain the different concepts you will meet when using Kapeta. You can read about each part in detail and learn how to use Kapeta in different scenarios – from a single software developer working on their own systems to full blown teams working with other teams on bigger systems.
Kapeta is a cloud platform where you have your own unique user profile and where you either work alone or work as a part of an organization. When working in your own user context, no one else has access to your code, unless it is published to the global Blockhub as a Block to to be used by other users. Organizations on the other hand is a group of users who work together on the same system. Organizations can be informal groups of users or owned by a Company. The users in an organization can have different permissions pertaining to their role in the software project.
No matter if you work alone or in an organization you work on Plans and Blocks which are central concepts of Kapeta. Plans are software systems that can be deployed and blocks are the elements of a plan. Blocks can be thought of as services, eg. a user service or notification service. A Plan can be deployed to a specific environment, such as Testing, Staging or Production. Plans are versioned and can be deployed to the infrastructure of choice – local servers or a cloud provider. Deploying is completely agnostic to the chosen infrastructure as it is literally a click of a button, whereafter Kapeta is doing the rest.
Plans deployed on Kapeta can be monitored through metrics and insights based on sensible default.
Kapeta can be used in three different ways: in a browser, in a desktop application and from a command line interface. All of them give different capabilities depending on the work that needs to be done and the person’s role. The web-application is mostly meant for account maintenance, metrics/insights and deploying of systems. All billing and subscription handling are exclusively taken care of in the web application. As the web application works in a browser and needs no installation, this is the go-to tool for people who are not using Kapeta to write software.
People actively producing software will download the desktop application which works on Windows, Ubuntu and Mac. Through the desktop application, users can run their software locally and it is an integral part of the software development. The command line interface is the part of Kapeta where many developers will spend most of their time. The command line tool has all the functionality needed to download code, work with versions, trigger code generation and to publish code.
Everything, such as Blocks and Plans, in Kapeta is essentially an Asset. Assets can depending on their type be versioned, deployed, consumed, used by other assets. You can think of Assets as super types to Plans, Blocks etc. When downloading an Asset, you will always find a kapeta.yaml file where the specific type and its properties are declared. It looks like this:
kind: kapeta/block-type-service:1.1.0
A Plan describes all the parts of an actual software system, such as business services, databases, frontends, files systems. A plan describes the interrelationship between the different parts and can be deployed locally while doing active development, and when ready, deployed to a cloud provider and monitored. Plans can only be deployed locally using the desktop app and not the web app, whereas they can be deployed to the cloud provider from both apps. The app needs access to the filesystem in order to deploy, and that is for security reasons in the browser, only possible in the desktop app. Plans can be versioned which is essential when they are being deployed in order to reason about the current version but also in order to deploy older versions in case of regressions.
A Block is a self contained part of a Plan. A Block can interact with other Blocks by consuming inputs, processing the inputs and providing outputs. Blocks are building blocks which seamlessly integrate with each other, exposing inputs and outputs, but hiding implementation. A Block can be developed in house or be downloaded as third party Blocks. Kapeta is built on the foundation of the micro service paradigm, so it is encouraged to split out functionality into blocks. When applying this way of designing systems, Kapeta will be very powerful as you can download Blocks providing functionality not specific to your domain, while you can focus on building the Blocks essential to your product.
A Block is defined by the following attributes:
A Block is a self contained part of a Plan. A Block can interact with other Blocks by consuming inputs, processing the inputs and providing outputs. Blocks are building blocks which seamlessly integrate with each other, exposing inputs and outputs, but hiding implementation. A Block can be developed in house or be downloaded as third party Blocks. Kapeta is built on the foundation of the micro service paradigm, so it is encouraged to split out functionality into blocks. When applying this way of designing systems, Kapeta will be very powerful as you can download Blocks providing functionality not specific to your domain, while you can focus on building the Blocks essential to your product.
A Block is defined by the following attributes:
Example of how a language target are declared in the kapeta.yml file:
kind: kapeta/block-type-service:1.1.0
spec:
target:
kind: kapeta/language-target-nodejs:0.0.25
Resources are components and technologies that a block usually needs in order to work properly. Blocks rarely live in a vacuum and need to interact with other blocks or databases. Resources can be rest clients, file systems, APIs and they can be consumed or provided by the Block. We differentiate between two types of resources, Internal resources and Operators:
The illustration above is showing a block exposing a rest interface to other blocks while having a database for storing data and a smtp client for sending emails . That block would then have three resources, an internal one and two operators.
In order to deploy your plan, you need to specify a deployment target which then will inform Kapeta to which cloud provider the plan should be deployed. This allows Kapeta to generate and hide away all infrastructure code which is needed to deploy the service to a hosting provider, typically a cloud provider. Kapeta currently supports Google Cloud Platform (GCP) and can be used for production grade deployments. In order to truly make an ecosystem that everyone can be a part of, no matter the programming language, operative system or infrastructure, we will be supporting the major cloud providers such as AWS and Azure.
Environments are the combination of a plan and a deployment target. The combination of the two tells where the plan should be deployed. You can have different environments if you want to have your plan deployed at different service providers.
Kapeta has the notion of Stages (Test, Staging, Production) in order for you to safely deploy versions of your plans that aren’t production ready and move them through the different stages. We will make this a build pipeline and will be supporting safeguards down the line where specific conditions need to be met before moving code from one stage to the other, eg. passing an integration test suite.
It is possible for software developers who work on a Block in a plan to run the plan locally. This will spin up a local Docker cluster where all the services are run. This makes for an efficient workflow where it isn’t necessary to work against a remote system. This feature is available in the desktop app.
Deployments can be initiated both in the desktop app and in the web app. It is possible for people who aren’t engineers to deploy plans. If you are a Product manager, then you can easily get an overview of what version of the plan that is running and if any new updates need to be deployed. We make it possible for teams to take on a separation of duties approach where the Product manager essentially is in charge of deploying the software.
Join us on this exciting journey as we redefine the future of software development. It’s not just about writing code; it’s about making dreams come true.
Solutions
Kapeta Inc. US
548 Market Street
Suite 44932
San Francisco
CA 94104
Kapeta Inc. London
One Canada Square
Canary Wharf
London
E14 5AB
©2024 Kapeta.com
Kapeta Inc.
548 Market Street
Suite 44932
San Francisco, CA 94104
Sign up and get latest articles on the newest technologies, AI Code generation and much more
