Imagine you’re a DevOps engineer managing microservices on AWS. How would you configure auto-scaling to handle high traffic without wasting any resources?
Tags: Platform engineering
When should you adopt Platform Engineering?
If you’ve not been living under a rock for the last year and a half, chances are you’ve heard of Platform Engineering. The latest industry trend promises to do everything DevOps tried to do and failed, yet again: lighten your devs’ workload, improve DevX, skyrocket operational efficiency, and turn your projects into rivers of gold.
In truth, Platform Engineering continues the process DevOps started. With PE, leaders have an actionable plan to build toolchains and workflows that empower developers of any skill level with self-service capabilities. It’s an all-round solution that not only improves devs’ autonomy and collaboration, but also enhances resource management, and provides ecosystem and plug-in integration.
You see why it’s an extremely attractive proposition for IT departments – and a very daunting undertaking. After all, it takes nearly 3 years and 20 dedicated specialists to start seeing tangible results. And yet, Gartner predicts that by 2026, 80% of IT departments will adopt internal platform engineering teams.
Obviously, you don’t want to be left behind, but does this mean you should join the race now? When should you adopt Platform Engineering?
Let’s look at the factors that mean your organization needs to consider platform engineering seriously.
Governance and security: finding the sustainability sweet spot
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?
How to build developer self-service your team will use
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.
The future: modern infra as the foundation to platform engineering
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.
What is sustainable platform engineering?
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!
Migrating infra to IaC is a business imperative: Infra Import Use Case
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.
Developer self-service: your key to adopting Platform Engineering!
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
7 Platform Engineering KPIs you should be tracking
Platform engineering is becoming an increasingly popular approach to software delivery because it offers benefits such as improved time-to-market speed, increased developer happiness, and breaking down of team silos. We wrote extensively about platform engineering, specifically that it’s not, in fact, new and DevOps is not dead. However, given how many enterprises have struggled with delivering DevOps business value, they might view building internal digital platforms to aid software delivery as an actionable plan to achieve everything DevOps ever promised.
But how do you avoid falling into the same trap that held 80% of companies back from adopting DevOps?
Our advice: treat your platform like an internal product, and your wider teams as your customers. This means that your success metrics should be the same as you would use for your customers – with a platform engineering twist.
Key goals of Platform Engineering
When setting up your success metrics, it’s important to not lose sight of what your Platform Engineering strategy should aim for. According to the 2023 State of DevOps report, these were the top goals companies set for their platform teams.
Educating and empowering developer and product teams is a major priority for platform teams, followed by iteration speed and security processes. This people-centric approach is the same one you should adopt in your metrics. Reinventing tools is only half the job – you need to make sure your people are comfortable using the new frameworks. Streamlining and automating processes according to DevX best practices helps the entire organization move more quickly and drive a competitive edge.
Platform Engineering KPIs
According to the 2023 State of DevOps report, after adopting Platform Engineering, the majority of enterprises saw improvements in system reliability (60%), productivity and efficiency (59%), and workflow standards (57%), while 42% reported improved development time.
Productivity
Measuring lines of code produced by developers in X amount of time is an outdated metric used these days perhaps only by the likes of Elon Musk. Developer productivity is a sensitive subject, and while platform engineering promises to speed up software development, it doesn’t happen by making developers deliver more.
Instead, it’s about creating the best conditions for your devs to thrive in. Think about the bottlenecks and obstacles that your teams have to deal with daily and how much they have to rely on experts to get their work done. Complex infrastructure deployments, creating new environments, shipping features – all these require DevOps help, which inevitably clogs up processes. KPIs centered around streamlining and simplifying the software delivery process should be your focus.
- Lead Time
This is a measurement that tracks the time from when a user story is initiated to when it’s ready for delivery. This time can also include discussions about the user story, how long it was waiting in the backlog, and how much time it took the story to move from pickup to release.
If your lead time for changes is too high, it’s a clear sign of a roadblock somewhere in your processes, causing items in the backlog not to move along. Automating whatever could be automated will help keep your lead time low, as it shows your teams are quick to adapt to feedback and deliver on their goals.
Enabling developer self-service in Kubernetes
Platform engineering is taking the IT world by storm. We’re seeing articles claiming that platform engineering is finally going to end the DevOps reign and achieve everything DevOps never could – agility, automation, developer experience, efficiency and governance. The path to IT transformation and business growth that the new trend paints through self-service seems so painfully obvious, but let us tell you a little secret – it is not new. The trend might be a fresh marketing buzzword, but forward-thinking companies have already been utilizing the benefits of a platform engineering approach. Today’s platform teams are tasked with exactly this: building and maintaining an internal developer platform that connects the end-user to infrastructure management through simple developer self-service and improves efficiency and developer experience.
This idea has been working in practice for a while — and we should know, since improving operational efficiency through a developer platform with self-service is Cycloid’s core offer. We’ve recently used platform engineering to help our client Alchemy scale their automation and move infrastructure to Kubernetes on AWS.
Here’s what we did step by step:
Step 1: Take an Opinionated Approach to the Development Environment
Alchemy is a digital asset management company that helps organizations to implement the open solution for managing digital content using Phraseanet, and starting now with the brand new Phrasea, a promising DAM/MAM on AWS. They have a small team of developers that were able to service their clients needs – but as the company grew, they needed a way to scale up effortlessly.