Knowledge Library
Welcome to your go-to hub for all things platform engineering. Dive into expert insights with our blog, explore in-depth resources in our library, tune into inspiring conversations on our podcast, and watch engaging videos packed with valuable tech knowledge.
Compte tenu de la chaleur qui a étouffé l’Europe l’été dernier, il faut reconnaître que des mesures urgentes doivent être prises par tout le monde. Oui, tout le monde, pas seulement les gouvernements et les acteurs du secteur de l'énergie. L’univers des technologies informatiques ne déroge donc pas à la règle et a son propre rôle à jouer. Pour ceux d'entre nous qui travaillent dans ce secteur, ce rôle implique notamment l'adoption du GreenOps. Alors, en quoi consiste cette approche, et pourquoi le monde en a-t-il besoin?
Selon des études de l'Université d'Oxford, l’empreinte carbone annuelle d’un seul ordinateur de bureau standard utilisé pendant 6 ans s’élève à 778 kg de CO2. Les émissions dues au cloud computing (ou informatique en cloud) sont souvent négligées ; elles représentent de fait entre 2,5 % et 3,7 % des émissions mondiales de gaz à effet de serre. Elles dépassent ainsi celles des vols commerciaux (environ 2,4 %), et de plusieurs autres secteurs essentiels qui alimentent l’économie mondiale.
Le GreenOps est avant tout un système qui permet aux organisations de comprendre les impacts de leurs stratégies informatiques, tout en encourageant la responsabilité environnementale à tous les échelons de l’entreprise. Considérez-le comme une forme de FinOps, un système de gestion des dépenses d’exploitation, mais dont la mission est de préserver la santé de notre planète.
Le grand défi de l’approche GreenOps est celui de la durabilité d’un écosystème informatique complet. En effet, une vue d'ensemble de la répercussion environnementale de chaque élément est nécessaire. C'est pourquoi, pour assurer le bon fonctionnement du GreenOps, la collaboration de tous les acteurs au sein de l'organisation, du service informatique aux RH, en passant par le marketing et la comptabilité, s’impose. Tous ces services doivent se charger de la définition des besoins de l'entreprise, ainsi que de la supervision du développement de logiciels et des processus DevOps, en adhérant à des principes de fonctionnement. Pour ce faire, l’avènement d’un nouvel état d’esprit parmi les leaders et responsables du secteur informatique est indispensable, et ce dernier permettra leur participation au débat général sur la durabilité.
Une fois que chaque employé, à tous les niveaux d'une organisation, prend conscience de son rôle dans la réduction de l'empreinte carbone, la société peut alors entreprendre de viser des objectifs autant en durabilité qu’en informatique.
Comment s’y prendre ?L'”écologisation” de l'ensemble d'une infrastructure informatique implique de faire du développement durable une priorité absolue. Faire de la décarbonisation un ICP (indicateur clé de performance) au même titre que la croissance du chiffre d'affaires, ou que la marge bénéficiaire, voire que la satisfaction des clients, est la démarche à suivre pour ancrer l'environnementalisme dans la culture d'entreprise. Ce n'est pas toujours évident, d'autant plus que de nombreux fournisseurs du secteur informatique s’autoproclament « durables » sans expliciter ce que cela signifie. Heureusement, la technologie numérique garantit une offre informatique plus verte.
La numérisation est une occasion de créer un monde plus durable en rendant les processus plus efficaces, mais elle n'est pas exempte de difficultés : en règle générale, plus les solutions numériques sont sophistiquées, plus elles consomment de ressources. En fin de compte, plusieurs approches sont possibles dans l’optique du GreenOps. En ce qui concerne les services cloud, qui contribuent sans l’ombre d’un doute à réduire l'empreinte carbone d'une organisation, il est important que les équipes informatiques disposent d’outils adaptés pour déterminer si les services cloud sont utilisés de manière inefficace mais aussi savoir comment rectifier la situation. Comme pour toute décision informatique, il est important de s'assurer qu'une organisation optimise son efficacité et son budget, mais grâce au nouveau prisme du GreenOps, cette optimisation recouvre également un sens du point de vue de la durabilité.
Le GreenOps est un élément capital de notre parcours vers un avenir durable. La prise de conscience collective de l’urgence climatique appelle à la reconnaissance des leaders du secteur informatique de leur rôle vis-à-vis de la décarbonisation.
...
What makes a successful and sustainable platform engineering portal? Is it the level of observability it permits? Is it how many useful things it can do with your Terraform? Is it how customizable and user-friendly it is?
Well, yes, all this and more. This is the fifth article in our series on sustainable platform engineering and we’ve discovered that the sustainability of a portal isn’t always obvious at first sight - but one thing is crystal clear. Building a platform engineering portal is a colossal waste of money and time - and therefore very unsustainable - if no one uses it. You need to make sure the possible dealbreakers are addressed long before you ever make a move or else sustainability will be nothing but a pipe dream.
Defusing the dealbreakers
One way to avoid these dealbreakers is to focus on them before you even think about creating any features. One of the most important of these “dealbreaker defusions” is the one we’ll discuss today - governance and security. In this domain, balance is everything and if your team have so much of an inkling that it’s off-kilter, your platform will be sunk before you can even say “principle of least privilege”.
The overall aim for security and governance in platform engineering is to keep things tight enough to keep ops happy and flexible enough to keep users happy. Too tight, and all of the positive DevX attributes that teams love like confidence, autonomy, and self-learning will be completely absent (ops lock things down so techs are unable to make any security decisions for themselves). Too loose and, obviously, it will be a free for all that would risk losing money (wasting paid-for cloud resources) and almost certainly compromise the security of the business.
In many organizations, however, governance is still a bit of a dumpster fire. There’s a lack of clarity and a sense of randomness about policies and best practices and, as a result, infra management and resources. It’s also one of the few places where you can have a clear and direct impact on sustainability - clear up the mess, impose order, and start proactively streamlining and optimizing your usage. But when it comes to imposing order, there’s a risk of the extremes we spoke about earlier - and it’s that risk that might undermine the usability of your platform.
Getting the balance right
There’s a sweet spot, a compromise between the needs of Ops and the experience you offer your users - get it right, and your portal will thrive. Here’s what we think you need to concentrate on:
User experience: excellent user experience, especially when it comes to traditionally sticky areas like governance, can really up your chances of a platform being a success. When you’re enabling specific and fine-grained controls from the Ops end, the way they are presented to the users is key - without an accessible interface that allows people some degree of autonomy and independence about their decisions, tight controls are annoying and undermining. The perfect solution is to pre-program really specific security options but conceal any complexity behind a user-friendly interface. This means that techs can confidently and autonomously make decisions about ops-related topics, but the only options available to them are ones that have already been okayed by those who know.
IaC adoption: good governance is made infinitely easier by the adoption of infra-as-code, facilitating better management and making it possible to create a centre of excellence within your organization. As ever, the better managed a situation is, the more sustainable it is - you cut out waste, streamline processes, and easily keep an eye on all the goings-on. At Cycloid, our governance and security tools are based on Terraform, so the tool you’re going to use to render all of your resources in IaC is an important step in the process. Infra Import creates automatically generated Terraform that allows you to always apply pre-defined best practices and help track infrastructure drift. Then, once the IaC is in order, we use InfraPolicies, the Terraform-based implementation of Policy as Code, to provide control over changes to your infra while simultaneously defining validation rules.
Quotas, automatic approvals and role-based permissions: when you have well-controlled governance, it becomes easy to set up appropriate quotas and permissions, even when you have multiple roles or even businesses to deal with. This removes risk and decision fatigue from non-expert members of your team. On a larger scale, they also contribute to sustainability, since you can keep precise and proactive track of resources, which in turn avoids waste and helps you optimize spending. Cycloid does this with Roles and Multiple Organizations. Meanwhile, Quota Management offers unobtrusive governing constraints to limit resource consumption. Your ops team will set resource quotas for private clouds (Nutanix, VMWare) in advance and control exactly who can consume what.
Playing the long game
It’s the platform engineering team’s job to make sure you get the governance balance right. It’s something that will need to be carried out with the help of the Ops team and the feedback of everyone involved, but it’s something you should oversee and, crucially, help translate into your portal’s reality. And implementation is where a 3rd party tool can help - it can provide the buffer and UX-strong link between the tight controls your Ops need and the flexibility techs want. It can offer ways of hiding tight controls and fine-grained options behind an interface that everyone can use and that’s no small order.
We hope you see better how governance and sustainability are linked. Governance amps up visibility and observability and what can be properly seen can be properly controlled. When you can control something, you can ensure it’s working as efficiently and rationally as possible. That’s the essence of sustainability, and if you achieve that on your platform team or the portal you produce, you’ll be in the best possible position to play the long game - for both your business and the planet.
- What is sustainable platform engineering?
- Stepping into the future: modernising infra as the foundation of platform engineering
- Get your automation right: how to build developer self-service your team will use
- Governance and security: finding the sustainability sweet spot
{{cta('2fa281d7-afe7-428b-94b2-6e02f8188729','justifycenter')}}
...
Le Platform Engineering constitue une approche de plus en plus attractive dans le domaine de la livraison de logiciels, car elle présente des avantages tels qu’une mise en marché plus rapide, une satisfaction accrue chez les développeurs, et une augmentation de la synergie entre les équipes. Nous avons déjà écrit au sujet du Platform Engineering, en expliquant qu’il ne s’agit en fait pas d’une pratique inédite, et que le DevOps n’est pas devenu obsolète. Cependant, compte tenu du nombre d’entreprises qui ont eu du mal à générer de la valeur commerciale grâce au DevOps, ces dernières considèrent peut-être que la construction de plateformes numériques internes pour favoriser la livraison de logiciels est une stratégie qui permet de bénéficier de tous les bienfaits du DevOps.
Mais comment ne pas tomber dans le piège qui a empêché 80% des entreprises d’adopter le DevOps?
Notre conseil est le suivant : traitez votre plateforme comme vous traiteriez un produit interne, et les utilisateurs de votre plateforme comme vos clients. En l’occurrence, vos indicateurs de réussite, riches d’une touche de Platform Engineering, devraient être similaires à ceux employés pour vos clients.
Les objectifs fondamentaux du Platform Engineering
Lorsque vous établissez vos indicateurs de réussite, assurez-vous de ne pas perdre de vue les buts de votre stratégie de Platform Engineering. Nous vous présentons les principaux objectifs des entreprises pour leurs équipes sur les plateformes, selon le rapport de 2023 sur l’état du DevOps.
L’éducation et l’émancipation des équipes de développeurs et de conception sont des priorités capitales pour les équipes de plateforme, et elles sont complétées par la vitesse d’itération et la sécurité des processus. Cette approche centrée sur le personnel doit se retrouver dans vos indicateurs de réussite. La réinvention des outils ne représente que la moitié de la tâche : vous devez également vous assurer que vos équipes ont bien maîtrisé l’utilisation des nouveaux systèmes. Les processus de rationalisation et d’automatisation inspirés par les meilleures pratiques de DevX favorisent la productivité générale de l’entreprise ainsi que sa démarcation sur le marché.
Les ICP du Platform Engineering
Selon le report mentionné plus haut sur l’état du Devops, la majorité des entreprises qui ont adopté le Platform Engineering ont constaté des améliorations aux niveaux suivants : fiabilité du système (60%), productivité et efficacité (59%), flux de travaux (57%), auxquelles s’ajoutent une amélioration du temps de développement pour 42% de ces sociétés.
La productivité
Compter le nombre de lignes de code produites par les développeurs sur une période de temps donnée est un indicateur dépassé, qui n’intéresse aujourd’hui que des profils comme Elon Musk. La productivité des développeurs est un sujet sensible, et bien que le Platform Engineering garantit l’accélération de la mise au point de logiciels, celle-ci ne s’opère pas en augmentant les rendus des développeurs.
L’idée, c’est plutôt de leur offrir les meilleures conditions de travail possibles. Pensez à tous les obstacles et contretemps que vos équipes doivent affronter au quotidien et à leur dépendance vis-à-vis des experts pour travailler correctement. Les déploiements d’infrastructures complexes, la création de nouveaux environnements et de fonctionnalités de livraison, sont quelques exemples qui nécessitent une intervention DevOps, ce qui ralentit inévitablement les processus. Les ICP centrés sur la rationalisation et la simplification du processus de livraison de logiciels devraient être votre priorité.
- Délai de production
Il s’agit d’une mesure qui calcule le temps entre la mise en place du récit utilisateur et sa livraison. Ce temps comprend les discussions sur le récit utilisateur, l’attente dûe aux retards, et la durée entre la sélection du récit et sa distribution finale.
Si votre délai de production est trop long, c’est le signe d’un obstacle au niveau des processus, qui conduit à l’éternisation des retards. Automatiser tout ce qui peut l’être limitera votre délai de production, car il s’agit d’une preuve de la proactivité de vos équipes pour atteindre leurs objectifs et s’adapter aux retours.
- Fréquence de déploiement
Cette mesure suit la fréquence des déploiements de code en production par l’utilisateur final. Elle permet d’estimer la valeur que peut apporter vos équipes d’ingénieurs à vos clients. Peu importe l’optimisation du flux de travaux, sa valeur peut s’avérer insuffisante si les déploiements sont trop peu fréquents.
- Satisfaction des développeurs
On pourrait se dire qu’associer le bonheur des développeurs à leur productivité est peu éthique, mais il s’avère heureusement que le niveau de satisfaction des développeurs est proportionnel à leur productivité. Le Platform Engineering vise justement une meilleure expérience pour les développeurs, ce qui explique l’importance de vérifier vos statistiques DevX.
La stabilité
La stabilité mesure la marge d’action des ingénieurs de production pour opérer des changements sans compromettre l’expérience du client final.
- Taux d’échec des modifications (CFR)
En suivant cet indicateur sur le long terme, vous pourrez estimer les efforts alloués à la solution des problèmes ainsi que ceux destinés au déploiement de code nouveau. Lorsqu’il affiche plus que 15 %, cela signifie sans doute que vos équipes passent trop de temps à régler des problèmes. Ce temps aurait pu être plus productif, certains processus doivent être optimisés.
- Temps moyen de réparation (MTTR)
Même les équipes de DevOps les plus aguerries font face à des difficultés et des imprévus de temps à autre. Les échecs sont inévitables : il s’agirait de savoir combien de temps il faut pour que les activités reprennent leur cours habituel après qu’ils se produisent.
L’efficacité
La productivité et l’efficacité sont souvent traitées de manière interchangeable, mais nous voulons nous pencher spécifiquement sur des indicateurs de rentabilité, qui comprennent le coût des ressources cloud, des infrastructures, des licences, et des équipes de Platform Engineering. Cette approche fait la part belle à l’utilisation efficace des ressources, donc les modules de FinOps et de GreenOps favoriseraient votre stratégie de ressources.
- Allocation de ressources
- Observabilité des coûts
La connaissance des objets de vos dépenses vous permettra de mettre un terme aux dépassements des coûts dus au cloud et au gaspillage. Comme nous l’avons déjà expliqué, l’efficacité de l’utilisation des ressources est un des piliers du Platform Engineering, et c’est pourquoi nous encourageons les entreprises à privilégier la sobriété dans leur consommation du cloud.
Des ICP de coût transparents sont essentiels pour atteindre ce but. Offrir aux utilisateurs finaux ainsi qu’aux équipes sur la plateforme la possibilité de constater les répercussions financières de leur architecture avant le déploiement, en plus d’une vue d’ensemble holistique de tous les coûts relatifs au cloud, est l’élément charnière sur lequel repose la réussite de vos projets.
Les tableaux de bord des ICP du Platform Engineering
La plupart de ces ICP relèvent d’une responsabilité partagée entre les équipes : il faut le garder en tête lorsque vous regardez ces indicateurs. La transparence et l’observabilité participent à l’amélioration de la collaboration entre les équipes, donc des tableaux de bord des ICP exhaustifs et partagés sont à envisager. Voici, par exemple, à quoi ressemblent les ICP à Cycloid :
Ce qu’il faut retenir
En raison du fait qu’un tiers des équipes de Platform Engineering doivent encore faire face à la réticence des autres équipes dans leur organisation quant à l’adoption d’une plateforme, vous devriez surveiller le progrès de cette adoption, et le considérer comme un ICP plus général. Après tout, la plateforme est censée aider l’ensemble de l’entreprise et favoriser le rapprochement entre les équipes ; cela requiert une coopération de la part de tous.
Peu importe les indicateurs que vous choisissez, il faut rester réaliste au niveau des attentes de l’entreprise pendant les premières années de l’adoption d’une équipe de plateforme. Vos ICP évolueront au cours de votre parcours de Platform Engineering, mais au début, votre objectif devrait être de rendre l’ingestion et l’exploitation des données beaucoup plus aisées pour vos équipes.
Vous êtes intéressé par Cycloid Platform Engineering ? Recevez une démonstration personnalisée par notre équipe
{{cta('168578582557')}}
...
Le module Cloud Carbon Footprint (Empreinte carbone du cloud) est la nouvelle fierté de Cycloid : il s’agit d’un outil intégré à notre solution FinOps qui sert à mesurer les émissions carbone. Notre approche est unique : nous combinons le GreenOps et le FinOps afin que vous puissiez mesurer au même endroit vos dépenses budgétaires et vos répercussions environnementales découlant de l’utilisation du cloud. Notre but est de promouvoir ainsi une culture de sobriété, qui favorise la conscience écologique des entreprises et qui réduit le gaspillage lié au cloud.
Ceci n’est pas un nuage
Il semblerait que la plupart d’entre nous tend à oublier que le « cloud » n’est pas un nuage du tout, mais plutôt une série d’imposants bâtiments de béton remplis de serveurs qui nécessitent un refroidissement constant. Il n’est pas surprenant de constater que l’électricité combinée nécessaire pour alimenter ces serveurs se traduise en une empreinte carbone conséquente, qui affecte profondément l’environnement. Les émissions de carbone liées au cloud computing vont de 2,5% à 3,7%, dépassant de fait celles des vols commerciaux (2,4%), et au fur et à mesure que le monde se numérise, nous devons nous attendre à une augmentation de ces chiffres. Regardons la vérité en face : les entreprises qui ont recours au cloud doivent prendre des mesures concrètes pour réduire leur empreinte carbone ; et c’est là qu’intervient la nouvelle solution de Cycloid.
L’empreinte carbone du cloud en détail
Le dernier module GreenOps de Cycloid fait partie intégrante de notre solution FinOps – Gestion des coûts du cloud. Il affiche les données relatives à l’empreinte carbone et vous offre une vue d’ensemble à la fois sur votre consommation du cloud et sa répercussion sur l’environnement. Notre objectif est triple, il se rapporte aux trois défis principaux que doivent relever les organisations en matière de gestion de l’empreinte carbone du cloud.
- Observabilité et données réelles
- Compréhension des données d’un point de vue humain
- Plan opérationnel clair
Watch the product demo
Données précises sur l’empreinte carbone du cloud
L’outil de gestion Cloud Carbon Footprint s’appuie sur une méthodologie d’émissions sophistiquée inspirée par le Projet open-source sur l’empreinte carbone du cloud. Nous avons décidé d’adopter une approche ascendante, où nous avons confronté l’utilisation des ressources atomiques du cloud à la conversion d’énergie, à l’efficacité de la consommation énergétique, et aux mesures des émissions du réseau. Cette méthodologie est expliquée dans le schéma ci-dessous.
Cette méthodologie permet l’accès à des informations claires à tous les niveaux, que ce soit la chronologie, les projets, les environnements, les clouds, les services, ou autres, afin de surveiller ce qu’il faut.
Les informations sont ensuite affichées à côté des coûts du cloud, et elles peuvent être filtrées de la même manière que celles sur vos dépenses cloud ; selon le fournisseur, le projet, la date, la région, etc.
Le rapport au monde réel
Maintenant que vous avez toutes les données sous la main, vous pouvez enfin faire preuve de durabilité numérique… Mais quand on y pense, que signifie concrètement 298,33 kgCO2 ? Est-ce trop ou pas assez? Quel est le degré de durabilité de votre consommation cloud ?
Peu de personnes sont rompues aux subtilités des calculs des empreintes carbone, c’est pourquoi le module Cloud Carbon Footprint inclut des équivalents concrets pour chaque information ponctuelle. Par exemple, 298.33 kgC02 est l’équivalent de 4 vols Paris-Bordeaux. De quoi nourrir notre réflexion sur nos habitudes de voyage et sur notre consommation cloud !
Consommez et dépensez moins
Les principes de durabilité de Cycloid reposent sur le concept de sobriété : consommons et dépensons moins. Après tout, peu importe à quel point certaines options de centres de données sont « vertes », la seule manière de vraiment limiter votre production de carbone est de limiter votre consommation cloud au strict nécessaire.
Selon Gartner, 26,8 milliards de dollars de gaspillage sur le cloud ont été générés au total en 2022 par les entreprises ; on a payé et fait tourner ces serveurs… pour rien. Il s’agit non seulement d’une dilapidation insensée mais aussi d’un gaspillage intolérable des ressources faiblissantes de la planète, ce qui contredit tout principe de durabilité du cloud.
En offrant aux organisations l’occasion de mesurer concrètement leurs émissions carbone, nous voulons les convaincre de prendre des décisions plus écologiques. Ne laissez pas les serveurs tourner pendant les week-ends. N’utilisez que les ressources dont vous avez besoin. Suivez vos dépenses cloud de plus près, et optimisez votre utilisation.
Votre budget ET l’environnement y gagneront : surtout maintenant que le monde traverse une autre crise financière et que la bulle spéculative du secteur technologique est en train d’éclater…
Dernier point : le GreenOps n’est pas facultatif
Cloud Carbon Footprint est la seule fonctionnalité de Cycloid qui ne peut pas être désactivée (c’est dire). Chez Cycloid, nous sommes fiers de promouvoir la souplesse décisionnelle : vous pouvez choisir des modules et assembler une plateforme personnalisée et engagée qui répondra parfaitement à vos désirs - ni plus, ni moins. Lorsque nous avons décidé de faire du GreenOps une fonctionnalité non facultative, nous avons pris position contre le gaspillage numérique, les dépassements de budget, et la consommation cloud irresponsable. Cela encouragera les entreprises à prendre en compte les répercussions écologiques de leur activité. Nous sommes conscients que Cloud Carbon Footprint n’est pas LA solution au dérèglement climatique ; mais pour beaucoup, cet outil représentera la première étape d’une consommation réfléchie.
Si vous souhaitez soutenir cette position et gérer votre consommation cloud, cliquez sur le bouton ci-dessous pour assister à une démonstration en direct par notre équipe qui vous présentera la solution Cloud Carbon Footprint.
{{cta('168578582557')}}
...
Build it and they will come. That’s the idea, right? But you may have realised, perhaps through a process of failure (we hope not), that that’s not a reliable way to guarantee an audience.
This is how it’s likely to go down - your organization needs to evolve, so the platform team is tasked with building an IDP (internal developer platform) that will streamline, optimize, and rationalize your software development process. But wouldn’t it be great if you could guarantee a successful platform before you went to the effort? Of course, it’s possible that you’ve already gone to that effort, and are now sitting there, wondering why no one is using the platform your team worked so long and so hard to build. But let’s hope that you’re actually at the starting line asking some hard questions, and not at the finish line, wondering why you didn’t.
The starting line...
All parts of your developer self-service platform have a role to play in promoting the usability of the platform itself, but not all of them play the same role at the same point. Let’s look at them one at a time.
Automation - Once your users see how much easier automation can make their jobs, they’ll be queuing up to use the tool, but it requires a certain level of trust to make the first move. Automation will be a decisive pull factor, but it will come later. There are other, more important factors for getting the ball rolling in the right direction.
Self-service - a truly self-service platform will help hugely when it comes to people choosing to use it. Being able to self-serve and not rely on others for help and permission gives people a big dose of confidence and levels up productivity, which in turn does wonders for DevEx. That’s not to say your platform should be a free for all. There are limitations and restrictions. The difference is that they’re pre-determined with skill and built-in so they’re practically unnoticeable.
The platform - the actual platform your users will be interacting with is the real make-or-break aspect of the plan. It’s also the part that can cost the most (in time, money and effort), and the part that underlies our other assumptions - the internal platform will revolutionize the ability to self-serve and the potential for really nifty automation, but only if you get it right and people will use it. So focus all your attention here - it’s a tall order, and it’s easy to get wrong.
If you do one thing...
If we had to boil this article down to one piece of advice for the creation of your internal developer platform, it would be to: focus on the DevEx. With the growth of platform engineering, hybrid cloud, and automation, it’s easy to get caught up with some pretty ambitious objectives, but the only one that matters when it comes to an IDP is quite simple - the dev is your end customer. Max out the DevEx and the users (and evolution) will follow.
Max out the DevEx - focus on making your IDP the best environment for your end customers (the development team) to do great work and have a great time doing it. To do this, especially if platform engineering is a new concept in your organization, you need to make sure that the people around and above you understand that the devs are your end customers, not the product. If you’re struggling to see how you can do this and also remain accountable to your executive team, take a look at this article. It will show you how to create KPIs that truly reflect what you should be held responsible for.
Build for purpose - this one is a no-brainer, but when there are a lot of spoons in the pot, it can get lost in a mire of opinions, inheritances, and ill-advised professional interests. How so? The idea of an IDP probably isn’t new. There may be traces of previous plans, tools that were trialled, and ideas that were considered and discarded, some or all of which may resurface during the planning of the new platform. Don’t let strong opinions or easy options knock you off course - your IDP needs to be perfectly aligned with the needs of your current team, for the challenges of today (and tomorrow).
Employ professionals of usability - if you were building a product for an external audience, you wouldn’t even consider unleashing a tool that had no usability auditing built in - so why would you unleash such a beast on your team? Make sure UX plays a central role in the development process or ensure that your 3rd party tool has a rock-solid UX foundation. No, Cycloid’s UX team didn’t pay me to add that, but I’ll be sure to draw their attention to my complimentary words!
Lessen the donkey work and remove complexity - we’ve already mentioned automation and how it comes later in the process to win fans and admiration, but that won’t happen spontaneously. Make sure the intention to lessen repetitive, boring, but necessary work is a central part of your platform. Taking full advantage of IAC will ensure you’re in a great position to use ready-built tools to take on some of this burden, like Cycloid’s Quota Management, which does what it says on the tin, or Stacks and Stackforms, which simplify the process of creating new environments, and Cloud Carbon Footprint, which allows true sustainability of both energy and spending without your devs having to always keep one eye on the bottom line.
Make it truly self-service - this is another point we’ve covered, but it should be of primary concern, especially as it can be difficult to ensure when you’re DIYing your tool - you need to make it truly self-service. If you don’t, you’ll miss a huge proportion of the objective - and the ability to hook your audience. The problem here is that although most people acknowledge that self-service is a great thing, it’s actually pretty hard to provide through entirely internal development - or at least, requires a lot more work. By outsourcing some of the development process to a 3rd party tool, you can focus on the specifics of your business, while entrusting the bells and whistles to people whose only job is to make your people’s lives easier.
The long-term goal
Sustainability is a drum we beat long and hard around these parts. The world is changing, and on multiple fronts, it's no longer feasible to allow a culture of excess to thrive in your organization. But by "excess", we're not talking about generous employee benefits or even a no-limits funding buffet. We're talking about a company-wide tendency to spend too much (time, effort, money) on things that just aren't returning the investment or, worse, actually damaging to the future of the business, human capital, or environment.
Too much...
One of the primary things that the development of an IDP absorbs is time. It's a recurring topic, and one that we tend to find clients aren't really aware of. That's why we have developed an IDP timeline, to show people exactly how long it takes to bring a self-service portal to life.
Take a look...
- Information-gathering: 3 - 6 months
- UX/UI research and validation: 3 - 6 months
- Specification definition for frontend and backend teams - 1 month (and several pizza teams)
- Missing the talent needed for one or more of these tasks? Well, you'll have to hire new faces: yikes, it could take forever. But let's call it 6 months.
- Development of the platform: 1 year.
- Ongoing maintenance and optimization: forever.
That's why, on average, it takes a whopping 3 years for platform engineering to be able to show a positive impact on the business.
Why should you care? Your IDP will be no exception. It will take a long time to build - even more if you decide to DIY it. Add that to the other sponges - money invested, the tendency to over-engineer, the people-power required - and people actually using the portal you built becomes an absolute imperative.
If you manage to make your IDP in a rational, optimized manner - congratulations! Now you must see if your devs are interested in using it. If they are, your IDP's impact will be felt far and wide. If they're not, it will be - by definition - an abject failure. No one will use it and it will make zero impact. So building an IDP isn't one big ask, it's two. And it's an intimidating prospect. We hope you're ready for the challenge. We are - and if you'd like a little help, all you have to do is ask.
This article is part of a larger series on sustainable platform engineering. Check below to see what you've missed - we'll add them as they go online.- What is sustainable platform engineering?
- The future: modern infra as the foundation to platform engineering
- How to build developer self-service your team will use
- Governance and security: finding the sustainability sweet spot
{{cta('2fa281d7-afe7-428b-94b2-6e02f8188729','justifycenter')}}
...
Modernizing your infrastructure could take many forms. Artificial intelligence, GreenOps, FinOps, and sustainability are all aspects that are just on the cusp of changing tech forever (for the better? It's still hard to tell - we're looking at you, ChatGPT!). The possibilities are endless and exciting.
But if you're planning on heading straight for the bright lights, you’re getting ahead of yourself. You can’t take the opportunities out there if you have a codebase that’s unmanageable. So that's why here, on Cycloid's watch, modernize means “make manageable”. Once you can manage your code, then you can transform it.Here's how you start.
Truth is, modernizing the way you deal with your infra, at least at the beginning of the process, isn't exactly hi-tech. Think about building bases and establishing sustainable foundations for the business of tomorrow, not building sky-high and adding bells and whistles today. Modernizing is about infrastructure-as-code (IAC) and using that IAC to automate as much as possible, streamlining processes and eliminating human error. This is something that works especially well in a GitOps context, which we'll also talk about today.
The foundation: Infra-as-code
We're unlikely to have to convince you of the benefits of infrastructure as code, but if we're still having this conversation, we might have to convince you of the benefits of actually biting the bullet. Sure, there are blockers - it's unlikely to provide full coverage of your infra, and legacy infra could cause a problem, but by making sure you've got the greatest coverage possible leaves much more time and space for higher-level tasks.
Adopting IAC can be automated with tools like InfraImport, leaving the smallest possible trace of legacy infra to be managed by hand. Less time doing repetitive, low-value work makes happier the techs, more streamlined processes, and code that's significantly easier to manage.
The system: GitOps
Once IAC is underway, you’ll be in a much better position to make the move to GitOps. It’s the natural extension of the idea underpinning all of our modernization - use the available tech to remove manual involvement and human error.
By making your Git the single source of all truth and home to your code, config, and infrastructure (in the form of IAC), you can set up the pipelines you need to deploy and manage your infra and applications. It further automatizes the day-to-day of your environments, as well as ensures that there's always a single source of truth (the infra in your Git) to refer back to, and helps with security and other requirements for your code by checking and applying requirements as part of the continuous deployment process.
By using Git, you can take advantage of versioning and rollback capabilities, visibility and observability, and the ability to apply security requirements in a timely manner. It also creates a standard workflow for doing things, which leads to consistency across environments. Finally, it also allows your techs to work in the code repos they've always worked in, something we're sure they'll appreciate. GitOps truly does have something for everyone on the tech team.
The future: the platform engineering team
Once these two linked tasks are completed (a move to IAC and then implementing the use of Git to manage it), you’ve got a much more manageable technology “package” to entrust to the platform team. You know those pantry organization TikToks? The sigh of relief you get when you see the pleasingly predictable finished product is a lot like what will happen with your platform engineering team when it becomes obvious they're dealing with a "modern" infrastructure - it makes their job vastly easier.
With the traceable, versionable, and automatizable benefits of IAC and GitOps, you'll have a manageable foundation that's much easier to build or insert into a solid developer platform. When you choose to use a tool like Cycloid, modules like StackForms, Cost Estimation, and Infraview will also leverage your infra-as-code to give you more insights and information on your performance and status that will allow you to take better, more sustainable decisions.
Ultimately, know that modernizing the way you manage your infrastructure sounds great, but "modernizing" is a bit of a misnomer. Using IAC and making the move to Git aren’t themselves the future - they’re the foundation of it. Get them in order and let really game-changing technology make the impact it can on your business.
This article is part of a larger series on sustainable platform engineering. Check below to see what you've missed - we'll add them as they go online.
- What is sustainable platform engineering?
- The future: modern infra as the foundation to platform engineering
- How to build developer self-service your team will use
- Governance and security: finding the sustainability sweet spot
If you’re hanging around the Cycloid website, chances are you’re familiar with platform engineering and may well have already received the slightly worrying verdict on the topic delivered by the State of DevOps Report 2023 - Platform Engineering: on average, platform engineering takes 3 years to start showing its benefits to the wider organization!
If you have a platform team or have been thinking about initiating one, it’s galling reading. Although not unexpected, it is quite sobering - in today’s economic environment, can any business afford to implement a new strategy for three whole years without a single bit of payback? It doesn’t sound likely.
Building a platform and customizing it to your team’s preferences is a tempting trap to fall into - after all, you probably have your best men (and women) on the job. However, what most teams don’t consider is the long-term viability and upkeep of the platform, and simply the amount of effort it takes to keep it running smoothly. In other words, the platform’s sustainability is in question, which is why we’re here today to talk to you about the need for sustainable platform engineering - and no, we don’t mean that you should bring a reusable cup to the coffee shop on your way to work (although you should).
It’s significantly wider-reaching than that.
What is sustainability in the context of platform engineering?
Let us reclaim the term sustainability and bring it back to its roots. This concept goes beyond simply being “green”. In general, sustainability means meeting the needs of the present without compromising the ability of future generations to meet their needs. The definition comprises three pillars: economic, environmental, and social —also known informally as profits, planet, and people.
In the context of platform engineering, this means building the foundation and tools that are going to last and deliver a stable return on investment year after year. The idea is to modernize and streamline the infrastructure, as well as change the way your team interacts with it so that your business can weather any change.
In Cycloid’s book, this involves various aspects such as efficient use of resources, carbon footprint awareness, reproducibility, reusability through automation and self-service, scalability, standardization and governance, and optimization through monitoring and analytics.
Okay, but practically, how do I achieve sustainability?
We view sustainable platform engineering as an iterative cycle. When it comes to DIYing your platform tool, it isn’t the making of the beast that’s the killer - it’s the maintenance, upkeep, and usability of the platform as your business moves forward. This takes time, effort, and money, but in today's business environment, you can't just throw these variables at the problem and hope that you'll see radical results in 3 years.
Instead, you need to act strategically, choosing paths that will sustain your business in the long run. The three main areas to focus on are:
GitOps/Infra as code - start by optimizing your infra, modernizing it, and enjoying the benefits of infra as code. This protects your profits, allowing your business to keep moving forward and making an impact in a fast-moving technological world. Together, IAC and GitOps are what allow you to pick up speed and simplicity while maintaining a flawless end product.
Self-service - this is what’s going to help your people feel good about the work they do. A self-service tool with great UX removes the pressure on techs to be the infra experts they're not. At the same time, it erases the need for the endless tickets they used to raise, allowing your DevOps engineers and often, platform experts, time and space to do the “big thinking” that's going to help your business make and keep a leading edge.
Iteration and optimization - your self-service portal will bring flexibility to end-users while decreasing the number of tickets for the platform team. Do it right - or with the right partner - and it will also keep governance in check and control your cloud spending and carbon footprint impact, offsetting the environmental impact of your business while continuing to optimize people and profits. After all, the global tech market isn’t going to sit still, so your platform engineering tool can’t afford to either.
How does sustainable platform engineering affect the bottom line?
Sustainable platform engineering is meant to support the 3 main pillars of sustainability – profits, planet, and people, covering the major factors for a successful business.
Profit
Legacy infra, dysfunctional tech teams, and painfully slow production all contribute to a business that isn’t performing as it needs to. By modernizing legacy infrastructure, breaking down silos between teams, and accelerating production, platform engineering helps build a sustainable foundation that will continue to help bring in profits no matter the outside forces. Additionally, having an eye on your business expenses, such as the cost of the cloud, will keep your business a lean and mean machine.
Stable and secure ROI is the keyword of the day, and a business that is flexible enough to weather the changes and robust enough to keep going is the outcome of sustainable platform engineering.
Planet
A business that operates without an eye on the cost of its cloud resources is losing money and karma, plowing through energy and cloud costs at an eye-watering and unsustainable level. We’ve said it time and time again - billions of dollars paid for the cloud get wasted every year, putting a major dent not only in a company’s finances, but the real-life resources (water and electricity) sustaining the cloud.
This is where we put the “green” in sustainable platform engineering. By getting a hold of your cloud usage and controlling your cloud carbon footprint, your platform should be able to lessen the organization’s impact on the environment, saving both the green pastures and the green dollars (or colorful euros). But this is only achieved through a centralized and holistic overview of everything that gets deployed on the cloud, and everything that’s wasted.
People
A business that is pushing its capabilities to the limits in the search for success risks burning out its people and nowhere is this more obvious than on the tech team. Techs get stressed by having to interact with infra they know nothing about, DevOps and specialists get stressed by those techs desperately raising tickets in an attempt to get help, and platform engineers get stressed from the weight of providing a solution to these problems resting squarely on their shoulders. Stressed, desperate employees make bad decisions. By removing these pressures with a self-service portal (ideally complemented with tools around observability and governance), you’re releasing the cognitive workload on your team, allowing them to focus on what they do best. Better DevEx, happier people, better business.
As makers of a platform engineering tool, we’ve got skin in this game - but we believe we have a valid point: building a "homemade" platform engineering tool will likely backfire and compromise sustainability - not just of your project, but of the 3 fundamental pillars of sustainability.
If we’ve convinced you that platform engineering needs to be sustainable, great - because Cycloid is confident of it. Over the next few weeks, we’re going to look at the topic in more depth - today, we’ve shown you why and in future articles, we explore how to make it sustainable and why everyone on your tech team is going to benefit.
We'll add them below as they go online.
- What is sustainable platform engineering?
- Stepping into the future: modernising infra as the foundation of platform engineering
- How to build developer self-service your team will use
- Governance and security: finding the sustainability sweet spot
{{cta('da7d1a6d-80dd-41a7-8811-0ffaef8d457e','justifycenter')}}
Imagine this: you’re looking to scale your infrastructure to match your rapid business growth. Infrastructure-as-code is an excellent way of modernizing infrastructure. You know that the longer you wait to make the move to IaC, the deeper your business will sink into the quicksand of human error and, eventually, slower deployment. However, industrializing your manually-deployed infra is a daunting and resource-extensive task.
This is precisely the story our business development lead Rob Gillam hears in conversations with potential clients. We asked Rob to expand on what kind of pain points companies are dealing with and if there’s a solution.
Rob Gillam: There’s a term that’s getting more popular to describe slow cloud infrastructure deployment - ClickOps. It refers to the way you deploy cloud infrastructure through the cloud providers management interface. Historically, they are not very user-friendly and quite clunky, requiring you to search for and select multiple resources before you deploy them. Hence the term - ClickOps, since you spend all your time clicking interfaces, instead of doing your job. It's not a desirable way to deploy your cloud.
IaC, or Infrastructure as Code, is a way of managing and provisioning infrastructure through code rather than manual processes that can result in faster, more reliable, and more scalable infrastructure deployments.
RG: Organizations are starting to see the value of infrastructure-as-code and are looking for ways to migrate their existing infrastructure to IaC - fast. Lucky for them, Cycloid has just the solution.
RG: The first reaction we get when we demo Infra Import is disbelief. People are amazed at how fast and well it’s working.
Take a look and judge for yourself:
But how does it actually work?
RG: Let’s take a typical use case. One of our customers is an early adopter of cloud infrastructure, with 5,000 manually deployed instances in Azure. Their team is primarily skilled in networking and isn't DevOps-oriented. They understand the value of IaC and have even tried migrating their environments but, because they have to deploy infrastructure manually every time they have a new customer, recreating it in IaC is a complex, lengthy, and error-prone process.
With Infra Import we created infra-as-code describing all the manually-deployed services including complex networking in just a few steps (and even fewer clicks).
Step 1.
Select your cloud provider and fill out the appropriate credentials to enable connection to the API. This will allow you to import your deployed infrastructure. Cycloid supports all major public cloud providers (AWS, GCP, and Azure) and most private cloud providers.
Step 2.
Select which resources you want to import from your deployed infra.
Step 3.
Name your blueprint and specify what catalogue repository Infra Import should use to store the created Stack. The power of Infra Import is in repeat automation supported by the Cycloid platform. Once you’ve imported your infrastructure, Infra Import will automatically create a service catalogue saving your configuration, which you can then deploy for new resources using a custom web form we call StackForms. Not only does this make things faster, but you’re also helping customers who are new to IaC to take advantage of this technology because it requires no additional skills.
Step 4.
Enter the name of the project you want to launch, the config repository where the project configuration will be stored, and the location of your Terraform state file.
Et voilà - 5,000 manually deployed instances are automatically recreated in IaC in a few hours!
RG: With Infra Import, the client estimates that they have saved 200 man-days migrating existing infrastructure to Terraform. All their infrastructure can now be centrally managed in Cycloid’s service catalogue and deployed by anyone with any skill level (no need to be a DevOps expert!) in our developer self-service.
In addition to automation, they never have to worry about security either. Cycloid’s governance and observability tools will allow ops to control access to the infra using our RBAC module and monitor any changes inside the platform.
RG: As more companies are considering platform engineering, they start realizing that infra-as-code is an integral piece of the puzzle and often the first step to platform success. After all, creating sophisticated automation requires your building blocks - infra - to be automated in the first place. Migrating existing infrastructure to IaC is a business imperative and I’m glad Cycloid’s Infra Import answers this very specific - but common - need because not many other solutions do.
Curious? Good, because modernization can’t wait. Check out Infra Import or schedule a meeting with Rob now.
...
Wider teams are resisting adopting an internal developer platform, and platform engineers are pulling their hair trying to understand why, according to the State of DevOps 2023 Report. Is it too complex? Does it not do the job? Is the UI not sleek enough? Possibly all of the above, but the real culprit is under-education and under-communication about the possibilities of an internal developer platform to your wider team.
Developer self-service is an integral part of platform engineering, and one that has the most number of users across an organization. If you can get your team to adopt developer self-service, your platform engineering strategy is in the bag. But for this to happen, it should satisfy the needs of all – both end-users (devs, solution architects, IT teams) and Ops.
So, building developer self-service, which is more than simply designing a fancy UI (though it is very important and overlooked by many!) – it’s about building a functional tool with a user in mind. It’s not just making it user-friendly - make it user-oriented!
Treating the platform as a product that answers your customers’ (wider teams’) needs is what will help you build a platform that’s going to be easy to adopt.
How can you make developer self-service more user-friendly?
Address the user’s needs
Just like any relationship, it’s all about communication. In an ideal world, end-users communicate their needs, and the platform team responds to them as best they can. The platform team’s role is to put their end-users in the best position to handle tools, processes, and infrastructure, but how exactly that’s done depends on individual members.
Treat your colleagues as if they were your customers, and the platform as a product, then the roadmap becomes so much simpler and clearer.
If your team can’t articulate their wants and needs clearly, take the next best thing - an out-of-the-box industry standard solution. We’ve written loads on the benefits of buying vs building, but the gist is this – why spend hours of your precious time perfecting what’s already been perfected by experts? There’s nothing your team is going to gain from reinventing the wheel, so you’ll be safer with market-tested solutions..png)
Cycloid’s own self-service portal StackForms prioritizes end-user experience to make configuring new environments as seamless and autonomous as possible. We aim for flexibility, simplicity, and control when it comes to self-service, concealing complex tech behind a user-friendly interface (so hopefully we know what we’re talking about!)
Autonomy and security
The primary goal of a developer self-service portal is to allow end-users to service their infra and cloud needs independently, without the need for expert (usually DevOps) supervision. This is the deciding factor in increasing development and time-to-market speed, as platform engineering promises. 
This means that any security guardrails your DevOps needs are going to have to be in the background, to not obstruct or slow down your end-users' process. With permissions and roles set in advance, your end-users can deploy fast, while Ops enjoy peace of mind that nothing will get broken without their knowledge.
Independence goes beyond leaving devs to their own devices. Sharing some of the business responsibility improves their involvement and facilitates the process known as “shift left.” For example, giving end-users estimated cost data on their new deployments will help foster a culture of responsibility.
Improve UX
We know we just said that a developer self-service is not just about snazzy UI and it’s not - it’s about functional and user-friendly smooth user experience. Far too often platform engineers overlook this simple step, but the shocking truth is that bad UX can severely impact efficiency and their experience on a project.
There’s nothing wrong with DIY-ing an engineering platform – open-source tools like Backstage offer great flexibility and moldability. However, at the same time, they require more technical expertise. Developers either need to upskill (and there’s a shockingly low upskilling rate in companies - we wrote a whole ebook about that), or write up more tickets to Ops, which would defeat the entire purpose of a self-service portal.
Not only do end-users, and especially developers appreciate simple and functional interfaces, a good user-oriented developer self-service design will help them be more efficient and independent.
Platform engineering adoption is a big step in the right direction to achieve better DevX and faster time-to-market speed. The biggest challenge is convincing your wider team that it’s worth it. Platform teams should make evangelization and communication around the capabilities of the internal developer platform their number one priority. Anything you can do to help nudge them in the right direction – including creating a user-oriented and user-friendly developer self-service platform, will certainly help your cause.
Can Platform Engineering address data center energy shortages?
In this eBook, we dive into how platform engineering can play a pivotal role in tackling the energy crisis faced by data centers.
The Art of Platform Engineering
This ebook will clear up any confusion you may have between Platform Engineering, Internal and self-service portals.
The Definitive Guide to GreenOps
This ebook will be your roadmap to success in a world where environmental responsibility takes center stage.
Guardians of the Cloud: Volume 2
Part 2 of our comic book sees the start of an environmental rebellion and attempts to use cloud resources more efficiently.
In It For The Long Haul: Platform Engineering in the Age of Sustainability
Enable smarter, more environmentally conscious cloud consumption decisions at every level of a business, and more efficient processes for your teams.
Guardians of the Cloud: Volume 1
Welcome to Guardians of the Cloud, a brand-new comic book series that takes you on an unforgettable journey to Cloud City – a place of endless innovation that harbors a deep secret.
Life in the fast lane: DevOps and hybrid cloud mastery
In this ebook, we show you how to roll out DevOps and hybrid cloud at the same time, while taking as few risks as possible.
IAC Migration for forward-thinking businesses
Read how to alleviate some of your infra-related anxieties with a simple tool. Here are the answers to some of your most burning questions.
Infosheet: hybrid cloud - bring it to the devs
Are you a team leader, tasked with bringing hybrid cloud to your team? We’ve put together 5 practical, actionable tips to make the rollout easier and the DevX smoother
Life in the fast lane: DevOps and hybrid cloud mastery
In this ebook, we show you how to roll out DevOps and hybrid cloud at the same time, while taking as few risks as possible.
Insight: Businesses need to start thinking about that DevX Factor
We believe that you should empower your existing teams to reach their full DevOps potential. How to deliver that DevX factor – insight by Rob Gillam.
Insight: How do you solve a problem like Cloud Waste?
Without supervision, running cloud expenses will add up and cost you success. Read about Cycloid’s solution to cloud cost estimation and monitoring – insight by founder Benjamin Brial.
Infosheet: Infra as Code by Cycloid
We believe Infra as Code is the only approach to software development that lets you scale safely and successfully, so let us soothe your concerns and lead you confidently into the wonderful world of IaC with this infosheet.
Infosheet: Governance with Cycloid
We know, we know. Governance isn’t cool, but it is essential! Cycloid builds it in from the ground up, so your experts have all the control they need, without cramping the style of the rest of your team. This infosheet explains our approach and what tools you’ll have at your disposal.
Cheatsheet: DevOps business value - make the case to the c-suite
It’s not the message that needs to change, it’s the way you deliver it! We’ve created an infosheet with a new perspective on sharing DevOps and tech metrics with a non-tech audience.
Ebook: DevOps business value: prove it or lose it
We’ve written this ebook to help tech team leaders create better, more productive relationships with the executive team, even if you’ve really had problems communicating in the past.
Whitepaper: Get Your Team Ready for Increased Automation
This whitepaper consolidates the 3 ebooks that make up the hugely popular Plan Now, Win Later ebook series and will show you how to lead your tech team into a DevOps-first future!
Ebook: Build a culture of operational safety
DevOps will help you scale, but scaling is dangerous if you have no safeguards in place. This ebook shows you how to keep your SDLC safe, no matter what.
Ebook: Make tools and schedules work with your team
The grind – or smoothness – of their daily work is what’s going to make or break your team. Set them up for success from day one – we show you how in this ebook.
We talk to Wilco Burggraaf, Green IT lead at HighTech Innovators, to shine the spotlight on the world of Green Coding – a transformative approach that prioritizes energy efficiency.
We sat down with Sean Varley, Chief Evangelist and VP of Business Development at Ampere to discuss the intersection of AI, cryptocurrency, and sustainable technology.
Donal Daly, the visionary founder of Future Planet, joins us this time and takes us on a compelling exploration into the realm of ESG (Environmental, Social, and Governance) strategies.
We talk to Guillaume Thibaux, Founder & CTO of Quanta.io, shining the spotlight on his visionary company that has pioneered a free solution to measure the environmental impact of a website.
Coming soon!
Up Next!
Keep an eye on this page to view upcoming episodes.
Next Episode Launch date: February 2025
Product demos
Cycloid Platform Engineering Demo Video
Improve developer experience, empower end-users and operational efficiency to increase time-to-market speed with Cycloid.
Improve DevX with Cycloid Platform Engineering
Cycloid Platform Engineering uses a simple user-friendly self-service portal and service catalog to empower your end-users.
Feature demos
Calculate the cost of resources before you deploy - Cloud Cost Estimation Tool
Cloud Cost Estimation is integrated within our developer self-service portal Stackforms to help you make the best cost-optimized decisions before you deploy.
Simple service catalog - Stacks
Preconfigure user-friendly Stacks and allow your devs to choose approved and suitable infra configurations from a custom service catalog that’s made to measure.
Reverse Terraform tool: Infra Import 2024
Infra Import industrialises your manually deployed infrastructure at scale by automatically creating Terraform files and generating IaC. Modernize your infra and future-proof your business with Cycloid.
