t
t
t
In our last piece (link here), we cut through the cloud-native jungle, honing in on Platform Engineering’s role in taming cloud-native complexity and alleviating developer experience (DevEx) degradation. Let's do a quick flyover of what we’ve established so far before jumping into finding a starting point for adopting Platform Engineering:
The Why: Platform engineering is your GPS through the labyrinth of cloud-native. Its mission? Elevate DevEx by handling the grunt work - wrestling with microservices, orchestrating containers, and navigating serverless.
The How: We leverage tools like Kubernetes and containerization, with IaC as the magic wand, orchestrating the tech stack and letting your devs dive back into the deep end of coding.
The Result: Your reward is an Internal Developer Platform (IDP). Think of it as a cognitive load balancer for your devs - it manages resource provisioning, app lifecycle, and CI/CD automation, lifting the infra fog and supercharging DevEx.
.png)
Now, let's zoom into the starting line of your platform journey - deciding to buy off-the-shelf PaaS or craft your own IDP. The 'Build vs Buy' decision hinges on your org's unique resources, requirements, and roadmap. We'll deep dive into that later.
But first, let's unpack the secret sauce of successful adoption - the "Platform as a Product" mindset.
A successful IDP operates like an internal product. The focus is on your devs - they are the end-users. Regardless of whether you're hand-crafting your platform or leveraging a PaaS solution, this mindset is a game-changerStep 1: Crystalize Platform Goals
The IDP journey starts by defining clear, actionable objectives. Identifying key stakeholders, understanding developer needs, defining success metrics, and establishing platform goals - these elements align your efforts and guide your platform mission.
Stakeholders & Dev Needs: Identify all users of the IDP, not just devs, but also DevOps, SRE, QA teams, and management. Next, dive deep into developer pain points. Are there bottlenecks in the current development, testing, and deployment processes? What tools could dial up their DevEx?
Success Metrics & Goals: Formulate measurable outcomes - like reducing deployment times, decreasing the number of deployment failures, or increasing developer satisfaction. Define SMART goals for the IDP that improve user experience, performance, and compatibility with existing systems.
Buy-In: Finally, rally your team behind these goals. Clear, engaging communication ensures everyone's aboard the IDP train.
Weighing up 'build vs buy' is all about your unique needs, resources, and timeline.
Capabilities & Costs: Check the pulse of your team's skills and bandwidth. Can you manage the long-term financial commitment of building and maintaining an IDP?
Time-to-Market & Vendors: If the clock's ticking, a PaaS solution might be the fastest ticket to a functional IDP. If you're leaning towards buying, rigorously assess potential vendors' offerings.
If you're coding your own platform, you'll need to plan, design, build, and document.
Roadmap & Architecture: Outline your IDP's key features, tech stack, integration points, and desired UX. The architecture should be scalable, resilient, maintainable, and flexible enough to adapt to changing requirements.
Prototype & Development: Create a prototype to validate your design. Next, build the full platform, leveraging DevOps best practices like IaC and CI/CD to ensure reliability and maintainability.
Docs & Training: Finally, draft clear documentation and conduct training sessions to ensure a smooth transition for your users.
If buying, you'll need to evaluate, select, integrate, and customize your IDP.
Vendor & Platform: Rate potential vendors against your goals and requirements. Once you've zeroed in on the best fit, gear up for the integration phase.
Customization & Training: Most off-the-shelf platforms allow for customization. Tailor it to your unique workflows and processes, then onboard your team with training and comprehensive documentation.
Whether you've built or bought your IDP, it needs ongoing TLC to ensure long-term value.
Monitoring & Optimizing: Keep an eagle eye on platform performance, identify bottlenecks, and tweak for optimal developer experience.
Feature Development & Security Updates: Listen to user feedback, evolve with your org's needs, and keep security and compliance at the forefront of all updates.
Infrastructure Management or Vendor Relations: If you've built, manage your infra smartly. If you've bought, nurture the vendor relationship and stay abreast of platform updates.
User Training & Feedback: Continually train and support users. Seek regular feedback to refine and enhance your platform.
Documentation & Resilience Measures: Keep docs fresh as your platform evolves, and rigorously test backup and disaster recovery plans.
Feedback Loop: Keep the feedback loop tight. Frequent check-ins with developers help tailor the platform to their needs and continuously refine it.
Kaizen Mindset: Treat the platform as a product in perpetual beta. Continually crunch performance, usage data, and feedback to inform updates and new features.
Docs Sync: Keeping your platform's docs current is not optional. As changes roll out, update documentation to ensure a seamless user experience.
DR Tests: Don't let your disaster recovery plans gather dust. Regularly test backup and recovery mechanisms to maintain platform resilience.
Navigating the IDP implementation boils down to a crucial fork in the road - build in-house or go for a pre-built solution. Each choice has specific implications for your resource allocation, customization scope, ownership duties, and total cost.
Building from scratch gives you total control and bespoke customization tightly tailored to your business demands and tech landscape. But keep in mind, it’s a high-effort, high-reward path. Expect to burn significant bandwidth on initial build-out, maintenance, and feature rollouts.
On the flip side, off-the-shelf IDP can be your fast pass to deployment, demanding less upfront work and cash. However, you may be limited by the platform’s existing architecture and feature set. You share ownership of updates and upkeep with the vendor, a double-edged sword, depending on your perspective.
Let’s compare the two approaches:
When it comes to Identity Platform (IDP) selection, the options can be classified broadly into two categories. With a Do-It-Yourself (DIY) IDP, organizations have the chance to craft a tailor-made platform that's laser-focused on their needs. On the other hand, choosing an off-the-shelf IDP involves procuring a ready-made, usually tweakable platform from a trusted vendor.
When it comes to the effort needed, both options differ significantly. Opting for a DIY IDP means you should expect heavy lifting upfront and ongoing upkeep. Contrastingly, an off-the-shelf IDP demands less grind at the get-go and during upkeep thanks to pre-baked functionalities, with vendor backup usually available on demand.
In the realm of customization, a DIY IDP grants you full command over the platform's every nook and cranny. But with an off-the-shelf solution, customization is contained by the vendor's blueprint and their openness to custom integrations.
Ownership dynamics also vary between the two. With a DIY solution, you're the captain, but the responsibility for all updates and support are solely on your plate. Meanwhile, choosing an off-the-shelf IDP is more of a co-piloting situation with the vendor, who usually handles regular updates and support.
Lastly, a DIY IDP carries a hefty initial investment and recurring maintenance costs. Conversely, an off-the-shelf IDP is easier on the wallet initially, and the ongoing costs are predictable, usually manifesting as subscriptions or licenses.
Consider these factors in light of your organization's capabilities, resources, and long-term objectives to chart the most effective course for your platform journey.
Deciding whether to build or buy an IDP hinges on your organization's context, resource pool, and big-picture vision. There's no one-size-fits-all verdict here; instead, you'll be choosing from two distinct value propositions, each carrying its own perks and drawbacks.
A DIY IDP hands you the reins of customization. You can tweak the platform to gel seamlessly with your workflows and tech stack, making it a go-to choice for orgs with quirky or proprietary needs and a laundry list of demands.
The flipside? You're also signing up for total ownership. This means taking care of the usual suspects: bug hunting, maintenance, scaling, and updates. Sure, your journey to value might take a bit longer, and you'll need to splurge upfront and in the long run. But, you stand to gain a platform tailored to your unique requirements.
Opting for an off-the-shelf IDP, on the other hand, means you're in the fast lane to value. Your platform arrives ready for deployment, and while you can jazz it up a bit, you're ultimately working within the bounds of its design.
This is a snug fit for organizations with run-of-the-mill workflows and a tech stack that plays nicely with mainstream solutions. You'll enjoy a softer blow to your budget initially, and future costs are easier to eyeball, given that most maintenance tasks are on the vendor's tab. You also get to offload scalability to the vendor, freeing up your resources.
To offer more clarity, here's a deeper dive comparing DIY and off-the-shelf IDPs:
DIY: Commandeer the customization landscape to match your specific quirks and tech stack.
Off-the-shelf: You've got a customization sandbox tailored for best practice workflows and popular tech.
DIY: You're in the cockpit, bearing the brunt of maintenance and scaling.
Off-the-shelf: It's a shared cockpit with the vendor; updates and new bells and whistles are usually part of the package.
DIY: Steeper initial and ongoing costs; a solid bet for the long haul if you've got complex use cases.
Off-the-shelf: Easier on the wallet initially, plus predictable subscriptions and fewer maintenance migraines.
DIY: Brace for a longer runway due to development time.
Off-the-shelf: A speedy solution since it's deployable right out of the box.
DIY: Scalability is your baby.
Off-the-shelf: The vendor shoulders scalability, relieving your load.
DIY: Your best bet for satisfying finicky, complex, or homegrown needs.
Off-the-shelf: A match for companies with out-of-the-box needs and well-supported tech stacks.
Standing at the 'build or buy' junction on your IDP journey, the right direction is dictated by your organization's individual blueprint, not a universal rule book. To untangle this decision, put these lenses on:
Organization Size: Small and medium players might balk at the Herculean task of home-brewing an IDP, given their lean bandwidth. On the flip side, larger squads with hefty resources can revel in the fine-tuning a custom IDP offers.
Industry and IT Needs: Orgs where software takes a backseat might find a turnkey IDP handy, efficiently dealing with complexities without requiring them to morph into IT mavens overnight. But, for those swimming in IT-rich or niche waters with idiosyncratic needs, a tailor-made IDP might be non-negotiable to cater to their unique demand landscapes.
Resources: Let's talk cold, hard cash and talent. If these are in short supply, a canned IDP could be your best bet, delivering a robust solution without stretching your resources to the brink.
Tech Stack: Your existing tech stack can swing your decision. If you're dealing with a motley crew of custom or legacy systems, a DIY IDP might be your only route to ensure seamless compatibility. On the other hand, if your tech stack is in the mainstream lane, an off-the-shelf IDP might sync quicker and easier.
With those decision lenses in place, let's examine the typical beneficiaries of DIY and pre-packaged IDPs.
Builders: Larger enterprises that can capitalize on a custom-made solution.
Buyers: Smaller players where in-house development resources are a constraint.
Builders: Specialized sectors or those with distinct IT demands.
Buyers: Sectors where IT doesn't take center stage or with standard tech stacks.
Builders: Entities with ample resources and robust tech development muscle.
Buyers: Those with limited headroom for significant non-core development tasks.
Builders: Entities with intricate workflows, unique deployment tactics, and offbeat integrations.
Buyers: Those with standard development workflows, regular deployment strategies, and typical integrations.
Builders: Entities with the luxury of time for extensive platform development, eyeing long-term payoffs.
Buyers: Those seeking a quick fix and where prolonged development is a non-starter.
Builders: Entities with a unique, rare, or niche tech stack, not well-addressed by ready-made IDP solutions.
Buyers: Those with a standard tech stack, comfortably catered to by existing IDP offerings.
This should give you a leg up on your IDP journey. However, don't forget to account for the unique nuances of your organization to land on a decision that fits like a glove.
With an understanding of the theory behind Platform Engineering and a first indication of how to approach implementing Platform Engineering and IDPs, let’s move on to the Anatomy of an IDP. In this next part, we will look under the hood of an IDP and introduce what components and modules make up the typical architecture blueprint.
Subscribe to our newsletter and stay on top of the latest developments
By signing up, I agree to the mogenius privacy policy.
