A visual overview of Stackspot IDP from a Devops Engineer Perspective
Introduction
As a DevOps Engineer or Site Reliability Engineer in any IT department, it’s essential to have knowledge about a range of concepts, tools, and technologies. This includes various cloud providers, CI/CD tools, infrastructure as code, container orchestration, and coding—often all at once—to support production-grade applications, development environments, study time, and so on. It’s a never-ending cat-and-mouse dynamic that doesn’t scale quickly and can be a nightmare for cognitive load.
Creating self-service delivery systems and reducing friction in deploying software pieces is crucial to saving some breath for executing all the different activities described above. The DevOps movement and Google’s SRE framework have started some mechanics to achieve this, but there are still many loose pieces in this dynamic. This is where an Internal Developer Platform (IDP) comes in.
What is an IDP (Internal Developer Platform)?
An Internal Developer Platform is a set of tools, services, and processes that support and accelerate your software development while managing the underlying infrastructure. Source
One of the best features of an IDP is that it abstracts a series of steps:
Developers don’t need to know which IaC or CI/CD tool is used or which Cloud Provider is deployed. A modern developer needs three panes of glass: the IDE for coding, git for merging, and an IDP for shipping.
Stackspot
Stackspot is an IDP, or as they call themselves, an Enterprise Developer Platform (EDP). It’s designed for anyone—companies or developers—who need to standardize, scale, share, accelerate, and manage how they develop things and deploy them into production.
Stackspot is available in a SaaS model in two flavors: Personal and Enterprise. You can start using it right now for free with all major features using a personal account. Nice, isn’t it?
Stackspot Anatomy
There are three personas that interact with Stackspot:
- Account Holder: Manages permissions, organizes the company in the Stackspot environment, etc.
- Creator: Creates all the cool stuff, like application plugins, infrastructure plugins, workflows, and so on.
- User: Usually a developer who uses all artifacts generated by the creator to abstract away unnecessary objects for daily activities.
Of course, this is a logical division of duties and does not imply that a person acts as more than one persona. Now, let’s delve a bit deeper into Stackspot’s capabilities:
Account holders, creators, and users can access Stackspot in two ways: console and CLI. The console has a modern UI, and it’s quite easy to do anything you want from there:
Studios
Studios act as an organizational structure that allows for managing, creating, and sharing plugins and their capabilities. Besides sharing, it’s possible to define granularly how content is accessed.
Stacks
Stacks are logical compartments used to group plugins and starters that will be shared across all Stackspot ecosystems. A stack can be versioned, updated, and deprecated, fully aligned with a typical development workflow.
Plugins
This is where the magic happens. A plugin is a package written in YAML format in two flavors: app and infra. Essentially, we can do anything from an application scaffold, Python, or shell scripts, to infrastructure Terraform code. One of its powerful features is that Stackspot renders plugins using the Jinja template language, making a plugin highly reusable and customizable.
Starters
Starters are a set of predefined plugins of a Stack. Useful the act to group and preset a collection of plugin in determined pattern.
Actions
An action is a capability that allows the user to run scripts (shell or Python) in a workflow defined by the creator/user. It extends Stackspot’s capabilities when a repeatable or bureaucratic step is necessary within an organization, before or after an event, like a deployment, for example.
Workspaces
Workspaces are structures where all stacks, plugins, actions, starters created, and published are used, following some organization (using Conway’s Law or not, lol) or giving the company context, organization, and so on.
Environment
It’s an entity that helps organize resources reflecting deployment or cloud environments, like development, testing, production. Environments also allow for aligning applications and clouds according to resource dispositions.
Connection Interfaces
Connection interfaces are capabilities that allow for sharing cloud resource parameters in a standardized and friendly way. Think of it like a Terraform output shareable with anyone inside a Stackspot ecosystem.
Shared Infrastructure
It’s an easy way to generate Cloud Resources and share them with Stackspot.
Cloud Account
A cloud account is an entity that allows StackSpot to integrate with Cloud Providers (AWS and Azure, for now). This is the final piece to build a fully-fledged environment, using Workspaces, Stackspot environments, and Cloud Accounts, reflecting exactly a development workflow like dev, test, and prod.
Runtimes
Runtimes is a engine responsible to manage and provisioning resources on Cloud, like application and infrastrucute. Currently using Terraform as orchestration tool and come is in two Flavors: SaaS and SelfHosted.
Runtimes Saas
This version is responsible for connecting to the cloud using cloud accounts and provisioning infrastructure autonomously. It manages resources, dependencies, and stores .hcl code along with the Terraform state file
Runtimes Self Hosted
Extend the runtime engine to on-premises environments, offering them granular execution and increase governance, while also enabling the storage of .hcl code and Terraform state files. Currently delivered through containers encapsulated in GitHub Actions.
Cloud Providers
The target where resources (applications and infrastructure) are rendered. Currently AWS and Azure.
Conclusion
As demonstrated, Stackspot is a powerful platform that enables SRE or Platform Engineering teams to deliver self-service systems for developers, reduce friction in deployments, cognitive load, and increase the Developer Velocity Index (DVI). Overall, it’s an invaluable tool for abstracting complex infrastructure and its relationships, making it easier to build, manage, and share.
References
Any sugests or doubt?
Feel free to reach out to me on social media: twitter ,linkedin and github.
You can also email me directly at rmnobarra@gmail.com.
Support
Did you really enjoy my content? Consider buying me a coffee through my Bitcoins wallets:
Bitcoin Wallet:
bc1quuv5hml9fjkf7azgwkt4xp867pzdwzyga33qmj
Lighting Address:
lnbc1pjue6mkpp5yj737e7fm6efhlj6sns42a875pmkencqmvdshf4ghlnntaet5llsdqqcqzzsxqrrsssp5d9hxl686w839qkwmkm0m30cf5gp4gnzxh68kss393xqzlsg0wr3q9qyyssqp3933zc3fg46nk3vafh63r3lqd0jn2p04w5xrz77h33rrr3xm7ckegg6s2ss64g4rf4jg87zdjzkl5tup7umqpghy2qnk65tqzsnplcpwv6z4c
Bye!