 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
For reporting or analytics, spreadsheets get a bad rap. They’re considered old school — and quite frankly, dated. Whether you’re an accountant or a software engineer, there’s always a conflict between the flexibility and usefulness of spreadsheets and the need to use dedicated reporting and analytics tools that aren’t manual.
Even in the software engineering space, the same conflict arises, such as in the case of using spreadsheets as a way to track microservices. In Port’s 2024 “State of Internal Developer Portals” report, 30% of engineering leaders stated that they used a spreadsheet as a microservice catalog. This is despite virtually all respondents (99%) reporting that they’re embracing platform engineering in their organizations, which is all about empowering developers with the tools, resources and processes they need to promote productivity.
Our survey aimed to get a better understanding of the platform engineering space, and particularly the core interface of platform engineering: the internal developer portal. We surveyed 100 engineering leaders from companies using a microservices architecture in production.
When asked if the respondents were using an internal developer portal, the majority (85%) said they were either already using one or were planning to do so in the next 12 months.
We then asked what type of portal they were using. Some 35% said they were using spreadsheets with microservices data. More than half (53%) use some kind of developer portal (in-house portal, Backstage or commercial products), and 12% use some sort of CI/CD developer self-service that isn’t a portal.
As internal developer portals are still a new product category, it’s unsurprising that the market is unclear about what it entails, but it is also natural that engineering leaders are using all kinds of tools and functions to try to deliver portal functionality to their developers. Those capabilities can be broadly categorized as developer self-service, as a catalog, and as an ability to ensure software standards are met. Often organizations will combine a CI tool like Jenkins, which provides a self-service interface — a service catalog of sorts — and a solution to ensure standards such as production readiness are met to create a homegrown portal of sorts. These highly customized portals tend to work well initially, but are difficult to maintain and adapt as the needs of the organization grow.
This is perhaps where the confusion to pick spreadsheets in the survey may have stemmed from. Leaders in eEngineering may be using them as a catalog in their organizations to track which microservices exist in the first place, as well as dependencies, software ownership and on-call personnel — all things you can do with an internal developer portal’s software catalog.
The main drawback, of course, is that updating spreadsheets is manual and error-prone, making any data that was painstakingly entered into them suspicious. Imagine using a spreadsheet to track application security vulnerabilities in microservices. If the data is entered manually, every once in a while, would you trust it? Would developers be happy manually updating the spreadsheet in the first place?
Another drawback is that internal developer portals are more than a service catalog. Portals also provide developer self-service actions, as well as the ability for managers to ensure standards are met using scorecards, automations and dashboards. They are a product category in their own right, focused on developer autonomy, productivity, setting clear and consistent quality standards, and promoting visibility into engineering activities and outcomes.
When cloud native microservices came into the world, together with the push to shift left, the knock-on effect has been chaos. First, through higher complexity, driven by tools with multiple interfaces, a mix of terminology and huge knowledge gaps within teams (for example, K8s). Second, through more responsibility given to developers — meaning they’re not just being asked to code but also manage incidents, deliver features and interact with the cloud. They also have to be mindful of the security, quality and compliance standards that have been set by the organization.
With microservices, a service catalog isn’t merely a list of the set of IT services offered by an organization. It’s a catalog that should track microservices, providing visibility into everything about these services and enabling users to query them — for instance, asking which externally facing services have critical security vulnerabilities, and understanding upstream and downstream dependencies.
With this in mind, using a spreadsheet as a service catalog to track dependencies, software ownership, on-calls and security migrations is problematic and labor intensive. Every change necessitates a manual update, and this can become outdated, difficult to manage and prone to errors.
Additionally, the lack of standardization can lead to difficulties in identifying resources, assets or owners. Without current data and context, answering critical questions such as “What is the AppSec posture of this service?” becomes impossible, and driving ownership and accountability becomes impractical.
An actual service catalog can help remove developer friction points and deliver a better experience in three key ways:
An internal developer portal also provides scorecards, which enable you to define the standards that a service or services within the software catalog should meet. By providing a score to these services, you get a view of their status and health. The catalog enables you to continuously monitor these services to ensure standards are being met.
Consider the FinTech company TransferGo as an example. Its developers had been manually recording all information about microservices and other platform elements using spreadsheets. The software engineering team attempted to use tags to identify asset ownership, but this tedious and nonstandardized process varied among users, making it difficult to establish a reliable single source of truth.
The spreadsheet method failed to effectively identify resources or owners, increasing the cognitive burden on developers and negatively affecting their experience.
Meanwhile, the company also used spreadsheets to determine the AppSec status of services. But this required considerable manual effort as multiple developers and team leads had to update the information, which affected productivity and satisfaction.
TransferGo adopted Port’s software catalog (another way of saying “service catalog”), a central metadata store for everything application-related, which allowed developers to note critical distinctions such as the version differences of the checkout service between staging and production.
By mapping vulnerabilities and misconfigurations to microservices within the software catalog, TransferGo’s developers gained a better understanding of the severity and context of each vulnerability. This enabled them to prioritize remediation effectively. Additionally, developers could see whether a vulnerability was in production, and access relevant application data in one centralized location.
Having all information in one place allowed the team to easily communicate AppSec standards and drive necessary changes.
Finding that 30% of engineering leaders say they use spreadsheets as a service catalog might not be that surprising as a standalone statistic; we’ve all used spreadsheets for analytics and reporting. But in a cloud native microservices environment, this method is too manual — and “manual is a bug.”
In the context of platform engineering, using spreadsheets undermines developers and their managers by failing to provide a centralized single source of truth, making the software development life cycle more difficult to understand than it should be. By creating a software catalog that’s always up to date and in context, engineering orgs can begin to use platform engineering to make developers autonomous and allow managers to ensure engineering standards are met.
