Operations | Monitoring | ITSM | DevOps | Cloud

Developers are builders by nature (and profession), so many take pride in building their own solutions to problems from first principles, often using tools developed in open-source projects. So as Internal Developer Portals (IDPs) increased in popularity, it should come as no surprise that interest in open source IDPs increased in kind. While we may not yet have a fully opensource IDP platform, in this blog we’ll cover the open source components and platforms used to build IDPs from scratch.

Selecting the right Internal Developer Platform (IDP) is a critical decision that shapes the effectiveness of your software development team. An IDP empowers developers with the tools and environments necessary for efficient coding, testing, and deployment, resulting in a streamlined development workflow. However, a poor choice can lead to substantial setbacks, reducing productivity and overall business efficiency. In this article, we will discuss the most common mistakes to avoid when selecting an IDP.

Finding, prioritizing, and mitigating security vulnerabilities is an essential part of running software. We’ve all recognized that vulnerabilities exist and that new ones are introduced on a regular basis, so we make sure that we check for and remediate them on a regular basis. Even if the code passed all the security checks before being deployed, you still perform regular security tests to make sure everything’s secure.

The General Data Protection Regulation (GDPR), a legal mandate across the EU, requires enhanced protection for EU personal data transferred to countries with inadequate levels of data protection safeguards—including the US. The EU-US Privacy Shield, which was in place until 2020, facilitated these protections but was invalidated by the Schrems II ruling as a result of US surveillance concerns.

Until fairly recently, software releases happened once or twice a year, maybe once a quarter. This gave IT teams plenty of time to verify and manually sign off on every change before they were released in big batches during a bank holiday weekend or off-peak hours. Typically, they’d produce paperwork to show that all changes had been properly tested, and then those changes would be approved for release in a change advisory board meeting (CAB).