🌟 Leaders please answer this: Why would you still need a developer platform on top of Clouds or Kubernetes? 🌟

TL;DR Developers want to do what they do best, code and get products in the hands of users. They need to be able to self-serve to code, ship and run, secure, manage their apps. As much as possible should be automated. Hence you would need to build many of these automations yourself or you look to adopt a platform with integrations and automation built in.

Now, full disclosure; I’m not unbiased, nobody is, nevertheless I believe that some of the questions I raise in this blog are valid no matter which way you look at it.

Ow and to all readers; Azure, AWS and Google Cloud users; 88% of all cloud implementations also include Kubernetes as supporting technology for your modern applications. So highly likely that the below also applies to your organization.

‍

Containerized apps and their technology stack

As companies increasingly containerize their apps in their modernization efforts they turn to Kubernetes to manage these applications. Much research has been done and the outcome is always the same, Kubernetes is great yet very complex. Plus, one would need at least a dozen additional technologies to automate the application lifecycle and to monitor, manage and secure the workloads. The choice between building a developer platform for Kubernetes or clouds from scratch, or opting for a ready-to-run solution becomes a pivotal decision. In this post, I touch on the critical considerations and statistics behind this choice, shedding light on why businesses often are slowed down to innovate and modernize their application estate.

‍

The Benefits of Kubernetes are Undeniable

Kubernetes offers a plethora of advantages for deploying and managing containerized applications. It provides scalability, high availability, self-healing capabilities, easy application packaging, resource optimization, service discovery, and more. With a vibrant ecosystem and community support, Kubernetes simplifies container orchestration and is widely adopted for modern app deployments. Here also lies the challenge of integration.

So, while Kubernetes itself is a powerful foundation for container orchestration, it lacks critical components required for running business applications, such as CI/CD, observability, metrics, security, compliance, service mesh, cost management, storage, databases, backup, identity and access management and more. To achieve true developer self service and abstract all that complexity away, delivering a self-serve abstraction for developers will definitely be on the agenda for many organisations. This ensures fast, controlled, and secure deployment and management of business applications. This is why companies are investing heavily in the engineering of an integration layer with many components, whether those components come from the Hyperscale Clouds or the Open Source ecosystem, after deploying Kubernetes or consuming a Kubernetes service the actual work begins to bridge this gap to offer self service to developers and provide the ability to run and manage apps securely.

The interesting part is that most organizations are doing the same thing (building a platform on top of Kubernetes) but in an ever so slightly different way or context. This begs the question: Should every company invest in engineering their own platform which will be just slightly different from the next company? Does this add any business value? If most of those platforms achieve relatively the same, then surely this does not add competitive advantage. IMHO The real business value is in the ability to build unique experiences through software, the applications your users interact with. Users will never see or experience the fantastically engineered infrastructure below a running application.

If this is the case then why are many companies still choosing to go down the path of this heavy engineering, knowing this can take many months of engineering resources away from building the next differentiating feature in your software.

‍

The Temptation to Build Custom Platforms

Theoretically, a bespoke Developer Platform for Kubernetes sounds appealing. It can be tailored to your organization's specific needs, aligning with your processes and requirements. However, the decision to build a custom platform should not be taken lightly. Here are some statistics and drawbacks to consider:

‍

1. Initial Costs: Building a custom platform can be a substantial financial commitment, with researched costs ranging from €150,000 to €450,000 for a basic version. Research from Gartner indicates that building custom software can be up to 3.5 times more expensive than buying pre-built solutions.

2. Time to Market: Developing a custom platform is a time-consuming process, with lead times spanning from 12 to 24 months or in some cases longer depending on regulatory requirements. According to research from Forrester, 64% of IT decision-makers prioritize the speed of implementation when choosing between building and buying. If you were given a choice, how would you quantify the speed to deliver functionality?

3. Software Updates: Maintaining custom software can be up to 4 times costlier than building it initially, as per McKinsey's research.

4. Talent Shortage: Kubernetes expertise is scarce, and building a custom platform can lead to staff attrition and knowledge loss, as skilled employees often leave in 2 years for better opportunities. The average tenure for software engineers is 2 years.

5. UI and User Experience: Custom platforms may lack the user-friendliness, consistency, and aesthetics for developers to interact with them in an intuitive way.

6. Support: Custom solutions require additional investments for support and maintenance, or worse, there might be no support contract at all.

7. Reinventing the Wheel: Building a custom platform will not differentiate your business from competitors, and ready-to-run platforms offer the advantages of research, development, tested architecture, and compliance validated set up.

8. Build up of technical debt: one of the reasons for the app modernisation era we find us in is because the legacy application estates. Legacy applications are hard to maintain and even harder to change. There is a massive effort going on at companies of all sizes to modernize these estates. And if there is something to be learned from this effort then it should be that modernizing legacy is extremely hard. So the build up of new technical debt (legacy) should be a factor in your decision, or lack thereof.

There are of course also arguments to the contrary which I need to address;

1. Lock-in; There is a perceived risk of being locked in when choosing for a vendor to provide you with software. Few things to this:

• Every externally sourced solution has an element of lock-in but there are ways to minimize the effort of moving away from the chosen solution or vendor. Open source solutions will give you flexibility and the ability to go in a different direction. The downside of open source could be that you lack support and your teams are now managing an open source project as opposed to using a ready product.
• Talent Lock-in; make no mistake. This talent lock-in is real. According to a 2022 report by Dice the average tenure of engineers is 2 years. If you are reliant on a couple of engineers who build a custom platform, how will you ensure continuity when they jump to a great new opportunity elsewhere? The likelihood of the engineers being hunted for other roles becomes bigger by the month as they build their resume. This will also drive their motivation to build a custom platform. It’s great fun and they build their CV in parallel. According to a 2022 survey by JetBrains, the top three things that IT engineers find most interesting about their job are:

1. Learning new things (57%)
2. Solving challenging problems (54%)
3. Building things that people use (49%)

So it’s no wonder that your smart engineers will advocate to engineer an in-house built platform. If you do decide to be taken on that journey be sure to plan for the time when the learning curve is not as steep and the problems of         engineering the platform have been solved.

3. Consultancy Firms: And then there is the reliance on system integrators or IT consultancy firms. Many companies and governments nowadays rely on the expertise of external parties. Especially because talented engineers are scarce it’s often quicker to assign a consultancy firm with the task of ‘supporting the cloud native journey’. There are many very good consultancy firms out there and they will be very capable of engineering a platform. The business model for most of these firms however is often opposed to your desired business outcomes of reducing hours, implementing efficiencies and speed to deliver. Being more efficient and doing more with less resources inherently means that you (the company) will need less hours from these firms, which is not in their interest. There are few companies that actually would recommend solutions which could compromise their business, to support the customer. 
4. Being special: “We have special requirements and so we need to build our own platform”. If that is the case how could then most companies make use of similar technologies of the same providers like Azure, AWS, GCP? I encourage you to write up with your engineers what makes your business so unique that you would need to custom engineer a non-differentiating utility. One could argue that the sheer acknowledgement of the fact that companies feel they have very exotic requirements says something about the complexity of internal processes and thus communication according to Conway.
5. Cost: This is a very valid argument and very hard to simplify but still, let me give it a shot. First, I realize that out of pocket money for an externally sourced solution weighs differently than the hidden cost of having people work to get to the same outcome. ROI calculations, developer productivity and other outcomes can be calculated but only stick if there is money to spend. Sometimes organizations have a hard time allocating budget for out-of-pocket investments because of financial drivers but even if the budget owner (business) is not opening up to financially viable arguments there is always the loss of opportunity cost and the competitive advantage cost. If companies can save time by implementing something and that would cost 1-2 years to build, this alone should justify out-of-pocket investments. The opportunity potential can be far greater than the initial investment. Or, put differently, the risk of your competitor beating you in Go-To-Market time should warrant some additional reasoning for investing. 
6. Security: This should never be an argument to engineer a custom platform in the context of cloud and Kubernetes. Our colleagues from Sysdig have found that 53% of companies have experienced security incidents due to misconfigurations in Kubernetes. To keep up with all the updates to all the moving parts and components becomes a real challenge and as such the risk of being exposed, when managing platforms is not your core business, is high.

I’m sure there are arguments I did not address here yet that would advocate for inhouse engineering and building of cloud platforms. I’d really be interested to hear your feedback as to why it would be a good idea. The question I would ask when companies really acknowledge the undertaking of building a complex platform, and after day 0 they would need to maintain and keep secure is; are you in the business of building platforms or does the value you provide to your users lie elsewhere?

Which Path Is Right for You?

The decision of whether to build a custom developer platform or to use an off-the-shelf platform depends on your specific needs and requirements. If you have a large budget and a team of experienced engineers, then building a custom platform may be a good option. I'd still encourage you to also think about Day2 of the platform. However, if you're on a tight budget or if you don't have the necessary expertise, then implementing standards through a platform product is probably a better option.

Here are some things to consider when making your decision:

• What is the key business goal you want to achieve? And by when?
• How is that business goal best achieved? By software or infrastructure?
• Budget: How much money are you able to invest in a developer platform?
• Timeframe: How quickly do you need to get a developer platform up and running?
• Expertise: Do you have the necessary expertise to build, secure and maintain a custom developer platform?
• Support: How important is support to you? Are you comfortable taking that risk for the business? At what cost? Are your team able to resolve all deep technical issues? 
• Talent: Are you already struggling to get the right technical staff onboard, trained and keep them happy and in the business? Think about investing in product and software engineering. Less on platform engineering.

In making the decision between a custom developer platform and an off-the-shelf solution, weigh these factors carefully. The right choice depends on your organization's specific needs, resources, and priorities. Making the wrong decision, or none at all could end up being a very costly one where you could fail the ultimate goal of becoming more competitive through software development.

If you are in doubt, we are more than happy to have a conversation.